Bill, I would start by trying datacombobox against a static data set. If that is still too slow, we'll need to take a look at what going on and how things might be sped up.
jim On Apr 4, 2006, at 12:37 PM, William Krick wrote: > 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 _______________________________________________ Laszlo-user mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-user
