Announcement

**Isomorphic** · 3 Sep 2013, 10:04

We see the problem and are investigating.

**jan.swaelens** · 9 Sep 2013, 21:41

Thanks, I just spent a few days tracking down another upgrade related issue that also seems to be caused by IDManager functionality. This is the case:

In our custom FooListGrid we have some custom code that fires after the grid went into edit mode, we retrieve the form of the edited record there using our following method:

Code:

public native DynamicForm getEditForm() /*-{
	var self = this.@com.smartgwt.client.widgets.BaseWidget::getOrCreateJsObj()();
	if (!self.getEditForm) return null;
	var form = self.getEditForm();
	return @com.smartgwt.client.widgets.form.DynamicForm::new(Lcom/google/gwt/core/client/JavaScriptObject;)(form);		
}-*/;

It accesses the local edit form of the grid - worked fine until now.

What's important here is the last line, where we call the constructor of DynamicForm from JS to wrap the obtained object into it's typed form.
This is where things go wrong, the new code located in the DynamicForm Java wrapper does as follows:

Code:

    public DynamicForm(JavaScriptObject jsObj){
        scClassName = "DynamicForm";
        setJavaScriptObject(jsObj);        
    }

and especially:

Code:

    public void setJavaScriptObject(JavaScriptObject jsObj) {
        internalSetID(jsObj);
        JSOHelper.setObjectAttribute(jsObj, SC.REF, this);
        onBind();
    }

Before it did the following:

Code:

    public DynamicForm(JavaScriptObject jsObj){
        scClassName = "DynamicForm";
        setJavaScriptObject(jsObj);
        
    }

and especially:

Code:

    public void setJavaScriptObject(JavaScriptObject jsObj) {
        id = JSOHelper.getAttribute(jsObj, "ID");
    }

Somehow the new logic causes the original form to be replaced by a new one, after which the fields are gone and the nullpointers we where having on the form items occur (the result was that the grid went into edit mode but locked up completely afterwards).
I'm not sure that this (adapted logic in the constructor) was intended to work this way, I assume not.

We can adapt the code in our method to the following:

Code:

public native DynamicForm getEditForm() /*-{
	var self = this.@com.smartgwt.client.widgets.BaseWidget::getOrCreateJsObj()();
	if (!self.getEditForm) return null;
	var form = self.getEditForm();
	return @com.smartgwt.client.widgets.form.DynamicForm::getOrCreateRef(Lcom/google/gwt/core/client/JavaScriptObject;)(form);
}-*/;

Which cures the ListGrid edit issue. The only problem is, what with all other calls to that particular contructor. And are other constructors for other objects impacted as well? Please advise what we should do here.

**Isomorphic** · 10 Sep 2013, 01:46

The SGWT Class constructors taking a JavaScript object were intended only for internal use by our object life cycle management code, and not for customer use. The public scope is only due to access restrictions between packages in Java.

The suggestion to use getOrCreateRef() will work, but we recommend a newly added set of APIs, asSGWTComponent(). Currently these are in SGWT 4.1d only, but we'll try to get them merged back to SGWT 4.0p for the next nightly build. Functionally the new APIs do the same thing as getOrCreateRef() but provide more friendly warnings.

The above applies to all Canvas classes - you should not be calling new on the JavaScriptObject constructor directly.

**jan.swaelens** · 10 Sep 2013, 02:49

Thanks for the information, we simply did not know that. I'll wait for the changes to come trough and adapt our code to the new API directly.Thanks!

**jan.swaelens** · 16 Sep 2013, 00:02

Can we have an ETA on this fix please, we would like to be able to upgrade to a recent build soon. Thanks.

**Isomorphic** · 16 Sep 2013, 14:13

The asSGWTComponent() APIs were added for SGWT 4.0p the day it was promised, so that's already in. The crash for MenuItem.getSubmenu() should have been fixed long ago, though we're going to deprecate the MenuItem.getSubmenu() API and instead provide Menu.getSubmenu() as that's really logical place to provide the correct support. That will happen this week.

Whether you need to switch from the deprecated API to get proper functionality depends on how you're using the obtained Menu, and as you haven't provided the code, we can't speculate.

**jan.swaelens** · 16 Sep 2013, 22:00

Hi,

Thanks, I assumed that you would follow up to state that it was added - you guys are terrific!

We are using the call only to get a handle to the menu to keep a reference to it - as it is a customized implementation of Menu we need to do some additional cleaning up when the menu is destroyed. I'm pretty sure that the api change will also work.

cheers.

Announcement

Nullpointer in IDManager

Comment

Comment

Comment

Comment

Comment

Comment

Comment