Hey Tim

Congratulations.

First question (of many I imagine) - is there any documentation that explains the layout class?

Second question - ditto for interfaces

Regards

Mark

Actually, scratch the Layout question - got it sorted now - very sweet indeed

Mark,

<< First question (of many I imagine) - is there any documentation that
explains the layout class? >>

None of the new documentation is done yet, but I can give you a quick
run-down:

1) Layout order - this is the key property for layouts, since it determines
the default stacking order as well as the order in which controls will
consume space in the layout.

2) Layout.Position - this indicates the position of the control *only*.  If
you were to add 3 controls to a form and set all of their Layout.Position
properties to lpTopLeft, then they would all be positioned in the top left
corner, stacked in their layout order (or display order, if modified to be
different from the layout order).  The position of a control *is* relative
to any space consumption that has already occurred in the layout (does not
apply to position of lpNone), so if 2 of the 3 controls were set up to
consume space in whatever way, then the 3rd control would be positioned in
the top left corner of whatever space has not already been consumed.

3) Layout.Stretch - this indicates in which direction(s) the control should
be stretched.  Like the Position property, this property is sensitive to
already-consumed space by other controls.  Also, stretching is not
*automatically* equal to consuming space.  You can have controls that all
stretch in the same direction, one on top of the other.

4) Layout.Consumption/Layout.Reset - these properties are the key to layout
space consumption, and how (direction) the control should consume space.
The Reset property determines whether the consumed space should be reset to
the last reset point (the last control with Layout.Reset=True, or the
beginning of the layout) *after* any space is consumed by the control, and
is normally used when you want to change space consumption direction in a
layout.

For example, with a normal label/input layout on a form, you would set up
the controls like this:

Label 1      Edit 1
Label 2      Edit 2
Label 3      Edit 3

To set up this layout, you would use these property settings:

Labels: Position=lpTopLeft, Stretch=lsNone, Consumption=lcRight, Reset=False
(and normally you would want to set their Format.Alignment to caRight, and
set their widths to be the same width)

Edits: Position=lpTopLeft, Stretch=lsRight, Consumption=lcBottom, Reset=True

So the way the layout works is this:

Label 1 consumes space to the right, so the layout rectangle changes are
<Client Rect Left> to <Client Rect Left + Label 1 Width>.

Edit 1 is now positioned according to the space already consumed by Label 1
at the *new* <Client Rect Left>.  It is stretched to reach <Client Rect
Right>.  However, it is set to consume space to the *bottom*, not the right.
This means that the layout rectangle will be reduced from <Client Rect Top>,
not <Client Rect Left>.  This is why we also need the Layout.Reset property
to be set to True here.  Without it, Label 2 will be positioned below Edit
1, not Label 1.  This is because the <Client Rect Left> position for the
layout rectangle needs to be reset to the last layout reset point at the far
left.

So, effectively what you end up with is a snaking pattern within the form's
client rectangle:

>=====> Next line of controls
>=====> Next line of controls
>=====>

I've attached a sample project that shows how this works.  It's an HTML form
submit example that does this kind of layout.  Just try resizing the form at
design-time and you'll see the controls automatically resize accordingly.
More importantly, you can layout a form using margins as general guidelines,
instead of trying to nudge stuff around.

<< Second question - ditto for interfaces >>

Let me do a separate post for that after I post a video today.  It may
answer a lot of your questions.

Tim Young
Elevate Software
www.elevatesoft.com

Got it Tim - all makes sense - I have just built a screen from my EWB 1 app in about 15 mins - it took a day or so and lots of maths in EWB 1 but just a few "layout settings" in EWB 2 - very cute indeed

As an aside, what is a TPaperForm - intrigued?

Mark,

<< Got it Tim - all makes sense - I have just built a screen from my EWB 1
app in about 15 mins - it took a day or so and lots of maths in EWB 1 but
just a few "layout settings" in EWB 2 - very cute indeed >>

Yeah, it's a lot easier, especially when you realize that these same layout
properties apply to the UI elements that *make up* a control.  The whole
shebang operates on just a few primitive layers of functionality.

<< As an aside, what is a TPaperForm - intrigued? >>

It's just a form that looks like a "document" instead of a windowed form.
See my reply to Matthew for the details about how new form types can be
used.

Tim Young
Elevate Software
www.elevatesoft.com

<< As an aside, what is a TPaperForm - intrigued? >>

>>It's just a form that looks like a "document" instead of a windowed form.
>>See my reply to Matthew for the details about how new form types can be
>>used.

Got it. Thanks.

Is there a way for a TPaperForm to resize based on the controls that are placed within in?

If, for example, one wanted to create a Facebook style app where the content is contained within the browser window from left - right but extends beyond it below, using the browser vertical scroll bar (only) to move up and down. You'd want to be able to dump controls (content) onto the TPaperFrom at runtime (based on content read from a DB for example) and use the new layout abilities to stack it from top to bottom, and have the form grow in height to accommodate. UI nirvana!

Cheers

Mark,

<< Is there a way for a TPaperForm to resize based on the controls that are
placed within in? >>

Not currently, no.  I tried adding auto-sizing of container elements based
upon the elements within, but had to kill that functionality due to some
issues with recursive layout updates.  There's definitely a solution in
there, though, and I'll revisit this once things quiet down.

<< If, for example, one wanted to create a Facebook style app where the
content is contained within the browser window from left - right but extends
beyond it below, using the browser vertical scroll bar (only) to move up and
down. You'd want to be able to dump controls (content) onto the TPaperFrom
at runtime (based on content read from a DB for example) and use the new
layout abilities to stack it from top to bottom, and have the form grow in
height to accommodate. UI nirvana! >>

For now, there are several ways you could handle this, from just getting the
bottom of the newly-added control (TControl.Top+TControl.Height) and
assigning it to the form's height, to more complicated stuff like a new form
class that looks at some change events that are triggered at the UI element
level (scChildLayoutChanged) and automatically resizes accordingly.

An important thing to remember is that the EWB UI layer does
sizing/positioning *outside* of the scope of the browser.  It does so to
minimize the triggering of layout operations in the browser, and to allow
for an abstraction layer for the design-time operation.  So, there's not a
lot of penalties for moving things around, or re-sizing them, especially
within the scope of a BeginUpdate/EndUpdate pair of calls on the form
control.

Tim Young
Elevate Software
www.elevatesoft.com

<< If, for example, one wanted to create a Facebook style app where the
content is contained within the browser window from left - right but extends
beyond it below, using the browser vertical scroll bar (only) to move up and
down. You'd want to be able to dump controls (content) onto the TPaperFrom
at runtime (based on content read from a DB for example) and use the new
layout abilities to stack it from top to bottom, and have the form grow in
height to accommodate. UI nirvana! >>

>>For now, there are several ways you could handle this, from just getting the
>>bottom of the newly-added control (TControl.Top+TControl.Height) and
>>assigning it to the form's height, to more complicated stuff like a new form
>>class that looks at some change events that are triggered at the UI element
>>evel (scChildLayoutChanged) and automatically resizes accordingly.

Ok. I get it. Will play later. Cheers Tim.

Tim Young [Elevate Software] wrote:

> So, there's not a lot of penalties for moving things around, or
> re-sizing them, especially within the scope of a
> BeginUpdate/EndUpdate pair of calls on the form control.

Is that new to EWB2, or is it in EWB1 too? Maybe I should start doing
that with my TPanel layouts...

Matthew,

<< Is that new to EWB2, or is it in EWB1 too? Maybe I should start doing
that with my TPanel layouts... >>

It's new in EWB2.  EWB1 relies on the browser for all of its dimensional
information because it really didn't have a "design-time" mode, at least not
with the same EWB source code.

Because EWB2 has to operate in a dual mode for design-time and run-time, it
abstracts away most of the layout operations into a middle UI layer that
handles all of this transparently to the application and controls.

Tim Young
Elevate Software
www.elevatesoft.com