Entering invalid number in Number Field, JavaScritpException

GXT 3.0.0-beta2

When I enter an invalid number in a number field, for example "3.4.5.6", instead of the the mark invalid actually getting called, it throws an exception.

Caused by: com.google.gwt.core.client.JavaScriptException: (TypeError): Object doesn't support this property or method
at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:248)
at com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:136)
at com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:561)
at com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java:269)
at com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:91)
at com.google.gwt.dom.client.Node$.appendChild$(Node.java)
at com.sencha.gxt.widget.core.client.form.error.SideErrorHandler.markInvalid(SideErrorHandler.java:116)
at com.sencha.gxt.widget.core.client.form.Field.markInvalid(Field.java:446)
at com.sencha.gxt.widget.core.client.form.Field.markInvalid(Field.java:253)
at com.sencha.gxt.widget.core.client.form.Field.forceInvalid(Field.java:128)
at com.sencha.gxt.widget.core.client.form.NumberField.onCellParseError(NumberField.java:86)
at com.sencha.gxt.widget.core.client.form.ValueBaseField$1.onParseError(ValueBaseField.java:44)
at com.sencha.gxt.widget.core.client.event.ParseErrorEvent.dispatch(ParseErrorEvent.java:85)
at com.sencha.gxt.widget.core.client.event.ParseErrorEvent.dispatch(ParseErrorEvent.java:1)
at com.google.gwt.event.shared.GwtEvent.dispatch(GwtEvent.java:1)
at com.google.web.bindery.event.shared.EventBus.dispatchEvent(EventBus.java:40)
at com.google.web.bindery.event.shared.SimpleEventBus.doFire(SimpleEventBus.java:193)
at com.google.web.bindery.event.shared.SimpleEventBus.fireEvent(SimpleEventBus.java:88)
at com.google.gwt.event.shared.HandlerManager.fireEvent(HandlerManager.java:127)
at com.sencha.gxt.cell.core.client.AbstractEventInputCell.fireEvent(AbstractEventInputCell.java:41)
at com.sencha.gxt.cell.core.client.form.TriggerFieldCell.finishEditing(TriggerFieldCell.java:205)
at com.sencha.gxt.widget.core.client.form.Field.finishEditing(Field.java:205)
at com.sencha.gxt.widget.core.client.grid.editing.GridInlineEditing.onEnter(GridInlineEditing.java:283)

Actually, something you reminded me from my other post and our custom BigDecimalPropertyEditor made me think that was the issue (even though it wasn't part of the stack trace, that GWT provided). It was in my parseString() method.

So, this is a non-issue, but rather I need need to do more investigation if I get an UmbrellaException; I would have expected a NumberFormatException from my BigDecimalPropertyEditor.

I believe that all exceptions thrown by NumberPropertyEditor.parseString are ignored, to allow multiple ways of parsing an inputted value. If you want custom behavior in that area, consider directly overriding the parse(String) method, and throwing a ParseException to make the error visible.

Of course, if you are calling parseString(String) yourself, then you need to catch any exception that it emits.

Hi Colin, I just tried it again on the 3.0.1 examples and it is working fine. I'm still puzzled why I'm having this issue.

I'm using the UI binder approach, without any customisation. I noticed that I am using an HTML Panel parent container where the examples are using a vertical panel. Does this have any effect? I'm also not using any container and widget tags like in the example.Capture.PNG
Initially I used the NumberField of type BigDecimal but changed it to Integer to be closer to the example provided (i.e. age field) but I'm still getting the same issue. There is no stack trace, just an error icon with no message.

For my scenario, I just entered ... as input to the field and was expecting a validation error like below:Capture.PNG

It is hard to say what could be causing your issue without a runnable code sample. The error tooltip is generated by the side error handler - if you are using different error support, something else might be happening instead.

Can you put together a class implementing EntryPoint that can be run on its own to demonstrate the issue?

I could try to run it, but if the bug doesn't occur, then where are we left? Verify that the bug still exists, and please document the steps you are using to reproduce this issue, expected and actual results, as well as the browser you are using.