ooptimum wrote:

> Mark Brooks wrote:
>
> << I concur with this statement. Certainly once you get into multiple hundreds of panels then I struggled to get acceptable performance without some form of virtualisation >>
>
> I have already answered Matthew above, but since you insist on virtualization, tell me, please, how you can apply it here. Imagine that we have a very long checklist of about 600 questions, of which a user should select, say, only three. Questions are distributed among 30 categories approximately equally. They can be filtered, but without a filter we have to show them all. How this can be virtualized?

The simple answer is to create as many labels as fit the available space, and then use a scroll bar which is set to scroll for the full number. When the user scrolls to item 50, you set the values of the labels to the 50th, 51st, 52nd, etc items in the list.

To make it work, I have all the items on a panel have a tag which is their index. You have a separate object list that contains all the data. Then, when someone clicks on a checkbox for example, you update the object in the list at index tag + top-offset.

In your case, with multiple levels, you might insert the category titles as you go, or have the controller set the type of the panel to be category, and it updates from that.

--

Matthew Jones

Matthew,

What is the principal difference of what you describe from a grid? If I wanted to use a grid, I would use a grid. However, thank you for helping. When I was thinking about your proposed solution and my answer to it, I had the idea that I need not create all 600 checkboxes on the initially hidden sublevel at once, and I could do it later, as needed. A large number of elements is not a problem when they are already created. Now we need to understand what is worse, wait a little longer, but once, or less, but many times.

ooptimum wrote:

> What is the principal difference of what you describe from a grid? If I wanted to use a grid, I would use a grid. However, thank you for helping. When I was thinking about your proposed solution and my answer to it, I had the idea that I need not create all 600 checkboxes on the initially hidden sublevel at once, and I could do it later, as needed. A large number of elements is not a problem when they are already created. Now we need to understand what is worse, wait a little longer, but once, or less, but many times.

A grid is a specialised display of a database, and yes, it is virtualised for speed. In the situations I was working on, I've had much more complex displays, some with edit boxes, check boxes, icons, and lots. I too started thinking I could add as needed, but performance just caused too much hassle. In the end, it was easiest to be virtual and go for it. And the dynamic system I did would allow for more panels to be added as needed, and when not needed they were hidden. It was slower to delete them and recreate.

And this isn't EWB, it is the whole DOM operation - any javascript will have this.

--

Matthew Jones

<< b) The second problem is that these panels with nodes must be initially collapsed, but despite I call Minimize method and their internal state corresponds to the minimized view, they actually are not minimized when displayed. Moreover, this behavior is manifested only if the AutoSize.Height property of a panel is True. In real app their behavior even weirder, but in the attached demo it apparently depends on AutoSize.Height only. Is this some kind of RTL error or I have mistaken somewhere? >>

Okay, here's the hot fix:

In the WebCtnrs unit, modify this method:

procedure TPanelControl.UpdateClientAutoSize;
begin
  if Assigned(FClientElement) then
     begin
     if (Element.AutoSize.Width and Element.AutoSize.Height) then
        FClientElement.Layout.Stretch:=lsNone
     else if (Element.AutoSize.Width and (not Element.AutoSize.Height)) then
        FClientElement.Layout.Stretch:=lsBottom
     else if ((not Element.AutoSize.Width) and Element.AutoSize.Height) then
        FClientElement.Layout.Stretch:=lsRight
     else
        FClientElement.Layout.Stretch:=lsBottomRight;
     end;
  if (not Minimized) then  <<<<<<<<<<<<< Add !!!
     inherited UpdateClientAutoSize;
end;

and modify this method also:

procedure TPanelControl.Minimize;
begin
  if Element.Minimize then
     begin
     InterfaceState:=MINIMIZED_STATE_NAME;
     UpdateClientAutoSize;  <<<<<<<<<< Add !!!!!
     Height:=((Element.Border.Top.Offset+Element.Padding.Top)+FCaptionBar.Height);
     FCaptionBar.UpdateMinimized;
     DoMinimize;
     end;
end;

I will ensure that this hot fix is in 2.06 B19, which will hopefully be the last build for EWB 2.x.

Tim Young
Elevate Software
www.elevatesoft.com