Mark Brooks wrote:

> but absolutely key for multi-platform scenarios

I believe you but I've not found a problem with panel or form scrolling
on my test devices. One application allows use from desktop to weeny
little 3.5" phone, and the latter has to scroll a lot. Normal scrolling
works on iPhone and Android.

Being able to do something to turn off the desktop sizing would
probably be good to allow those who really want it to do it. Even if in
code only as a manual override.

"Matthew Jones" wrote:

>>I believe you but I've not found a problem with panel or form scrolling
>>on my test devices.

I do hear what you say, but I think the difference is that EWB2 seems to use it's own non-native scroll bars. This is not the case with EWB1.

Mark Brooks wrote:

> EWB2 seems to use it's own non-native scroll bars

Ah right, nicely styled, and work well for most things, but may give
grief in places. Hmm.

Mark,

<< 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.
>>

None of the control interfaces in EWB 2 are "native".  There's no way to
paint a "native" control at design-time, because the design-time environment
isn't Windows, it's EWB.  I spent about 3-4 weeks on the scrollbars in total
in December, so this is a non-negotiable item and you won't be seeing native
scrollbars in EWB 2.

If you're worried about touch support and mobile devices, then that support
isn't complete yet, so you can't test that yet.  Under mobile or touch
environments, there will be an option to turn off the scrollbars so that you
can just use touch scrolling.  In such environments, the controls will look
just like they do now, sans scrollbars.

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

>>None of the control interfaces in EWB 2 are "native".  There's no way to
>>paint a "native" control at design-time, because the design-time environment
>>isn't Windows, it's EWB.  I spent about 3-4 weeks on the scrollbars in total
>>in December, so this is a non-negotiable item and you won't be seeing native
>>scrollbars in EWB 2.

Sorry Tim, but I'm just not getting this. Let me try to break it down for my own sanity:

- In EWB1 it was possible for the Desktop to be made larger than the browser window
- In this scenario it would cause the browser to invoke "native" scrollbars
- These scrollbars would scroll the entire web app view i.e. the Desktop
- Therefore a web app could extend below the bottom of the browser window (a common requirement)

In EWB2, since the Desktop always autosizes to the browser window, then it will never extend outside and the browser will never invoke its own "native" scrollbars. Instead, I think you are saying that the EWB2 controls will extend beyond the Desktop and the desktop itself will invoke "non-native" scrollbars, which is of course understandable, but not necessarily desirable. Native scrollbars are appropriate to scroll the "entire web app" while non-native can be used anywhere within the app.

It seems to me that the only possible issue is the fixed auto-sizing of the desktop. If the functionality were the same as EWB1, then we could make the desktop any size we wanted and the browser would handle scrolling it, whilst controls that required scrolling internally would use non-native.

>>If you're worried about touch support and mobile devices, then that support
>>isn't complete yet, so you can't test that yet.  Under mobile or touch
>>environments, there will be an option to turn off the scrollbars so that you
>>can just use touch scrolling.  In such environments, the controls will look
>>just like they do now, sans scrollbars.

That will be wonderful. Can't wait to see it.

Mark,

<< In EWB2, since the Desktop always autosizes to the browser window, then
it will never extend outside and the browser will never invoke its own
"native" scrollbars. Instead, I think you are saying that the EWB2 controls
will extend beyond the Desktop and the desktop itself will invoke
"non-native" scrollbars, which is of course understandable, but not
necessarily desirable. Native scrollbars are appropriate to scroll the
"entire web app" while non-native can be used anywhere within the app. >>

I understand what you're saying, but the Windows desktop, for example, does
not have scrollbars.  That's what I was going for in terms of design.  The
desktop encompasses the browser window space available to the EWB
application.  As far as EWB applications are concerned, there is no "browser
window", only the desktop.

<< It seems to me that the only possible issue is the fixed auto-sizing of
the desktop. If the functionality were the same as EWB1, then we could make
the desktop any size we wanted and the browser would handle scrolling it,
whilst controls that required scrolling internally would use non-native. >>

You *can* do so - you just need to modify the Desktop instance at
application startup so that it doesn't use the same layout, and set its size
accordingly.  You can also just modify the TDesktop interface and rebuild
the library, and that will do the same thing.

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

>>I understand what you're saying, but the Windows desktop, for example, does
>>not have scrollbars.  That's what I was going for in terms of design.  The
>>desktop encompasses the browser window space available to the EWB
>>application.  As far as EWB applications are concerned, there is no "browser
>>window", only the desktop.

Ok

>>You *can* do so - you just need to modify the Desktop instance at
>>application startup so that it doesn't use the same layout, and set its size
>>accordingly.  You can also just modify the TDesktop interface and rebuild
>>the library, and that will do the same thing.

Yeah. This kinda works. I used the following (ugly) code:

procedure TForm1.Form1Show(Sender: TObject);
var
 H: integer;
begin
 H := Application.Desktop.Height;
 Application.Desktop.Layout.Stretch := lsRight;
 Application.Desktop.Height := H;
end;

And I find that the desktop now has a fixed height but shrinks its width based on the browser window size. When the browser window height is less than the desktop height the app is vertically scrollable, but only via the mouse wheel, there is no browser vertical scrollbar. Actually, maybe no bad thing, although I wonder why? Has EWB2 set some HTML / CSS attribute for the desktop that tells the browser not to display scroll bars (but to still allow the content to be scrolled by the mouse wheel)?

Mark,

<< And I find that the desktop now has a fixed height but shrinks its width
based on the browser window size. When the browser window height is less
than the desktop height the app is vertically scrollable, but only via the
mouse wheel, there is no browser vertical scrollbar. Actually, maybe no bad
thing, although I wonder why? Has EWB2 set some HTML / CSS attribute for the
desktop that tells the browser not to display scroll bars (but to still
allow the content to be scrolled by the mouse wheel)? >>

It may be an issue with the desktop turning off scrollbars for the body
element, but I'll have to check.  Sorry that I can't provide more
information, but I'm really not prepared to go into this in much detail at
this point. I'll need to audit the whole thing to find out what's possible
since what you're trying to do goes against the general design of the
desktop.

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

>>It may be an issue with the desktop turning off scrollbars for the body
>>element, but I'll have to check.  Sorry that I can't provide more
>>information, but I'm really not prepared to go into this in much detail at
>>this point. I'll need to audit the whole thing to find out what's possible
>>since what you're trying to do goes against the general design of the
>>desktop.

Understood. Really don't want to take you off-track. The biggy for me was being able to set the desktop size. Scroll bars I can deal with whenever. I'll shut-up now.