Community
Participate
Working Groups
Created attachment 194811 [details] project to reproduce problem While working on https://bugs.eclipse.org/bugs/show_bug.cgi?id=314280 I encountered a problem with the Text widget that I could not solve: If a multi line text is added to a composite that has no layout and if the size of this text is calculated using pack(), there might be some trouble with the visibility of the scrollbars in case the textsize determination kicks in. I've modified the attachement of #314280 to demonstrate the problem: 1) download the attached project zip and import it to your RAP workspace 2) include the project to the bundles of the RAP Workbench launch configuration 3) launch the workbench and change the URL to use "demots" as entry-point 4) click "open new editor" What you see is that the textsize determination takes place. The text is resized to the correct size after the content of the text was properly measured. Unfortunately the scrollbars still stay visible although they are not needed anymore. The latter problem vanishes once you open a second editor and switch between the two editor tabs. Unfortunately I wasn't able to reproduce the problem in a simpler setup with the controls demo :( So the interesting part is in the DemoActionBarAdvisor of the demo project...
Frank, I think that your snippet is not so correct. You have a multi text widget with a parent ScrolledComposite (OS400JTerminal#getComposite), but you never set the content (call ScrolledComposite#setContent) on this ScrolledComposite. Thas't why the Text widget is not visible for me. Adding ScrolledComposite#setContent( testText) at the end of run method makes the Text widget visible. As ScrolledComposite maintain the bounds of its content, I don't understand the usage of pack() method here. If I change OS400JTerminal#getComposite to return a Composite, not ScrolledComposite, everything is working fine.
Created attachment 204272 [details] project to reproduce problem Changed the project to use Composite instead of scrolled composite as described by Ivan (the demo code was not written by me and it seemed to work at the time that I filed the bug). Anyway the problem persists using composite, but occurs only, if you use a browser within eclipse IDE (see screenshot attachment). Therefore I consider this a lower priority problem...
Created attachment 204273 [details] Screenshot using Browser (IE 9) integrated in IDE
(In reply to comment #2) > Created attachment 204272 [details] > project to reproduce problem > > Changed the project to use Composite instead of scrolled composite as described > by Ivan (the demo code was not written by me and it seemed to work at the time > that I filed the bug). Anyway the problem persists using composite, but occurs > only, if you use a browser within eclipse IDE (see screenshot attachment). > Therefore I consider this a lower priority problem... Note that I did the latest tests against CVS HEAD.
Note that this problem may be related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=359380
By switching IE to standard rendering (bug 270397) layout in IE9 x64 is not broken anymore and I can't reproduce this issue anymore.
