Morning Tim (at least it is over here),

One more thought re: your recent docking and proposed "insert" functionality. If you were also able to provide direct access to the display attribute (in addition to visibility) then we could truly populate pages with hidden elements that could simply be displayed by toggling "display". This would allow for a whole range of interesting dynamic UI constructs, such as trees and concertinas. No idea how this might "screw" the framework however.

Over to you.

Cheers
Mark

Mark,

<< One more thought re: your recent docking and proposed "insert"
functionality. If you were also able to provide direct access to the display
attribute (in addition to visibility) then we could truly populate pages
with hidden elements that could simply be displayed by toggling "display".
This would allow for a whole range of interesting dynamic UI constructs,
such as trees and concertinas. No idea how this might "screw" the framework
however. >>

I think that this type of thing is better reserved for the component
writers.  A treeview is much more complicated than just an assortment of
elements (there are focus issues, tabbing issues, parenting issues, etc),
and so the component itself would always have access to them, and I think
that's all that is necessary.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

>>I think that this type of thing is better reserved for the component
>>writers.  A treeview is much more complicated than just an assortment of
>>elements (there are focus issues, tabbing issues, parenting issues, etc),
>>and so the component itself would always have access to them, and I think
>>that's all that is necessary.

I have utilised the display attribute already in my own components (admittedly these are run-time only but I think that the concept remains the same). I do this via a hack to get at the HTML entity.

A very typical use case is to have items within a container become visible based on context and the other items then adjusting their position accordingly. Imagine the simple "insert into a list" scenario. To date I have achieved this with LOTS of absolute positional code and, to be fair, it works extremely well. However, the code is unpleasant and things can get slow when lots of repositioning is required.

The new Align capabilities will really help, especially when combined with the "Insert" capability that you mentioned previously. However, insert is most likely relevant when you don't know what you'll be inserting until run-time. Imagine the scenario when you do know, for example a long list of things, some of which are initially hidden. Here I would set the display attribute to hide them AND not take up any screen real estate. Simply changing the display attribute would both show them AND shuffle everything else accordingly. Lovely dynamic UI with flow - for free!

All this would need to avoid the hack would be exposure of the display attribute via the framework.

Does this make sense or shall I shut up now

Mark

Mark,

<< The new Align capabilities will really help, especially when combined
with the "Insert" capability that you mentioned previously. However, insert
is most likely relevant when you don't know what you'll be inserting until
run-time. Imagine the scenario when you do know, for example a long list of
things, some of which are initially hidden. Here I would set the display
attribute to hide them AND not take up any screen real estate. Simply
changing the display attribute would both show them AND shuffle everything
else accordingly. Lovely dynamic UI with flow - for free! >>

Yep, that's how the docking works already - if a control isn't visible
(Visible property=False), then it is removed from the docking flow.  Once
you make it visible again, the control will re-dock in the proper position
based upon its assigned position and dimensions.

Tim Young
Elevate Software
www.elevatesoft.com