Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder 2 Preview » View Thread |
Messages 1 to 10 of 17 total |
Layouts |
Tue, Jan 27 2015 3:10 AM | Permanent Link |
Mark Brooks Slikware | 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 |
Tue, Jan 27 2015 5:18 AM | Permanent Link |
Mark Brooks Slikware | Actually, scratch the Layout question - got it sorted now - very sweet indeed
|
Tue, Jan 27 2015 7:00 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 Attachments: formsubmit.zip |
Tue, Jan 27 2015 7:07 AM | Permanent Link |
Mark Brooks Slikware | 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? |
Tue, Jan 27 2015 7:21 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Jan 27 2015 7:53 AM | Permanent Link |
Mark Brooks Slikware | << 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 |
Tue, Jan 27 2015 8:13 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Jan 27 2015 8:29 AM | Permanent Link |
Mark Brooks Slikware | << 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. |
Tue, Jan 27 2015 8:45 AM | Permanent Link |
Matthew Jones | 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... |
Tue, Jan 27 2015 8:56 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |