How do you access an individual cell?

[Christopher]

In the Q2 release of the WPF grid one could do something like grid.CurrentRecord.Fields[0] to access an individual cell.

In the Q3 release I have been unable to find any means of accomplishing the same task.  What am I missing?

I am attempting to re-implement the tab handling I had created for the Q2 release of the wpf grid.  The Q3 grid made a nice leap forward adding some tab handling, but it doesn't match our desired behaviors.

Thanks,
  Chris

[Dimitar Dobrev]

Hello Christopher,

1. You may check here since we answered a similar question some time ago;
2. We do not fully comprehend what you mean by "tab handling". If you need to edit cells by using only tab navigation (i.e. a cell enters edit mode as soon as you focus it), you can use the following style:

<Style TargetType="telerik:GridViewCell">
    <Setter Property="IsInEditMode" Value="{Binding IsCurrent, RelativeSource={RelativeSource Self}}" />
</Style>

You are welcome to continue our discussion, if the proposed solutions do not satisfy your requirements.




All the best,

Dimitar Dobrev,

the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[Christopher]

Greetings Dimitar,
  I did a poor job of explaining my issue.  Let me give it another shot.

I am looking to access cell properties, not the data object displayed by a record.  For example in the Q2 release (when we had the Field object and collections) we could access a 'cell' by using the record and field objects.  (grid.records[0].fields[0].property). In this way we could do things such as setting the 'cell' to be current (IsCurrent property) or set it as being in edit. (IsInEditMode property).  With the Q3 release I have not been able to find a way to programmatically do this.

By tab handling I meant the over all tabbing behavior with in the grid.  Specifically in my case I need it to handle:
1) Placing a cell directly in edit mode as soon as it gains focus.
    (Thank you for the elegant style solution to this. I much prefer that to handling the GotFocus event as I am currently doing.)
2) Create a new data object and row(record) when tabbing beyond the last row.  This also needs to place the first visible/editable column in the new row in edit mode and mark the new row as being current/selected.
3) When using Shift + tab in the first column in a row, it should set the previous row to be current/selected and the last visible/editable column to be in edit mode.

These behaviors allow a user to fully enter/edit multiple rows of data with out ever needing to use the mouse.

Currently: (these can be tested using the First Look example in the grid demo)
 Forward tabbing works if your in edit mode or simply focused on a grid element.
 Reverse tabbing (shift + tab) works only if the cell is not in edit mode.  If the cell is in edit mode the focus shifts out of the cell to the browser (no focus is maintained on the page that I can see).  If the cell is not in edit mode, reverse tabbing correctly cycles backwards through the grid objects. In win forms the reverse tabbing while in edit appears to do nothing at all.

I have been able to get reverse tabbling partially working by doing something like:

private void Cell_KeyDown(object sender, KeyEventArgs args)
        {
            args.Handled = HandleCellKeyPress((GridViewCell)sender, args);
        }

private bool HandleCellKeyPress(GridViewCell cell, KeyEventArgs args)
        {
            if (args.Key == Key.Tab && args.KeyboardDevice.Modifiers == ModifierKeys.Shift)
            {
                cell.MoveFocus(new TraversalRequest(FocusNavigationDirection.Previous));
                return true;
            }
            return false;

        }

The issue with this is that once the first cell in a row(record) is reached focus goes to row and then on to other grid elements before moving to the previous row/cell.

For our particular usage having the entire row or row selector ever gain focus is not desired. I can see in other situations where this behavior may be desired.  With the Q2 release we had a means to access individual cell (field) objects and thus I was able to implement the tabbing behaviors we required. You can see an earlier example of the code I used to do this here: http://www.telerik.com/community/forums/wpf/gridview/edit-cell-using-tab.aspx#652328

Thanks,
  Chris

[Dimitar Dobrev]

Hi Chris,

Please accept my apologies for the Shift+Tab behaviour, I forgot to make the binding two-way:

<Style TargetType="telerik:GridViewCell">
    <Setter Property="IsInEditMode" Value="{Binding IsCurrent, RelativeSource={RelativeSource Self}, Mode=TwoWay}" />
</Style>

If you don't want the rows to get focus, you need to add two additional styles:

<Style TargetType="telerik:GridViewRow">
    <Setter Property="IsTabStop" Value="False" />
</Style>
<Style TargetType="telerik:DataCellsPresenter">
    <Setter Property="IsTabStop" Value="False" />
</Style>

Unfortunately in our Q3 release the navigation cells (the small empty cells in the first column) cannot be skipped when tabbing. This issue is fixed in our service pack which is due next week.

I hope these additional steps will help you reduce your problems. Be sure to ask us if you need further assistance.




Sincerely yours,
Dimitar Dobrev
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[Bradley Schultz]

I too have had similar issues. I still don't see how to access individual cells to start edit mode or perform other functions. Specifically the case mentioned previously:

"Create a new data object and row(record) when tabbing beyond the last row.  This also needs to place the first visible/editable column in the new row in edit mode and mark the new row as being current/selected."

b  r  a  d

[Christopher]

Greetings Dimitar,
   Thanks for the style updates to help with the tabbing. I'll put those to use right away.

  Can we expect to see support for cell level access again in the future?  Will support be built in to handle adding of new rows in the method I described?

Thanks,
  Chris

[Dimitar Dobrev]

Hi Chris,

1. We are currently thinking about reintroducing similar API and we will be glad to hear your opinion. For example: should we expose some data objects like we did before with the fields, or should we expose the UI cell objects instead?
2. At this time we do not have plans to have such functionality built-in. However, we are interested to hear in more detail about your need for automatic addition of new rows. Is it a specific or a standard requirement for the applications you develop? Is it connected to some specific business area (for example, accounting) or is it needed in any application?

Of course, we are also willing to know how important both features are for your project. Thank you for your patience and for your participation in our forums. We are looking forward to your answer.

Kind regards,

Dimitar Dobrev,

the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[Bradley Schultz]

This is a common need for applications that I develop. Often the user would like to continue to enter information row by row with the tab or enter key. The type of insert functionality that Chris discussed is extremely important to my end user groups.

Personally, I would vote for access to UI cell objects, as these kind of exceptions to standard processing are generally dealing with UI issues, and not necessarily the underlying data structure. There would need to be some way to correlate the two, however.

 

b  r  a  d

[Christopher]

Greetings Dimitar,
1. Personally I think exposing the UI cell objects and their editors would be the way to go.  I agree with the new change to record based access to the data. We are just missing the UI/Editor access.

2. The automatic addition of new rows is an extremely common behavior in our applications.  Most data entry applications I have worked on or seen have this behavior. It's also an accessibility issue. (See: http://msdn.microsoft.com/en-us/library/ms971323.aspx) Having said that, I'm not sure its something the grid itself should handle. If we gain cell/Editor level access again, there is no reason we can't code this behavior in based on our applications requirements.  I can see situations that a built in auto add functionality would break down. (Custom business logic when creating data objects. Historical and auditing reasons come to mind).

For our applications gaining this behavior back is a pretty high priority. We have instances of the winform radGrid that allow this behavior and have so for some time. The particular application in question right now his a hybrid wpf/winform. Slowly migrating fully to wpf. It is important for us to keep the same over all behavioral feel of the application during the transition.  The accessibility issue is also quiet high on the list.

Thanks for all your time and efforts with this issue!
 Chris

[Hristo Deshev]

Hi Christopher, Bradley,

After some discussions in the team, we are leaning toward exposing the UI objects through events and public properties, so that you can modify the appearance easy enough.

I think I understand the requirement of popping the insertion row when focus leaves the last cell in the grid, and we should definitely be providing a way to easily do that by handling an event. I am thinking that maybe we can expose a LostFocus event to the row or the grid and allowing users to initiate row insertion there. Is that how you do it with the WinForms RadGridView control at the moment?

As far as accessibility is concerned, I'd like to assure you that we are working on it. We already provide automation peers for the most important RadGridView components, and we will be extending that support in the future. Do you have any specific needs or high priority accessibility-related issues that need addressing. We may be able to bump their priority a bit.

Greetings,
Hristo Deshev
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.