Announcement

**pH4Lk0n** · 31 Jan 2011, 09:38

Hi,

Does anybody seen this error?
Don't know where to look because of it's irregularity.
Best regards

**uranio255** · 23 Mar 2011, 08:30

Hi pH4Lk0n,

Just to let you know that I am experiencing the same issue you are describing with SmartGWT 2.4. I would say that it does, indeed, come from the Calendar component itself.

In my case, however, everything goes fine the first time I open a window with the a Calendar inside. I can rearrange events in a weekly view (eg: move them about, change their time length, etc). If I close it and reopen it again (trying to show a Calendar with the same informacion again) and then I try to rearrange any events it hangs everytime.

I have used the SmartGWT console and it comes up with the same message "this.mainView is undefined".

This is the full stack trace:

Code:

17:33:22.853:XRP3:WARN:Log:TypeError: this.mainView is undefined
    Calendar.dayViewSelected()
    Calendar.refreshSelectedView()
    Calendar.dataChanged()
    anonymous("update", {Obj}, 0, [object Array], undef)
    ResultSet._doneChangingData()
    ResultSet.handleUpdate(_1=>"update",  _2=>[object Array],  _3=>undef,  _4=>{Obj})
    ResultSet.dataSourceDataChanged(_1=>{Obj},  _2=>{Obj})
    anonymous({Obj}, {Obj})
    DataSource.updateCaches(_1=>{Obj},  _2=>{Obj})
    [c]DataSource.handleUpdate(_1=>{Obj},  _2=>{Obj})
    DataSource.fireResponseCallbacks({Obj}, {Obj}, {Obj}, {Obj})
    DataSource._completeResponseProcessing({Obj}, {Obj}, {Obj}, {Obj}, {Obj})
    DataSource._handleJSONReply({Obj}, [object Array], {Obj})
    unnamed({Obj}, "{\"response\":{\"data\":null,\"endRow\"..."[ 89], {Obj})
    [c]Class.fireCallback(_1=>{Obj},  _2=>"rpcResponse,data,rpcRequest",  _3=>[object Array],  _4=>{Obj},  _5=>undef)
    [c]Class.fireCallback(_1=>{Obj},  _2=>"rpcResponse,data,rpcRequest",  _3=>[object Array])
    anonymous(a=>{Obj},  b=>{Obj},  c=>{Obj},  d=>"{\"response\":{\"data\":null,\"endRow\"..."[ 89])
    unnamed({Obj}, {Obj}, {Obj}, "{\"response\":{\"data\":null,\"endRow\"..."[ 89])
    [c]RPCManager.fireReplyCallbacks(_1=>{Obj},  _2=>{Obj})
    [c]RPCManager.performOperationReply(_1=>{Obj},  _2=>{Obj})
    RPCManager._performTransactionReply(12)
    [c]RPCManager.performTransactionReply(_1=>12,  _2=>"{\"response\":{\"data\":null,\"endRow\"..."[ 89],  _3=>undef)
    anonymous(12, [object XMLHttpRequest])
    [c]Class.fireCallback(_1=>"isc.RPCManager.performTransactionReply(..."[ 67],  _2=>"transactionNum,results,wd",  _3=>[object Array])
    [c]Comm.performXmlTransactionReply(_1=>12,  _2=>[object XMLHttpRequest])
    anonymous([object XMLHttpRequest])
    [c]Class.fireCallback(_1=>"isc.Comm.performXmlTransactionReply(12,..."[ 57],  _2=>"xmlHttpRequest",  _3=>[object Array],  _4=>[object XPCCrossOriginWrapper],  _5=>true)
    Comm._fireXMLCallback([object XMLHttpRequest], "isc.Comm.performXmlTransactionReply(12,..."[ 57])
    unnamed([object Event])
    unnamed()

So far I have not found a workaround, but I�ll surely post it here as soon as I find one.

Kindest regards,

**Isomorphic** · 23 Mar 2011, 08:45

We can't reproduce this, but just for context, it suggests that possibly some other component on the page has just completed a save at a moment when the Calendar is not drawn.

**Isomorphic** · 24 Mar 2011, 01:12

If you grab the latest nightly we've added a null check that *might* avoid this issue (but we can't reproduce it, so we don't know for sure yet).

**uranio255** · 24 Mar 2011, 01:29

Thank you very much for your reply.

At the moment we are using the LGPL version of SmartGWT.

The latest build I found at http://www.smartclient.com/builds/SmartGWT/2.x/LGPL is dated 21/3/2011. I am assuming this is not the one where you added the change so I will wait until a more recent one comes up.

If it does not solve the problem I will try to post a complete test case so we can continue from there.

**uranio255** · 31 Mar 2011, 23:27

I finally tried the nightly build dated 2011-03-28 (SC_SNAPSHOT-2011-03-28/LGPL Development Only), but the problem is still there although it comes out with a slightly different error messsage.

After a lot of narrowing down I think I may have found the (one of them?) root of the issue.

PROCEDURE:

1) I open one of our windows and add a single databound Calendar object in it.

Code:

oWindow.setWidth(750);
oWindow.setHeight(500);

    oCalendar.setDataSource(EventsDS.getInstance());

        TextItem codeField = new TextItem("code");
        codeField.setValue(codigoInventariable);
        codeField.setVisible(false);

        TextAreaItem descriptionField = new TextAreaItem("description");
        TextItem nameField = new TextItem("name");

    oCalendar.setEventDialogFields(codeField);
    oCalendar.setEventEditorFields(nameField, descriptionField, codeField);

oWindow.addItem(oCalendar);
oWindow.draw();

2) Then I close the window.
3) Then I open the same window again and try to change the date or length of any event. The cursor turns into a sandclock waiting icon. After this point, the application will not respond to clicks or any other interaction event (everything stalls). The only way out is reloading. The SmartClient Development Console shows a slightly different messsage:

Code:

09:56:07.239:XRP2:WARN:Log:TypeError: this.weekView is undefined
    Calendar.refreshSelectedView() @ es.europroyectos.epdgest.Main/sc/modules/ISC_Calendar.js:39
    Calendar.dataChanged() @ es.europroyectos.epdgest.Main/sc/modules/ISC_Calendar.js:38
    anonymous("update", {Obj}, 0, [object Array], undef) @ es.europroyectos.epdgest.Main/sc/modules/ISC_Core.js:44
    ResultSet._doneChangingData() @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:1352
    ResultSet.handleUpdate(_1=>"update",  _2=>[object Array],  _3=>undef,  _4=>{Obj}) @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:1349
    ResultSet.dataSourceDataChanged(_1=>{Obj},  _2=>{Obj}) @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:1345
    anonymous({Obj}, {Obj}) @ es.europroyectos.epdgest.Main/sc/modules/ISC_Core.js:47
    DataSource.updateCaches(_1=>{Obj},  _2=>{Obj}) @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:335
    [c]DataSource.handleUpdate(_1=>{Obj},  _2=>{Obj}) @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:258
    DataSource.fireResponseCallbacks({Obj}, {Obj}, {Obj}, {Obj}) @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:533
    DataSource._completeResponseProcessing({Obj}, {Obj}, {Obj}, {Obj}, {Obj}) @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:532
    DataSource._handleJSONReply({Obj}, [object Array], {Obj}) @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:391
    unnamed({Obj}, "{\"response\":{\"data\":null,\"endRow\"..."[ 89], {Obj}) @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:402
    [c]Class.fireCallback(_1=>{Obj},  _2=>"rpcResponse,data,rpcRequest",  _3=>[object Array],  _4=>{Obj},  _5=>undef) @ es.europroyectos.epdgest.Main/sc/modules/ISC_Core.js:297
    [c]Class.fireCallback(_1=>{Obj},  _2=>"rpcResponse,data,rpcRequest",  _3=>[object Array]) @ es.europroyectos.epdgest.Main/sc/modules/ISC_Core.js:393
    anonymous(a=>{Obj},  b=>{Obj},  c=>{Obj},  d=>"{\"response\":{\"data\":null,\"endRow\"..."[ 89]) @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:1174
    unnamed({Obj}, {Obj}, {Obj}, "{\"response\":{\"data\":null,\"endRow\"..."[ 89]) @ es.europroyectos.epdgest.Main/75C81E6BC93E04FF6624B3691E8D6FB1.cache.html:7762
    [c]RPCManager.fireReplyCallbacks(_1=>{Obj},  _2=>{Obj}) @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:1177
    [c]RPCManager.performOperationReply(_1=>{Obj},  _2=>{Obj}) @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:1173
    RPCManager._performTransactionReply(3) @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:1169
    [c]RPCManager.performTransactionReply(_1=>3,  _2=>"{\"response\":{\"data\":null,\"endRow\"..."[ 89],  _3=>undef) @ es.europroyectos.epdgest.Main/sc/modules/ISC_DataBinding.js:1142
    anonymous(3, [object XMLHttpRequest]) @ es.europroyectos.epdgest.Main/sc/modules/ISC_Core.js:38
    [c]Class.fireCallback(_1=>"isc.RPCManager.performTransactionReply(..."[ 67],  _2=>"transactionNum,results,wd",  _3=>[object Array]) @ es.europroyectos.epdgest.Main/sc/modules/ISC_Core.js:297
    [c]Comm.performXmlTransactionReply(_1=>3,  _2=>[object XMLHttpRequest]) @ es.europroyectos.epdgest.Main/sc/modules/ISC_Core.js:1193
    anonymous([object XMLHttpRequest]) @ es.europroyectos.epdgest.Main/sc/modules/ISC_Core.js:38
    [c]Class.fireCallback(_1=>"isc.Comm.performXmlTransactionReply(3, ..."[ 56],  _2=>"xmlHttpRequest",  _3=>[object Array],  _4=>[object Proxy],  _5=>true) @ es.europroyectos.epdgest.Main/sc/modules/ISC_Core.js:297
    Comm._fireXMLCallback([object XMLHttpRequest], "isc.Comm.performXmlTransactionReply(3, ..."[ 56]) @ es.europroyectos.epdgest.Main/sc/modules/ISC_Core.js:1169
    unnamed([object Event]) @ es.europroyectos.epdgest.Main/sc/modules/ISC_Core.js:1181
    unnamed() @

POSSIBLE CAUSE

We don�t use smartgwt Window objets but our own, they inherit from standard SmartGWT windows.

Our window objects have the following close handler:

Code:

oWindow.addCloseClickHandler(new CloseClickHandler() {
    public void onCloseClick(CloseClientEvent event) {
        oWindow.markForDestroy();
    }
});

If I remove this window handler, the issue gets solved.

This makes me think that possibly my close click handler does not really "clean up" and closes the window properly (at least when they have a calendar component) even though the handler is extremelly simple.

Is there much difference between what my close handler does and the standard procedure that SmartGWT uses to destroy a Window object?

**pH4Lk0n** · 12 Apr 2011, 15:11

Hi,

I don't think that's a reason for this problem.
I use Calendar on a tab on main page container and even showing it only once.
Still got this exception on random occasions.
It's rarer when I started to use my own editor windows (the code to accomplish this I took from this forum) but it still exists.
So far I noticed more often exceptions when there is a problem committing with validation on server side.
Don't know what to do next with it.

Best regards

**Isomorphic** · 12 Apr 2011, 15:27

The stack trace and additional information made the problem clear. It resulted from destroy()ing a Calendar that had a DataSource and had loaded data, then later updating an event that had existed in that Calendar from some other widget. Fixed now.

Announcement

Calendar Exception

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment