Tim

In EWB1 I would often set auto-desktop width to True and then trap Desktop.OnResize in order to "jiggle" my GUI as the user changed the size of the browser window. This no longer appears to be possible with EWB2, unless there is a preferred method?

Cheers
Mark

Mark,

<< In EWB1 I would often set auto-desktop width to True and then trap
Desktop.OnResize in order to "jiggle" my GUI as the user changed the size of
the browser window. This no longer appears to be possible with EWB2, unless
there is a preferred method? >>

By default, the EWB2 desktop automatically sizes to fit the browser window.

If you want a form to do the same, then just set it's Layout properties to:

Position: lpTopLeft
Stretch: lsBottomRight
Consumption: lcNone

and it will automatically resize also.

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

>>By default, the EWB2 desktop automatically sizes to fit the browser window.
>>If you want a form to do the same, then just set it's Layout properties to:
>>Position: lpTopLeft
>>Stretch: lsBottomRight
>>Consumption: lcNone

There's that magical "layout" functionality again ......... pretty much popping up everywhere!

As an aside, this suggests that an EWB2 app will never invoke the browser scrollbars since the desktop can never be larger than the browser window. Is this the case? If so, then will forms that grow larger than the desktop invoke the desktop scroll bars? And, for GUI layout purposes, how do we know when the desktop has resized?

Sorry - I did say there would be lot of questions ...........

Mark,

<< As an aside, this suggests that an EWB2 app will never invoke the browser
scrollbars since the desktop can never be larger than the browser window. Is
this the case? If so, then will forms that grow larger than the desktop
invoke the desktop scroll bars? >>

Yes, although I just realized that I didn't enable the scrollbar
functionality for the TDesktop control.  The TDesktop control wraps the
main body element of a document at the browser level, so the TDesktop
control essentially gives you a way to style its background, etc., in
addition to placing controls directly on it, if you so desire.

<< And, for GUI layout purposes, how do we know when the desktop has
resized? >>

You would add an event handler for the OnSize event for the TDesktop and put
your code in there.

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

Mark,

<< As an aside, this suggests that an EWB2 app will never invoke the browser
scrollbars since the desktop can never be larger than the browser window. Is
this the case? If so, then will forms that grow larger than the desktop
invoke the desktop scroll bars? >>

>>Yes, although I just realized that I didn't enable the scrollbar
>>functionality for the TDesktop control.  

So, in order to use the native browser scroll bars for "view navigation" will you be implementing manual sizing for the Desktop, otherwise I think it won't be possible?

Mark,

Actually, my previous answer was incorrect.  I didn't add scrollbars for the
desktop because I anticipated that the main form would be used for the
scrolling container, not the desktop (the forms have scrollbar options).
The desktop sizing options caused too much grief in EWB1, and weren't
understood very easily.

<< So, in order to use the native browser scroll bars for "view navigation"
will you be implementing manual sizing for the Desktop, otherwise I think it
won't be possible? >>

You'll have to elaborate here.  I know that you've got something particular
in mind with your application, but I'm not sure what "view navigation" means
in that context.  The desktop control is just a normal control, so you can
change it's layout options, size, etc.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

>>You'll have to elaborate here.  I know that you've got something particular
>>in mind with your application, but I'm not sure what "view navigation" means
>>in that context.  The desktop control is just a normal control, so you can
>>change it's layout options, size, etc.

Ok. OmniGraffle to the rescue. Please see attached Tim - does it make sense now?

Mark,

<< Ok. OmniGraffle to the rescue. Please see attached Tim - does it make
sense now?  >>

Sure, but the part I'm unsure about is why you need to have the *browser*
scrollbars instead of just a form/panel's scrollbars.  You can do what you
want with EWB 2 as it exists, you just can't do it with the desktop.  IOW,
it's just different from EWB1, and I would suspect that this isn't the last
time that I'll be saying that....

Tim Young
Elevate Software
www.elevatesoft.com

Mark Brooks wrote:

> Ok. OmniGraffle to the rescue. Please see attached Tim - does it make
> sense now?


I can't speak for Tim of course, but to achieve that you can create
both a View form and a Content form. The content form would be bigger
than the view, so the view form will show scroll bars.

I am following along because my initial thought was "oh no", but on
checking all my apps do what Tim has done anyway, so it will make life
easier for me.

"Matthew Jones" wrote:

>>I can't speak for Tim of course, but to achieve that you can create
>>both a View form and a Content form. The content form would be bigger
>>than the view, so the view form will show scroll bars.

I think the issue here, Matthew, is that this would invoke EWB scroll bars (non-native) as opposed to browser scroll bars (native). Might seem irrelevant at first glance, but absolutely key for multi-platform scenarios. This is how my current applications work (although with STACKS of code to sort out positioning that will longer be required due to Tim's work on layouts