Tim Young [Elevate Software] wrote:

> would allow developers to create fairly complicated layouts for the items in a list box

Somehow I have a feeling I'd like that. But you'd have to be virtualised, otherwise it won't perform well (as you suggested to me when I found it not performing well...).

It is certainly a complex task, but it would be good if you can pull it off as well as everything else you've done.

--

Matthew Jones

Matthew,

<< Somehow I have a feeling I'd like that. But you'd have to be virtualised, otherwise it won't perform well (as you suggested to me when I found it not performing well...). >>

Yes, everything will be virtual in terms of the UI elements used to display the items, just like it is today.

<< It is certainly a complex task, but it would be good if you can pull it off as well as everything else you've done. >>

It's primarily a matter of abstracting the hell out of everything.

The new auto-sizing functionality is going to be pretty cool, and will play a big part in making the above happen.  You can do some pretty cool things with it when combined with the overflow layout properties for child controls/elements, including having the outer container automatically grow vertically when child controls/elements overflow and are moved underneath the prior controls.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> << Somehow I have a feeling I'd like that. But you'd have to be virtualised, otherwise it won't perform well (as you suggested to me when I found it not performing well...). >>
>
> Yes, everything will be virtual in terms of the UI elements used to display the items, just like it is today.
>  
> << It is certainly a complex task, but it would be good if you can pull it off as well as everything else you've done. >>
>
> It's primarily a matter of abstracting the hell out of everything.

I had a think about this last night, and I think you should be careful not to do too much. I think the ideal would be a new TForm derivative like the TDialog, upon which we would make our forms as now. It would have a number of virtual functions that we then fill in. And there would be a class from which we need to derive our list items. Then the list would be set up to use a particular one of these forms, and we would populate them using the class.

This of course is a nicer version of my FormList, but done better than my hack. The thing is, I think you shouldn't get too detailed in what the forms actually can do, or do for you. Things like "you are now moused over" or "you are now selected" would be good, but what happens then should be down to the developer (show a check image, highlight the background, make an AJAX call). Likewise making it a proper form with all the capabilities that offers, rather than a special interface to be made and managed, allows for easy development.

Maybe this is where you are going, but I just think "don't be too clever and far away from forms" and it will be a lot better for wide use. I've done a load of these things now, and it is already quite flexible, but they are all very different too.

--

Matthew Jones

Matthew,

<< I had a think about this last night, and I think you should be careful not to do too much. I think the ideal would be a new TForm derivative like the TDialog, upon which we would make our forms as now. It would have a number of virtual functions that we then fill in. And there would be a class from which we need to derive our list items. Then the list would be set up to use a particular one of these forms, and we would populate them using the class. >>

You can't really do virtual overrides in the form designer/object inspector, only event handlers.  What I was thinking of would involve something like a virtual list, in that there would be, in addition to virtual methods for component writers, events that allow the end developer to return.

The general issue of forms vs. re-usable container controls is a separate issue.  The designer functionality in the IDE needs some tweaking to get it to work with non-forms as root controls.  But, in general, it's not wise to consistently treat forms as container controls, due to their special nature.  Yes, forms can be parented to other controls, but they also involve a lot of functionality that can be painful to deal with if they are misused as normal controls.  It is much better to have a base container control that can be manipulated in the IDE designer functionality, and then added to the component palette for re-use.

Tim Young
Elevate Software
www.elevatesoft.com

This week?

Tim .... maybe a Christmas present?

Merry Christmas too all EWBer's!

Walter

Walter,

<< Tim .... maybe a Christmas present? >>

It's looking that way.

I just have to fix one last thing before I can package things up and start doing the builds, so it will still be a couple of more days.

The auto-sizing changes went well, but I ran into one more thing that I wanted to add that turned out to be a bit harder than expected (stretching during layouts where the stretching always results in a square).  I'm doing this for icon resizing when the icons are combined with captions.  It's hard to handle because the layout functionality has to do a second pass through for auto-sizing changes.  I may end up punting on this for now, if I can't resolve it today.

Merry Christmas !

Tim Young
Elevate Software
www.elevatesoft.com

Doug,

<< This week? >>

Probably - please see my reply to Walter.

Tim Young
Elevate Software
www.elevatesoft.com