I can think of two options. Neither of them is pleasant: 1) Use a scheme like the one in newcombobox, but instead of employing a single floating list, make a caching pool of them, to avoid conflicts over who's looking at the shared list. Make the detatch event explicit.
2) If the main issue is the ability to programmatically set a combobox using an API like "selectItem", alter that method not to invoke the combobox and impose limits on what users of the combobox can write as their itemdatapath, for instance. Let me know if you want to go down either of these paths. A On Sep 22, [EMAIL PROTECTED] wrote: > This didn't seem to make it to the list for some reason so I'm > re-sending it... > > > > Actually, David met Tim at the meetup. I work with Tim at EIO but > sadly, I was unable to go to the DC meetup. > > > In the demo that Tim showed David, the datacombobox has a couple of > added methods that we needed. Here's the code... > > <method name="setItemDataPath" args="itemDataPath"><![CDATA[ > this.itemdatapath = itemDataPath; > this.refresh(); > this.selectItemAt(0); > ]]></method> > > <method name="refresh"><![CDATA[ > this._teardowncblist(); > this._setupcblist(); > ]]></method> > > Basically, we needed a way to set a new dataset on an existing > datacombobox and have it reflect the new data and automatically select > the first item as it does when initially created. I don't know if > this was the correct way to code it but it works for what we're doing. > Someone should evaluate these methods and integrate them into the > official source tree because they are invaluable for anyone who needs > to have dynamic datacomboboxes. Even without these methods, the > performance and memory use problems exist. > > > As for the shared list idea, check out the comments I added in > response to yours on the bug. To sum up... we went down the "shared > list" road about 6+ months ago with the newcombobox and abandoned it. > When you have combo select events triggering updates of the contents > of other combos, the whole thing blows up. There's no good way to be > certain that a combo is finished updating its list before the next > starts updating. > > For more pedestrian web apps, having a shared list works, but real > desktop style > applications have the need to have dynamic combos whose content > changes based on other controls, including combos, and therein lies > the problem. > > Rather than have a shared list, can't the existing list implementation > just be made less memory and CPU hungry? > > I'm not trying to put pressure on anyone, I know that Legals is of > critical importance at this time and our problems have to take a back > seat. However, consider what we are trying to do as a true test of > the future of OpenLaszlo. If what we are trying to do (develop a > replacement for a desktop app) is not possible (if not easy) to > accomplish in OpenLaszlo, then I feel it has failed. > > We currently develop in Java Swing, which as I'm sure you know, has > its share of > performance problems (as well as growing pains). We would love to > replace our current desktop product with a more flexible OpenLaszlo > based solution. > > As a small scale test, see if you can my my drilldown example work > with datacombobox... http://www.openlaszlo.org/jira/browse/LPP-1439 > > The sample code linked to the bug above uses the normal combobox. The > performance is passable when used as a standalone app, but when > combined with a larger app using a lot more memory, the performance > immediately degrades to the point where it's unusable. We had hopes > that a version using datacombobox would perform better but were unable > to get it working. The current version of our app doesn't have this > drilldown feature at all because of the performance problems. > > I'm eternally grateful for any time you or the rest of the OpenLaszlo > team can devote to what I believe are our mutual goals in the RIA space. > > ... > William Krick > Electronic Insurance Office, Inc. > > > > > > Quoting Adam Wolff <[EMAIL PROTECTED]>: > > > Hi William, > > David told me he met you at the developer meetup yesterday and asked me to > > take a look at your problem. Sadly, this is a pretty deep systemic > > problem with datacombobox. I made some notes on your Jira bug. > > > > There are a couple of things you can do though. First, if the real problem > > is with selectItemAt, we can probably patch that to avoid creating the > > floatinglist, which is what's causing the slowdown. > > > > A better alternative is to create a component that shares a single > > floating list among all of the combobox instances, and relies on data > > replication to alter the contents of that list. > > > > I did this for a project a couple of years ago. I have attached the result > > of that effort to this message. Unfortunately, this is not product quality > > code, and it's old. I didn't even try to run it on a recent OL build, but > > I'm guessing that it'll take some tweaking just to get it to compile. I'm > > sending it along in the hopes that it might be helpful to you. > > > > Sincerely, > > Adam Wolff > > Chief Software Architect > > Laszlo Systems > > > > On Sep 21, [EMAIL PROTECTED] wrote: > > > >> I just filed a bug about memory usage with datacomboboxes... > >> > >> http://www.openlaszlo.org/jira/browse/LPP-2719 > >> > >> I also included a test app. > >> > >> While exercising the test app, I think I uncovered another bug and I > >> wanted to get some input. > >> > >> Looking at the source for basedatacombobox, it appears that when the > >> control loses focus, the pop-up list is deleted to recover memory. > >> However, if the combobox is manipulated programmatically, as in my > >> sample app, the popup lists are never destroyed. > >> > >> So to demonstrate the problem, run the app, click the button and wait > >> for every combo to select. Notice that the memory usage goes *way* up > >> as I noted in the bug report. Then choose an item from the first > >> combo, then hit tab to shift focus to the next combo. There's a > >> *HUGE* CPU usage spike when you hit tab. This, I assume, is the list > >> (or lists?) being destroyed. > >> > >> We absolutely have to get some of these combo performance/memory usage > >> issues fixed if we are going to ever be able to come close to the > >> functionality of a desktop app in OpenLaszlo. > >> > >> > >> _______________________________________________ > >> 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
