|
|
|
|
Re: Resize Listener on Display [message #1018893 is a reply to message #1016507] |
Thu, 14 March 2013 16:24 |
|
Hi Stefan,
I'm not sure if this is the same situation, but it sounds similar... we too have an application that needs to respond to changes in the browser size, so that the shell takes advantage as the user enlarges the browser. We also want it to work in a device's browser when the device is rotated (for example), so detection of display size changes is important.
Our solution is to use shell.FullScreen(true), and a resize listener on that shell.
Some of our designs have a minimum size too, so if the browser is too small to show the whole design, we want it scrollable... to achieve this, we have a ScrolledComposite which uses a layout that takes the WHOLE parent shell space, and then another Composite that takes the whole of the ScrolledComposite space, with the ScrolledComposite taking a min width/height according to our UI design.
So the structure is Display->Shell(with FullScreen)->ScrolledComposite->Composite->All the other widgets in the UI.
This seems to work very well in desktop browsers and on devices. The same code also works well for Tabris.
On resize of the FullScreen shell, we also resize the ScrolledComposite and its Composite on the fly.
I may seem a little overkill, but actually it is only introducing 2 additional levels in the structure with the 2 Composites, and is relatively easy to code for.
Sorry if this isn't appropriate for your situation, but thought I would share as it had similarities.
Best regards, John
---
Just because you can doesn't mean you should
|
|
|
|
Re: Resize Listener on Display [message #1024763 is a reply to message #1023981] |
Tue, 26 March 2013 09:15 |
|
Hi Stefan,
We don't use a separate Shell for the fullScreen... only 1 Shell is 'primary' for us at a time, so we detect resize events on the fullScreen Shell, which actually contains our scrolled composite and widgets in that. Since this Shell is fullScreen, you cannot get focus on any other Shells that happen to be behind in the Z-order, although they are there. I'm not sure that our solution would work for Shells that are NOT fullScreen - suspect not. We do use a few of these, but they are subsidiary dialogs and confirmations most of the time, so don't necessarily need the same treatment. Any 2ndary dialogs like this always have a parent Shell (logically) which is fullScreen anyway, so we can still detect the display resize/rotate on the parent and do whatever we need to its children at the same time.
Hope that clarifies a little.
Best regards, John
---
Just because you can doesn't mean you should
|
|
|
Powered by
FUDForum. Page generated in 0.03552 seconds