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
