list grid, asynchron actions

[csillag]

I have trouble debugging a problem with a ListGrid.

I do development with FF under Linux, now I checked out app from FF under windows, and some components could not be drawn.

Instead, eclipse console says this:

Uncaught JavaScript exception [_2 is null] in http://localhost:8888/szolorg/sc/modules/ISC_Grids.js, line 2097

And the developer console says this:

22:51:06.983:INFO:Log:initialized
22:51:07.173:WARN:AutoObserver:Use addInterfaceProperties() to add methods to interface [Class AutoObserver]
22:51:12.174:INFO:Log:isc.Page is loaded
22:51:39.386:TMR7:WARN:drawing:isc_OID_139:draw() called on widget with current drawn state: handleDrawn, ignoring.
    Canvas.readyToDraw()
    Canvas.draw(_1=>undef)
    anonymous()
    Layout.layoutChildren(_1=>"resized",  _2=>0,  _3=>35)
    Canvas.$t1()
    Canvas.resizeBy(_1=>0,  _2=>35,  _3=>undef,  _4=>undef)
    Canvas.resizeTo(_1=>942,  _2=>641,  _3=>undef,  _4=>undef)
    Layout.resizeMembers(_1=>Array[3],  _2=>Array[3],  _3=>true)
    ** recursed on Layout.layoutChildren

22:51:39.389:TMR7:WARN:drawing:isc_OID_139:draw() called on widget with current drawn state: handleDrawn, ignoring.
    Canvas.readyToDraw()
    Canvas.draw(_1=>undef)
    anonymous()
    Layout.layoutChildren(_1=>"resized",  _2=>0,  _3=>35)
    Canvas.$t1()
    Canvas.resizeBy(_1=>0,  _2=>35,  _3=>undef,  _4=>undef)
    Canvas.resizeTo(_1=>942,  _2=>641,  _3=>undef,  _4=>undef)
    Layout.resizeMembers(_1=>Array[3],  _2=>Array[3],  _3=>true)
    ** recursed on Layout.layoutChildren

The component in question is a heavily customized ListGrid.

In the past few months, I had lots and lots of problems figuring out the right order of things to do when configuring my ListGrid, and until now, I thought that I have finally nailed it, but it seems I'm still not quite there..

* * *

So, the basic question is this: where can I find a comprehensive guide about the recommended order of configuration steps?

Some stuff is done immediately, some when the ListGrid is added to the layout, some when the DS is bound, some when the widget is actually drawn... it _almost_ feels hopeless.

* * *

Since I do not have a windows computer at home, I can not easily determine the cause by remove stuff until the problem is gone, so instead of this, I am asking this: what kind of error is likely to cause this:

resizing fields? reordering fields? hiding fields?
When I am supposed to do these?
When I am _not_ supposed to do these?

Thank you for your help, and sorry for the unclear question and the rant.

[Isomorphic]

The FAQ tells you to collect the stack trace from the Developer Console in IE, and look at it to see if you can spot a usage error that you can trace to your code (like passing invalid params).

As far as troubles with ListGrid init ordering, this is the first we've heard of someone being confused about it, there doesn't appear to be a need for a guide, rather, you would probably need to explain what problems you're actually having.

[csillag]

Stack trace from IE:

00:51:49.666:INFO:Log:initialized
00:51:49.885:INFO:Log:isc.Page is loaded
00:52:13.000:XRP2[E]:WARN:Log:Error:
     ''length' is null or not an object'
      in http://localhost:8888/szolorg/sc/modules/ISC_Grids.js
      at line 2097
    ListGrid.deriveFrozenFields()
    ListGrid.deriveVisibleFields()
    ListGrid.rebuildForFreeze(_1=>undef)
    ListGrid.toggleFrozen(_1=>Obj{name:UI_IDENTIFIER}, _2=>true)
    ListGrid.freezeField(_1=>"UI_IDENTIFIER")
    Layout.layoutChildren(_1=>"memberResized: (0,-352): isc_OID_278", _2=>undef, _3=>undef)
    Layout.reflowNow(_1=>"memberResized: (0,-352): isc_OID_278", _2=>6)
    anonymous()
    EventHandler.runTeas()
    EventHandler.$h2()
    Comm.$h0(_1=>Obj, _2=>"isc.Comm.performXmlTransactionReply(4, x..."[54])
    Class.fireCallback(_1=>Obj, _2=>undef, _3=>Array[2], _4=>[Class Comm], _5=>true) on [Class Timer]
    Timer.$in(_1=>"$ir63")
    anonymous()
        "isc.Timer.$in('$ir63')"



00:59:00.811:XRP7[E]:WARN:Log:Error:
    ''this.frozenBody' is null or not an object'

    in http://localhost:8888/szolorg/sc/modules/ISC_Grids.js
    at line 1130
    ListGrid.setBodyFieldWidths(_1=>Array[11])
    ListGrid.$45m(_1=>"resized", _2=>-205, _3=>0)
    ListGrid.layoutChildren(_1=>"resized", _2=>-205, _3=>0)
    Canvas.$t1()
    Canvas.resizeBy(_1=>-205, _2=>0, _3=>undef, _4=>undef)
    Canvas.resizeTo(_1=>737, _2=>598, _3=>undef, _4=>undef)
    Layout.resizeMembers(_1=>Array[5], _2=>Array[5], _3=>false)
    Layout.layoutChildren(_1=>"resized", _2=>-205, _3=>0)
     ** recursed on Canvas.$t1

Can you pick something obvious?

[Isomorphic]

Did you edit this stack trace, or have you been adding JavaScript overrides of some kind? The call layoutChildren -> freezeField does not exist.

Was this a nightly? If so, from what date?

This suggests that after a DSRequest comes back, you are dynamically freezing a field. Is the grid drawn at this moment?

[csillag]

Did you edit this stack trace, or have you been adding JavaScript overrides of some kind?

No, and no. (Btw, editing that stack trace before posting would _evil_. Why would anyone to that?)

The call layoutChildren -> freezeField does not exist.

I am not going to argue about that :)

Was this a nightly? If so, from what date?

Yes. I am not sure about the exact date, probably 2010-02-10 or 2010-02-14 (I have already upgraded from it.) Will soon test again with 2010-02-19.

This suggests that after a DSRequest comes back, you are dynamically freezing a field.

That's possible. Is that illegal?

Is the grid drawn at this moment?

That's also possible.

[Isomorphic]

It's evil, but a surprising amount of time people omit data that they think is not relevant (and are wrong).

It's fine to freeze a field after an RPC or on an undrawn grid, and if it's crashing, it would be a bug. But for a nightly snapshot, support procedures are different: please remember that anything you encounter could be something checked in at 2pm and fixed at 2:01pm, so if you find something that appears to be a bug, upgrade to the latest then please submit a testcase if the problem is still there.

[csillag]

To be more specific:

I am doing this kind of formatting when the DS is bound and the grid is drawn. (Both are async events, because I am loading the DS with the DataSourceLoader servlet.) The formatting is triggered either by the callback of the DS loading, or the draw handler of the ListGrid, whichever happens later. (I do it this way because when I checked last time, specifying frozen in the DS XML caused a crash.)

* * *

I will re-post the results with the latest version soon.

[csillag]

Here are the IE results with the latest build.
(Version "SC_SNAPSHOT-2010-02-19/PowerEdition Deployment (built 2010-02-19)" - I got the download link from you today)

The good news is that now it works with FF.

02:23:05.607:INFO:Log:initialized
02:23:05.961:INFO:Log:isc.Page is loaded
02:24:44.039:MUP9[E]:WARN:Log:Error:
    ''length' is null or not an object'
    in http://localhost:8888/szolorg/sc/modules/ISC_Grids.js
    at line 2097
    ListGrid.deriveFrozenFields()
    ListGrid.deriveVisibleFields()
    ListGrid.rebuildForFreeze(_1=>undef)
    ListGrid.toggleFrozen(_1=>Obj{name:UI_IDENTIFIER}, _2=>true)
    ListGrid.freezeField(_1=>"UI_IDENTIFIER")
    Layout.layoutChildren(_1=>"initial draw", _2=>undef, _3=>undef)
    Layout.drawChildren()
    Canvas.draw(_1=>undef)
    ** recursed on Layout.layoutChildren

To repeat this information, the process with involves freezing the field is either triggered by the onDraw handler of the ListGrid, or the completion of the loading of the DataSource definition, whichever happens later. (Probably the drawing, looking at the stack.) The following threads contain the description of the error(s) forcing me to do this:
http://forums.smartclient.com/showthread.php?t=9719, http://forums.smartclient.com/showthread.php?t=9714

[Isomorphic]

Both of the errors you were working around were temporary regressions that have been fixed (if you disagree, please show a standalone test case). So if you had a more straightforward approach before, go back to that.

Otherwise if you want to continue with your current approach, there's not really enough information to reproduce the problem, so we would need a test case. If it's as simple as you think, it should be reproducible with a trivial modification of a Showcase example.

[csillag]

Both of the errors you were working around were temporary regressions that have been fixed (if you disagree, please show a standalone test case).

I have tried going back the the previous, easier way, but the crash is still there. Right now, I am on a very tight schedule (inhuman, in fact), so right now I can not allow spending time with preparing a test case, but I will revisit this when things calm down a bit.

Otherwise if you want to continue with your current approach, there's not really enough information to reproduce the problem, so we would need a test case. If it's as simple as you think, it should be reproducible with a trivial modification of a Showcase example.

The above applies to this, too.