Jim, Since you seem to know your way around the combobox pretty well, how would you suggest I go about creating a dedicated non-editable "Yes/No" control that looks like a combobox but without all the unneeded bloat?
There are a few other "boolean" type combo choices in our app like Male/Female but Yes/No is the real bulk of the app. It's perfectly ok for the choices to be hardcoded to Yes and No. If I need a control for something else, I'll just make a copy and hardcode the other choices. Should I start with combobox, basecombobox, or baseformitem? Or maybe something else entirely? I think it at least has to extend baseformitem because the controls are part of a form and we must be able to submit them. I'm new to creating OpenLaszlo components so any advice or assistance you can provide would be greatly appreciated. ... Bill -----Original Message----- From: Jim Grandy [mailto:[EMAIL PROTECTED] Sent: Thursday, March 23, 2006 6:48 PM To: William Krick Cc: Laszlo-User Subject: Re: [Laszlo-user] combo box bloat == 100 meg laszlo app datacombobox *is* newcombobox, just under a different name. The correspondence is: incubator/newcombobox becomes base/basedatacombobox incubator/lzcomombobox becomes lz/datacombobox The main cause of bloat and slow initialization with combobox is that it creates a floatinglist instance when it is initialized. So all of the comboboxes in your application will have an associated floatinglist instance. We improved that in newcombobox to share a floatinglist between all newcombobox instances using the same style. But this created bugs with data binding and synchronization, so with datacombobox we changed it so that each instance has its own floatinglist, but the floatinglist is only instantiated when needed. This is still a bit fragile because newcombobox/datacombobox is engineered to get its selection manager and data state from the floatinglist -- selection and value have to be managed manually until the floatinglist is created. There are improvements to be made there. Note that both newcombobox and datacombobox are entirely data-driven (hence the name of the latter), so you can't supply the menu items statically as you can with combobox. jim On Mar 23, 2006, at 1:26 PM, William Krick wrote: > I'm working on an OpenLaszlo application that has a lot of controls > for data > input. > > When I load our app up in a browser and check the memory use for that > browser instance in task manager, it's around 100 megs. > > Obviously this is WAY too large and something has to be done to > bring the > size down. > > After some digging, it appears that the majority of our apps memory > use is > due to combo boxes. LOTS of comboboxes. > > The combobox is critical to our application so we need a solution that > brings the memory use for comboboxes way down. > > Also, a side effect of this bloat is that anything that dynamically > manipulates the contents of a combobox like adding or removing > items, or > refreshing the list when connected to a dataset, is unusably slow > in our > application. > > I know there was some work done on a "newcombobox" but it appears > that that > might have been abandoned in favor of the "datacombobox" which doesn't > really address the bloat problem. > > Can anyone tell me what, if anything, can be done to remedy our > situation? > > My co-worker is putting together and will post an example that > specifically > addresses the performance problems when manipulating comboboxes but > I just > wanted to query the list about a solution to the larger problem of > application bloat due to comboboxes. > > Is it possible to strip down the combobox and/or textlistitem to > make them > less memory hungry? > > ... > Krick > > _______________________________________________ > Laszlo-user mailing list > [email protected] > http://www.openlaszlo.org/mailman/listinfo/laszlo-user _______________________________________________ Laszlo-user mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-user
