CellTable - How to programmatically start editing a cell.

[Alfredo Quiroga-Villamil]

Scenario is as follows:

- CellTable with a column containing an EditTextCell.

- Add new record to the ListDataProvider.

- I can edit and do all the good stuff by hand to the newly added record in the CellTable.

Requirement:

- Programmatically call a starttEdit on say the first cell of the newly created row/record.

My investigation results:

After going through the code and investigating, all roads seem to point to ViewData in EditTextCell. Specifically, ViewData in EditTextCell has setEditing(boolean) which should do the trick. However, ViewData has package access.

Before I go and start to override, copy/paste things to be able to access the ViewData member I need, I figured I ask first since this seems like a basic operation when adding new records to a CellTable. I am thinking that I am very likely missing something.

Any help/pointers are appreciated.

Thanks,

Alfredo

--
Alfredo Quiroga-Villamil

AOL/Yahoo/Gmail/MSN IM:  lawwton

[R.K.P. Pisters]

I remember facing the same problem some time ago. In the end I just dispatched a click event on the cell, like so:

Scheduler.get().scheduleDeferred(new Scheduler.ScheduledCommand() {

    @Override

    public void execute() {

int i = getRowIndex();

int j = getColumnIndex();

NativeEvent clickEvent = Document.get().createClickEvent(1, 0, 0, 0, 0, false, false, false, false);

cellTable.getRowElement(i).getCells().getItem(j).dispatchEvent(clickEvent);

    }

});

I realize this is not a very elegant solution, all the more so since dispatching the event will fail in case you're using a SelectionCell instead of an EditTextCell (see my question here). So if anybody has a better idea, please share it with us.

Ralf

[Alfredo Quiroga-Villamil]

Ralf:

Appreciate the response. It sure looks better than what I was going to do, which was copy/paste the whole class, etc... just to get to the member I need.

I wonder if I should open an enhancement or something along those lines for this. One should be able to easily and programmatically start editing a CellTable.

Something similar happens with SelectionCell where "options" is private and final. The SellectionCell at that point becomes very static since I can't seem to find a way to add/remove a new option to it.

Thank you again for the response. I think I am going to open cases for both of these today. It shouldn't be that hard to patch I think.

Best regards,

Alfredo

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/KjzapcBdCtAJ.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

On Friday, April 13, 2012 7:16:10 PM UTC+2, Alfredo Quiroga-Villamil wrote:

Scenario is as follows:

- CellTable with a column containing an EditTextCell.

- Add new record to the ListDataProvider.

- I can edit and do all the good stuff by hand to the newly added record in the CellTable.

Requirement:

- Programmatically call a starttEdit on say the first cell of the newly created row/record.

My investigation results:

After going through the code and investigating, all roads seem to point to ViewData in EditTextCell. Specifically, ViewData in EditTextCell has setEditing(boolean) which should do the trick. However, ViewData has package access.

Before I go and start to override, copy/paste things to be able to access the ViewData member I need, I figured I ask first since this seems like a basic operation when adding new records to a CellTable. I am thinking that I am very likely missing something.

IMO, you should:

1. extend the cell to automatically switch to an isEditing() state on some trigger
   
2. share something from your presenter/view/whatever with the cell to tell it which value/index to "auto-edit"
3. trigger a redraw of the table, to trigger the auto-edit in the Cell (this will probably be your setRowData that adds the new "record")

To access the ViewData class, the easiest is to use JSNI, which allows bypassing access checks. For instance, when the "auto-edit" is triggered in your overridden render() method, to create the ViewData (before calling setViewData(context.getKey(), viewData) and then super.render()), use:

private native Object createViewData(String text) /*-{

   return @com.google.gwt.cell.client.EditTextCell::new(Ljava/lang/String;)(text);

}-*/;

 

[Alfredo Quiroga-Villamil]

Hi Thomas:

Thanks for the response.

"1. extend the cell to automatically switch to an isEditing() state on some trigger"

Unless I bypass access by using JSNI, ViewData and isEditing are both package access. I typically avoid doing what you suggested, although, I have to admit, I've had to do it quite a lot in the past due to the significant number of things with package access that I've come across.

I think I have sufficient info to use the suggested work arounds. However, I still opened an issue for this as an enhancement/bug. One should be able to say:

cellTable.getView().startEdit(row,cell) or better

cellTable.startEdit(row,cell) or something along those lines without having to use all these work arounds.

Thanks all for your responses/help.

Alfredo

 

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/BUF4Zk_6K7cJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Steve C]

Found this old thread, and thought it worth commenting.

I took a variant of Ralf's approach in an effort to get tabbing/enter key movement to the next cell.  In my recreation of EditTextCell, I revised the commit method:

   private void commit(Context context, final Element parent, ViewData viewData,
         ValueUpdater<String> valueUpdater)
   {
      String value = updateViewData(parent, viewData, false);
      clearInput(getInputElement(parent));
      setValue(context, parent, viewData.getOriginal());
      if (valueUpdater != null)
      {
         valueUpdater.update(value);

      }
      Scheduler.get().scheduleDeferred(new Scheduler.ScheduledCommand() {
         @Override
         public void execute()
         {

            NativeEvent clickEvent = Document.get().createClickEvent(1, 0, 0, 0, 0, false, false, false, false);

            Element td = parent.getParentElement();
            Element nextTd = td.getNextSiblingElement();
           if (nextTd != null){
              nextTd.dispatchEvent(clickEvent);
           }
         }
      });
   }

It seems to work, and has the benefit that I don't need to extend or rewrite every possible editable cell type.

But, I don't know if there are any pitfalls that I've missed, other than it won't jump over a non-editable column to the subsequent editable column, and it won't jump to the next row.

Steve