Here's another new item in the pipeline, and something that was supposed to
be in the initial release but didn't make it - a Layout.Overflow property
that handles flow layouts when UI elements/controls exceed the current
layout rectangle.  It allows for responsive design with just a single
property change, and it works at design-time.  No need for specific
flow-panel controls - any container control can have its child controls
automatically flow top-to-bottom/left-to-right, etc. as the browser window
resizes.  And, it works with stretching by simply using min width/height
constraints on stretched UI elements/controls.

An example application is here:

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

Just resize the browser window horizontally to see the flow/stacking effect.
The orange panel has its Layout.Stretch property set to lsRight.

The Layout.Overflow property is used to determine how to dynamically
back-patch the previous (in layout order) control's consumption behavior
when the current control's margin rectangle overflows the bounds of the
current layout rectangle.  This means that you can set up a pre-determined
layout with consumption, resets, etc. that will stay "put" until one of the
overflow conditions is met.  At that point, the overflow functionality kicks
in.

Tim Young
Elevate Software
www.elevatesoft.com

Nice work!

Very nice.

Tim, does that also mean that we can hide (using Overflow.hidden) controls if they exceed specific bounds ?

Cheers

Max Evans

OMG - We're gonna have to start calling you Santa!

Max,

<< Tim, does that also mean that we can hide (using Overflow.hidden)
controls if they exceed specific bounds ? >>

The quick answer is no.   It's something I can look into, but making
something hidden removes it from the active layout, and currently there
isn't any concept in the UI functionality for "user-hidden" vs.
"layout-hidden".

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> but making something hidden removes it from the active layout,

It strikes me that perhaps an event that someone can hook into would be
good to have. Some way of passing in the "this is how big the world is"
and then the event can show or hide anything and then the sizing
operation occurs. Would save the resize event then hiding something and
causing another sizing operation.

--

Matthew Jones

Matthew,

<< It strikes me that perhaps an event that someone can hook into would be
good to have. Some way of passing in the "this is how big the world is" and
then the event can show or hide anything and then the sizing operation
occurs. Would save the resize event then hiding something and causing
another sizing operation. >>

I would have to think about that.  The layout operations occur *a lot*, so
they are performance-critical, and you're talking about an event that would
need to fire for every layout sequence.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> so they are performance-critical,

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.

--

Matthew Jones

Matthew,

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

Tim Young
Elevate Software
www.elevatesoft.com