Community
Participate
Working Groups
Created attachment 225288 [details] ScrolledComposite and ControlListener bug example Hey guys, we've found a problem regarding the ScrolledComposite in RAP. The ControlListener's method "controlResized" of the ScrolledComposite's content gets called on each newly opened view. We've assembled a small example to prove the bug (see attachment). View1 contains a ScrolledComposite and a ControlListener on the ScrolledComposite's content. The button in View1 opens View2 that contains only a composite with a ControlListener and a button that opens View3. On startup, the "controlResized" method in View1 gets called twice. When clicking the button in View1, View2 opens up and "controlResized" in View1 and View2 get both called several times. When clicking the button in View2, View3 opens up and "controlResized" of View1 gets called again. The "controlResized" method in View2 doesn't get called (right behavior). Here is the output: Startup: Content of View1 resized. Content of View1 resized. Click on button in View1: Content of View2 resized. Content of View2 resized. Content of View1 resized. Content of View2 resized. Content of View1 resized. Click on button in View2: Content of View1 resized. Content of View1 resized. As you can see the "controlResized" method in View1 is called too often.
This behavior is expected and it is not related to the ScrolledComposite. When you start an application for the first time (after server start) the real text sizes are unknown and RAP uses a TextSezeDetermination mechanism to ask the client (browser) for the real text size and do the re-layout (trigger resize). Once all texts are measured these resize events will stop. You could prove it by opening the three tabs on the first run and reload application. After the reload there are no resize events as tests are already measured in the first run.
Hi Ivan, thanks for your comment. It _really_ has to do something with the ScrolledComposite as you can see by clicking the button in View2. The ControlListener in View2 doesn't get called this time but the ControlListener in View1, that has a ScrolledComposite. And if I would open another new view all ControlListeners of all opened Views with ScrolledComposites would get called. That surely can't be expected behavior. RCP doesn't behave like that. Greetings Thorsten
In RCP the text sizes are known from the beginning, in RAP - we have to ask the browser for the actual sizes and re-layout the application with them. Do you observe resize events after application reload (F5 in the browser without server restart)?
If there is a text with unknown real dimensions (not measured yet) RAP triggers a re-layout of ALL composites in the application after the browser reports the correct dimensions. This is done by resizing (width/height + 1000) of ALL Shells. I'm still thinking that this bug is invalid.
Our problem is, that the ControlListener gets called even if the view is not visible. If you would have 20 views with ScrolledComposites and open a new view, 20 ControlListeners would get called. That can be a real problem if every view has a complex layout. This only happens on views with ScrolledComposite.
I think that re-layouting of a Composite/ScrolledComposite (and it's content) after TextSizeDetermination based on its visibility is dangerous. For example invisible view with scrolled composite and a collapsed forms section in its content. You could expand the section by code, which will trigger the TextSizeDetermination of its texts. If re-layouting (resizing) of the ScrolledComposite content is not performed because SC is not invisible, the layout of SC content will be wrong when you make the SC visible (make the view active).
...or another simpler example - invisible view with ScrolledComposite and a label as its content. If you change the label text (even call layout manually afterwards), the size of the label will not adapt to the real text size without TextSizeDetermination re-layouting/resizing.
