Custom editor doesn't seem to be recognized with listgrid startEditingNew

[anstaafl]

SmartGWT version 3.0 July 4, 2012 build

I have a listgrid datetime field where only the time is modifiable.
I created a custom editor for this and set it via field.setEditorType.

All of it works perfectly when editing an existing record with startEditing(row, col, false).

The odd behavior is when a new row is added.
I can set the time with the picker and the custom textitem I use picks up the change.
However, when I commit the record (hit return), the value from the formitem is not pulled into the listgrid.

I know this is the case because I seeded starteditingnew with a default record containing a datetime. When I change the time and hit return, the original time is what gets sent to the server.

The only thing I can think of is the "new" editor isn't aware of the custom editor and isn't pulling the value from it.

Is there something I need to override when editing a new record?

[Isomorphic]

Editing a "datetime" value with an editor intended for editing just "time" values will not work. See the DateAndTimeStorage overview for details.

[anstaafl]

I am using the entire datetime field.
I am only displaying the time portion of it with a timedisplayformat.
The picker is passed the entire Date object.
The user selects the time they want and it's adjusted in the date object and passed back to the textitem editor form item.

As I said, this works perfectly when editing an existing record.
It almost seems like startEditingNew has no clue the custom editor exists and so doesn't pull the value from it.

[Isomorphic]

Once again, it would be incorrect for eg a TimeItem to be passed a value from a field of type "datetime".

If you think there's some unrelated problem, you need to provide a minimal, ready-to-run test case - there's no way we can spot the bug in a prose description.

[anstaafl]

I was afraid you were going to say that. ;-)
I'll see if I can get a test case together.
I would then just respond to this thread and paste in the test case?

[Isomorphic]

Yes, when you have something ready-to-run, minimal, and that seems to clearly demonstrate a bug or where you can't find an API call that does what you want, go ahead and post it here.

[anstaafl]

Will an exported/zipped eclipse project work for you?
I'm not really sure how to go about this any other way.

[Isomorphic]

Very simple: create a .java file that can be dropped into the sample projects.

We won't look at a .zipped project - many many things could be wrong with it that are not framework issues.

[anstaafl]

You mean the sample projects provided in the product download?

i.e. The same format with PanelFactory etc?

[Isomorphic]

Yes, the sample projects in the product download.

PanelFactory is involved in the Showcase only. Don't create a new Showcase example, just create a .java file you can drop into one of the sample projects.

[anstaafl]

Hopefully this is what you want.
Everything is contained within the onModuleLoad.

[Isomorphic]

Take a look at the docs for setEditorType(). You need to be following special rules for how you obtain references to the FormItem. Currently you are trying to store it in an instance variable on the FormItem class (editItem), you need to pass the instance to your custom dialog instead.

[anstaafl]

I'll take a look.
Thank you for your patience.

[anstaafl]

I hope I'm reading this correctly and point 2 is what you were referring to...

To store custom instance variables, you must use FormItem.getAttribute()/setAttribute() (or their type-specific variants). You cannot store and retrieve instance variables via "this" - "this.someVariable = 5" will not work.

So instead of the callbacks.
Just pass the formitem (this) to the custom dialog.

The custom dialog gets FormItem object (item).
When the custom dialog exits, with a date object (exitDate),
it sets item.setAttribute("time", exitDate);?

[Isomorphic]

That statement applies in the sense that instance variables aren't allowed for FormItems that work with setEditorType(). However you don't actually seem to have a reason to have instance state on the FormItem at all; you could just pass the FormItem to the picker and when the picker fires it's event to save, it could call something on the FormItem - no instance state required.