Tim Young [Elevate Software] wrote:

> << The caveat would be on the documentation, but better to have an
> event that you can do something in, than do the whole lot twice. Just
> make it clear that the event needs to be fast, and use pre-calculated
> info rather than complex calculations. >>
>
> Actually, I was referring to having an event call at all, regardless
> of the code in the call.  When I say the layout operations get called
> a lot, I mean *a lot*.

I wonder if my suggestion is understood then. I'm not talking about
asking each panel, button etc if they are going to be made visible or
not, I'm suggesting that there is a single event at the start of a
layout that tells the form that the layout operation is about to start,
and to change anything right then. So one call per resize event.
Obviously there is a lot to do in the layout, and I guess it is called
more often, like when a label text is changed. I'd not expect that to
cause this event.

Fundamentally, I think I am actually describing the existing Form
OnResize, aren't I? So long as that happens before the auto-layout
occurs, then what I suggest is already in place. As usual...

--

Matthew Jones

On 7/10/2015 5:48 AM, Matthew Jones wrote:
> Fundamentally, I think I am actually describing the existing Form
> OnResize, aren't I? So long as that happens before the auto-layout
> occurs, then what I suggest is already in place. As usual...

Surface resize event (Application.Surface.OnSize) would help to tell you
when browser got resized (form itself might not have resized at this
point depending on layout) so for "size of the world changed" you can
use surface OnSize and then check Application.viewport height and width.

Raul

Matthew,

<< I wonder if my suggestion is understood then. I'm not talking about
asking each panel, button etc if they are going to be made visible or not,
I'm suggesting that there is a single event at the start of a layout that
tells the form that the layout operation is about to start, and to change
anything right then. So one call per resize event. Obviously there is a lot
to do in the layout, and I guess it is called more often, like when a label
text is changed. I'd not expect that to cause this event. >>

Yes, but you can't just use such an event selectively.  The way the layouts
work must be uniform for every layout cycle.  If it isn't, then you're going
to have a mess.

And yes, as you say, there are numerous things that trigger layouts, and
*each UI element can layout its children*.   IOW, the layout management
extends from the surface all the way down to the scrollbar buttons.  So,
you're talking about more than just one event call per form resize.

<< Fundamentally, I think I am actually describing the existing Form
OnResize, aren't I? So long as that happens before the auto-layout occurs,
then what I suggest is already in place. As usual... >>

Yes and no.  As mentioned above, more than just sizing can cause a
re-layout, so there's that problem right off the bat.  But, if you're *only*
interested in changes due to sizing changes, then yes, it would
work.....maybe.

Tim Young
Elevate Software
www.elevatesoft.com

I've updated the responsive layout example to include the new animation
support coming soon:

http://www.elevatesoft.com:8081/responsive/responsive.html

(as before, just resize the browser window horizontally)

You can choose from any of the standard easing equations for animation:

  TAnimationStyle = (asNone,asLinear,asQuadEaseOut,asQuadEaseIn,
                     asQuadEaseInOut,asQuadEaseOutIn,asExpoEaseOut,
                     asExpoEaseIn,asExpoEaseInOut,asExpoEaseOutIn,
                     asCubicEaseOut,asCubicEaseIn,asCubicEaseInOut,
                     asCubicEaseOutIn,asQuartEaseOut,asQuartEaseIn,
                     asQuartEaseInOut,asQuartEaseOutIn,asQuintEaseOut,
                     asQuintEaseIn,asQuintEaseInOut,asQuintEaseOutIn,
                     asCircEaseOut,asCircEaseIn,asCircEaseInOut,asCircEaseOutIn,
                     asSineEaseOut,asSineEaseIn,asSineEaseInOut,asSineEaseOutIn,
                     asElasticEaseOut,asElasticEaseIn,asElasticEaseInOut,
                     asElasticEaseOutIn,asBounceEaseOut,asBounceEaseIn,
                     asBounceEaseInOut,asBounceEaseOutIn,asBackEaseOut,
                     asBackEaseIn,asBackEaseInOut,asBackEaseOutIn);

The elastic animations are particularly cool.

The animation support will probably be designated as "experimental" for the
next minor release, primarily because it's not being surfaced for dialogs,
etc. yet, and I need to add support for showing/hiding UI elements/controls
and some other bits like completion events.

Tim Young
Elevate Software
www.elevatesoft.com

This is just fantastic Tim. Can we use it for sliding in side-panels etc?

Tim,

> I've updated the responsive layout example to include the new animation
> support coming soon:

Very cool

Uli

Mark,

<< This is just fantastic Tim. Can we use it for sliding in side-panels etc?
>>

Sure, you can animate any TControl-descendant with it.  The animation works
at the tail end of any dimensional update by animating the transition from
the current DOM dimensional settings to the new DOM dimensional settings, so
it works with layout changes, etc. and only kicks in after the end of a
BeginUpdate/EndUpdate cycle.

Tim Young
Elevate Software
www.elevatesoft.com