I think there's some confusion here and I'll try to outline the problems as clearly as possible...
 
 
First, standard comboboxes:
 
1) comboboxes filled with data take up too much memory.  An app with many comboboxes is too large and unworkably slow.
 
2) comboboxes attached to datasets do not automatically select the first item in the list when data is loaded, and when the dataset changes, the selection can be left displaying an item that isn't in the new data at all.
 
3) There is no easy way to know when the new data is finished loading in order to achieve #2
 
 
Now, datacomboboxes:
 
1) datacomboboxes do not load all data immediately.  This keeps them small at startup.  This is good.  However once opened, they use nearly as much memory as a standard combobox, resulting in the same problems with memory use as a standard combobox.
 
2) datacomboboxes select the first item automatically, but not when connected to dynamically loaded datasets.  This behaviour is critical for implementing cascading datacomboboxes because you use the select event to trigger the dataset reload for the subsequent datacombobox.
 
 
 
So given the above, here's our situation...
 
Our app has a LOT of comboboxes the majority have STATIC DATA.
 
The problem with normal comboboxes is that all that data is always loaded and the app is huge.
 
Switching to datacomboboxes solves the problem, at least initially, by not loading all the data until the user opens the dropdowns.  The problem is that inevitably, the user WILL open all the dropdowns in the course of making their selections, and eventually all the data will be loaded, grind the app to a halt again.
 
Our solution (for the static data comboboxes only so far) was to modify basedatacombobox to destroy the _cblist each time the popup list closes.  This seems to stop our app from growing in size but may have other unintended side effects.
 
The only reason that the original symbol lookup drilldown example (which uses standard comboboxes) is slow is because our app is just too large and has exceeded some sort of memory limit either with the flash player or the browser or both, causing some sort of thrashing.  I don't know what that limit is but I know that when the app is small, the drilldown performs fine.
 
 
So, we're proposing that datacomboboxes should *always* destroy _cblist when the popup closes since it results in much lower memory usage for the whole app.  Keep in mind that we don't really know our way around the datacombobox that well and maybe destroying _cblist is a little heavy handed.  It's possible there's some other way to dismiss the data and reduce the size that isn't so aggressive.
 
We would also like to see the #2 isses above fixed for both combobox and datacombobox since they will make our life as OpenLaszlo developers much easier.
 
...
Bill
 
 
-----Original Message-----
From: Jim Grandy [mailto:[EMAIL PROTECTED]
Sent: Friday, April 07, 2006 12:26 PM
To: William Krick
Cc: Tim Patsch; Laszlo-User
Subject: Re: [Laszlo-user] combo box bloat == 100 meg laszlo app

On Apr 7, 2006, at 7:20 AM, William Krick wrote:

Regarding the destruction of _cblist...


I just wanted to clarify that we are destroying the _cblist on the

*datacombobox*, not the standard combobox. Also, I'm not sure that I

understand what you mean about destroying it in the ondata handler. Whose

ondata handler are you talking about?


Yes, I was referring to datacombobox as well -- this technique wouldn't work with combobox.

What I was suggesting was that you tear down the cblist when the dataset changed. Isn't this where you were seeing the slowdown? My understanding was that you saw a speedup until you had opened all the datacomboboxes in the screen and then changed the dataset, and then the refresh was very slow. My hypothesis is that tearing down the cblist rather than repopulating it would be faster -- the cblist should be rebuilt when the user clicks on the datacombobox next.

jim
_______________________________________________
Laszlo-user mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-user

Reply via email to