Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 336057

Summary:

CoolBar overlap its items

Product:

[RT] RAP

Reporter:

Yury <swimmer_86>

Component:

RWT

Assignee:

Project Inbox <rap-inbox>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

swimmer_86

Version:

1.3

Target Milestone:

1.4 M6

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
demo.png	none
planning(good).png	none
planning(bad).png	none

Description Yury

2011-02-02 07:05:41 EST

Build Identifier: RAP 1.3

CoolItems are wrongly positioned on its CoolBar panel in case of small panel size.

Reproducible: Always

Steps to Reproduce:
1. Run DemoWorkbench application from org.eclipse.rap.demo.
2. Switch to Demo perspective.
3. Reduce window size like it is shown on (demo.png)
4. Switch perspective to Planning. You will see problem as on Planning(bad).png.

If you switch to Planning perspective before size reducing - everything is OK (see Planning(good).png).

Comment 1 Yury

2011-02-02 07:06:18 EST

Created attachment 188126 [details]
demo.png

Comment 2 Yury

2011-02-02 07:06:47 EST

Created attachment 188127 [details]
planning(good).png

Comment 3 Yury

2011-02-02 07:07:13 EST

Created attachment 188128 [details]
planning(bad).png

Comment 4 Yury

2011-02-02 07:08:15 EST

I've found that following fixes in CoolItem.js resolve the problem.

    // reparenting to enable coolitem dragging
    setControl : function( control ) {
      if( control != null ) {
        // TODO [tb] : Control positioning is already handled by server
        control.setTop( this.getTop() );
        control.setLeft( this.getLeft()
                         + org.eclipse.swt.widgets.CoolItem.CONTROL_OFFSET );
        control.setDisplay( true );
      }
      if( this._control != null ) {
        this._control.setDisplay( false );
      }
      this._control = control;
    },



Using

control.setTop( this.getTop() ); 


instead of

control.setTop( 0 );

Comment 5 Ivan Furnadjiev

2011-02-02 08:21:00 EST

This is reproducible with CVS HEAD too.

Comment 6 Ivan Furnadjiev

2011-02-02 09:28:59 EST

Fixed in CVS HEAD by removing the control.setTop at all. As control bounds are calculated by the server, setTop is not needed.