Thanks, Derrell.
I did make the change you suggest after reading Stefan's message.
I also discovered that this line...
item = new
qx.ui.form.ListItem(result[tr]["Name"],"",result[tr]["Key"]);
needed "var" added to get it to work in IE6, as in...
var item = new
qx.ui.form.ListItem(result[tr]["Name"],"",result[tr]["Key"]);
That's a lot of "item" variables, I would think. Should I create the
object once and then reuse it for each entry, or is it OK to create a
new object in each loop pass?
These two changes allowed the SelectBox objects to populate from the RPC
calls successfully, resolving the problem with the RPC timeouts. I
still seem to get some lingering script causing my page to hang when I
try to navigate away from the page, and I'm not sure why that's
happening - the RPC calls are complete by this time. Firefox reports
that a script is still running and asks me to stop it, while IE6 says
that a script is causing the page to run slowly and asks me if I want to
abort the script. Same issue but different messages in the two
browsers. Maybe I need to dispose of the RPC objects or the RPC
handlers before exiting the Application.js script? Or, is it possible
that Qooxdoo is interfering with native Javascript that is included in
my HTML page?
I also still have the other issues with SelectBox, related to the mis-
positioning of the SelectBox objects. Now that the SelectBox objects
are populating, I see two problems with them. First, the previously
mentioned problem where the SelectBox appears in the page with the left-
hand edge centered in the layout container (generated by Qooxdoo) until
I click on each of them, where the SelectBox object then repositions
correctly. However, the selected entry that is displayed is also not
left-justified within the widget space - the starting position of the
text varies with the selected entry. The entries in the dropdown list
appear correctly. Shorter text entries start closer to the middle,
while long text entries get pushed farther to the right. It's like the
SelectBox widget is inserting a number of spaces in front of the
selected text based on the length of the selected list option text.
What gives?
Finally, if anybody can tell me how to work around the "bleed-thru"
issue (z-index bug in IE6?) with native HTML Select lists, that would be
helpful so that I wouldn't have to use the Qooxdoo SelectBox objects in
the first place. I suspect this might not be possible, but a
verification would be helpful so I can quit looking for an answer.
Thanks,
Gene
On Mon, 2009-04-06 at 13:33 -0400, Derrell Lipman wrote:
> On Mon, Apr 6, 2009 at 11:29 AM, Stefan Volbers <[email protected]>
> wrote:
>
> Hi Gene,
>
> I do something similar in a standard qx application,
> populating several
> form elements with rpc result data.
> Works for me with any browser I could test, and actually is
> working fine
> at my customer's place.
>
> I believe the problem is that you use for ( in ) on the rpc
> result with
> IE6. This has been discussed here before, but I can't find it
> right now.
> Qooxdoo, for reasons not on my radar right now, extends the
> for/in, but
> that doesn't work properly on some data types (I believe it
> somewhat
> fails on objects, but is clean on numerical arrays; the effect
> is that
> some property data or even methods get iterated; as a result i
> usually
> had three empty elements in a select box).
>
>
> for/in works fine for objects, which is what it's intended for. If you
> use for/in on arrays, Firefox iterates over only the members values of
> the object while IE iterates over both the members and any functions
> which have been added to the prototype of Array. For historical
> reasons (which are being remedied currently with the qx.base.Array
> classes), qooxdoo added methods to Array's prototype to make Array
> instances provide the same member functions in all of the various
> browsers. (This is contrary to the published claims of qooxdoo that it
> does not extend native types, which I expect is why the current work
> to remedy that is ongoing.)
>
> There's really no reason to use for/in on arrays anyway. Although non-
> integer indexes work on arrays, that's really just adding object
> properties, not technically adding array members. It's as easy to use
>
> for (var i = 0; i < arr.length; i++)
>
> as
>
> for (var name in arr)
>
> and is more reliable.
>
> Derrell
>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
