Unable to start the application after update to latest 3.1

[hin3x]

Hello,

After taking the latest v8.3p_2013-03-15/Pro Deployment 2013-03-15 we are unable to start our application.

We get this error: Error :Cannot change configuration property '_autoAssignedID' to true after the component has been created.

It happens when a canvas is created:

com.smartgwt.client.widgets.BaseWidget.error(BaseWidget.java:647)
com.smartgwt.client.widgets.BaseWidget.error(BaseWidget.java:635)
com.smartgwt.client.widgets.BaseWidget.setAttribute(BaseWidget.java:895)
com.smartgwt.client.widgets.BaseWidget.<init>(BaseWidget.java:108)
com.smartgwt.client.widgets.Canvas.<init>(Canvas.java:106)

And originates from here:

    public BaseWidget() {        
        internalSetID(SC.generateID(getClass().getName()));
        setAttribute("_autoAssignedID", true, false);
    }

Thanks

[Isomorphic]

Can you provide some sample code that will reproduce the issue? It doesn't seem to happen with out SGWT showcase samples.

[klausv]

Our cause & solution for the problem

Hi,

since I just stumbled upon the same problem, here's the reason why the effect appeared in our application:

We created one LayoutSpacer object and were using it multiple times in one SectionStackSection.setControls() call. (This led to SmartGWT (rightfully) warning about colliding IDs, perhaps hin3x experiences similar messages?)

I'm just guessing here, but it seems that SmartGWT tried to set the ID of the LayoutSpacer a second time, assuming that it doesn't get repeatedly fed the same control in a setControls() call, which then in turn led to the reported error.

As soon as I cleaned up by using distinct LayoutSpacers, the problem vanished.

Hope it helps.
Klaus

[hin3x]

Hello,

Well it might be a variant of your case, but it is indeed caused by the fact that SGWT believes that the Canvas is already created because it can find a reference for its ID.

This is the scenario:
- we create a Canvas X
- we destroy this Canvas X by calling its destroy method
...
- a Canvas Y is created which re-uses the destroyed Canvas ID (which is ok as it was unregistered by the destroy) but fails on the 'allowed post create' check. This seems to be caused by the 'isCreated' operation which returns true (which is not correct).

    public native boolean isCreated()/*-{
        var id = this.@com.smartgwt.client.widgets.BaseWidget::getID()();
        var obj = $wnd.window[id];
        return id != null && obj != null && obj !== undefined && $wnd.isc.isA.Canvas(obj) === true;
    }-*/;

    public native void destroy() /*-{
        var self = this.@com.smartgwt.client.widgets.BaseWidget::getOrCreateJsObj()();
        var id = self.ID;
        self.__destroy();
        @com.smartgwt.client.util.IDManager::unregisterID(Ljava/lang/String;)(id);
        this.@com.smartgwt.client.widgets.Canvas::onDestroy()();
    }-*/;

Is $wnd.window[id] properly cleared by calling destroy or should we call some other code to achieve that?

As a temporary workaround I disabled the call to destroy, this got me a bit further but the error also appears for other cases where we call destroy on components.

thanks

[hin3x]

I have been trying to create a simple repro for this but so far no luck. I am starting to think that maybe the destroy is not actually removing the canvas from '$wnd.window' for some reason. Any hints on how to debug that further?

Are you aware of a change between v8.3p_2013-02-13/Pro Deployment (built 2013-02-13) and the current build that might cause this to happen all at once? Maybe that can give us a clue.

The 2nd case we are having is as follows (with the destroy commented out which causes the initial issue):
- we create a bunch of canvas items like this and add them to a form using 'setItems':

CanvasItem arrowIcon = new CanvasItem();
arrowIcon.setCanvas(new Img(url));
arrowIcon.setAutoDestroy(true);

We add the form to a values manager which seems to result in 'destroy' being called on the Img instances (noticed in a stack trace) - a bit later other images are created and they attempt to re-use the id of this destroyed Img instance. The result is the well known error.

Just like the other issue, this also seems caused by a destroy not completely freeing up the reference to the original item.

[Isomorphic]

We have so far been unable to reproduce your issue in a current build of SGWT 3.1p, despite trying both dev mode and compiled mode. In fact, a tight loop creating, drawing (to ensure JS object creation), and destroying a Button assigned the same ID in SGWT works fine with no errors. What's more, checking window["FOO"] (for a widget named FOO) reveals that the JS destroy() call is correctly cleaning up window["FOO"] when the SGWT destroy() function calls it. So that doesn't appear to be a problem - at least we don't see it.

So,we're going to need some way to reproduce this to be able to provide a fix for you - a modified showcase sample would be fine, or a standalone app based on our BuiltInDS.java file.

A simple test you could perform is -- see if you can have your code run in separate pieces triggered by Button ClickHandlers. Then after the Canvas is destroyed but before it's recreated, check window{'FOO"] in the web console (or firebug) to see whether it's null as it should be. If it's not possible to create separate pieces like that, you could write a JSNI routine to call console.log($wnd.window(["FOO"]);.

I didn't see mention of your browser or OS - can you provide that information? And from your error reports I assume you're running SGWT in dev mode - if not, please say so.

[hin3x]

Thanks, this is indeed in dev mode. I am experimenting with the logging to maybe find more clues.