From the documentation (SL4)

CurrentItem - Gets or Sets the current Item (Inherited from DataControl)
SelectedItem -  Gets or Sets the selected item (inherited from DataControl)

Really?  Is that what properties do?  I didn't know that! 

COME ON Telerik!  First rule is to never use the word/member that you are defining in the definiition - we are looking to UNDERSTAND what the property is for!  Why is this member on the class?  Why does this class need to have this piece of information? Why would the designer which to expose this information? What are good uses of this information?

Please have an outside developer write the documentation, as s/he will think like a developer, and have these questions in their head when they are writing the documentation. 

Why is this so hard?  I would love to see at least 50% of the development budget into your documentation - because if developers dont' know how to use it, developers won't use it!

(Rant is now finished - I feel much better now.... :)

R

Hi codputer,

You have a valid point here. We will try to improve the descriptions of the properties.

Our documentation provides more information about these properties:
http://www.telerik.com/help/silverlight/radgridview-selection-programmatic-selection.html
http://www.telerik.com/help/silverlight/gridview-troubleshooting-first-row-always-selected.html

We appreciate your feedback so you are always welcome to share your opinion.

All the best,
Veselin Vasilev
the Telerik team

Interesting - but I think this distinction is going to be lost with a lot of people.

I would explain it a bit different - Focus and Selection is different - just because a control does not have focus, does not always mean the data is selected. Focus and Selection is often thought of as the same due to the behaviour of the TextBox. For example, highlighting text in a text box means that there is data (ie.the text) selected, and the control (which holds the data) must also then have focus - as the cursor must be in the control in order to highlight the text.  If you move away from the control (ie. cursor is moved to another control and the user clicks, or hits the tab key), the control loses focus.  If the text control doesn't have focus, it cannot have highlighted text.  For the text control, losing focus also means that if data is selected, the control "forgets" what data is selected, but retains the text.

In the grid control - the behaviour of Focus and Selection is different.  The control manages collections, and the SelectedRow may be differnent that than the row that is Current (has Focus, or where the cursor is).  In most cases however, the CurrentItem is always the SelectedItem, but there are circumstances where this synronization is problematic.

I may be incorrect here - but from your documentation - the CurrentItem in the grid (i.e. where the cursor is setting), may be a row, or a cell - depending on a configurable option as to what the default behaviour should be.  It the row current, or is the cell current when the cursor is updating a cell.  By default, when a cell is editted, the row is also current, as well as selected.

These are all subleties that will drive most programmers (including me) nuts.

Is it a correct assumptiont that if the grid control loses focus, the SelectedItem remains, but the CurrentItem is lost?

In MVVM pattern, I would like to know what the SelectedRow is - can I bind the SelectedItem to my MVVM?  Do I have to subscribe to the SelectionChanged event in order to keept his syncronization?

I got into this whole mess because I'm trying to manage the creation of a Row using RadGridView AddingNewDataItem.  I thought that when this event was thrown, the grid would create a new row, bind it to SelectedItem (which would then push it to  my VM so that I can provide default values), and update my RowDetailsTemplate accordingly.  Lots wrong here: 1) AddNewDataItem requires a NewObject, 2) the new Object does not become the SelectedItem ( or it may, but the binding does not used to update the VM), and 3) it looks like the RowsDetailsTemplate is ignored in the InsertRow?

Questions:
1) When the user clicks on the add row, how to I inform the VM, and get a row into the NewObject event arg (still new to this pattern)
2) How do I control the NewRowTemplate (my job this morning, so I have not researched this yet)

Although I would like to see more help in the documentation, I am very apprecative of the support via this forum.  Please let the powers at be know that it's the only reason why I'm using Telerik as a thrid party control - something that I have never done before when building client apps.

Regards,
R

Hi Codputer,

you can write code to verify it

Basing on my experience with the RadGridview, even though the grid lose its focus( but if you clicked a row before moving somewhere else outside the grid), we still have grid's selecteditem

now i know that currentitem means that the current focus row. The document is really confusing. Before(without this thread), I think both are the same

Hi codputer,

I will quote the MSDN site which describes the CurrentItem property as:
This property gets the data item for the row that either has focus, or contains the cell that has focus. It is equivalent to the DataGridCellInfo.Item value returned by the CurrentCell property.

We tried to make the RadGridView's CurrentItem property behaves the same way.

When you click outside the gridview - the currentItem and the selectedItem are not lost.

Also, you might find these links helpful:

• NewRow Style
• How To: Synchronize your UI selected items with your data context using MVVM and Blend behaviors for Silverlight and WPF 
• Insert Row - RowDetailsTemplate
  
  

All the best,
Veselin Vasilev
the Telerik team

I've just checked the Documentation (http://www.telerik.com/help/silverlight/p_telerik_windows_controls_datacontrol_currentitem.html).
It's been almost 2 years now and the documentation on DataControl.CurrentItem and DataControl.SelectedItem has not been updated at all.

Didn't you Veselin promissed that you would do a better job on documenting those properties?

Please consider updating the documentation soon.
It is frustrating again and again everytime I look into the documentation to see what property does what.

Sincerely yours,
David

Hello David,

 Thank you for your remark.

I have checked the referenced API links. Actually those links are generated based on the description given for the properties in the source code. The purpose of this description is very basic and we do not give any details there. More descriptive explanation is available in the articles available within our online documentation.  

Based on your complained, I am currently writing a new article comparing the two properties. I will include the information already partially available in the articles related to selection. Meanwhile may I ask you to share your opinion on what I should additionally include?

Regards,
Didie
the Telerik team

Articles are one thing, documentation about class and its members is another thing. I will quote a sentence from the original question:

"First rule is to never use the word/member that you are defining in the definiition - we are looking to UNDERSTAND what the property is for!"

It seems that majority of definitions in documentation is doing just what it should not be doing at all.

When a developer searches for information about some class member, articles are not the primary source. Major information should be kept in class member definition. And in there, you can have links to articles, demos, and everything related /helpful. That would be a major improvement to your documentation.

Currently, Telerik documentation is the worst documentation that I have ever used (and I was using 3rd party control for the last 10 years), while the products themself are very good. And during the last 6 months that I am using Telerik controls, I have seen a lot of Telerik employees saying that documentation will be improved, and thanking for the suggestions. However, I do not see any improvements being made, which can be a deal breaker if any new technology needs to be implemented / learned by developer. And from what I see, it seems that you are thinking about introducing payed consultancy services, which can be one more reason not to improve documentation.

If you are really eager to improve documentation, why don't you ask customers what do they need to be improved? Or create some sticky topic to see opinions of custromers. Write them email, ask them if they are satisfied with current documentation.

Regards,
Goran

Documentation of properties should be documented when the property is created or exposed.  The reason why the property is created or exposed is what the documentation should contain.  If the property does not have a purpose, then why is it in the API.  API interface should never contain a member that isn't useful, or be explained why it IS useful in a couple of sentances.  If the documentation grows, it's likely that the API needs to be thought through as well to make it simplier.

Remember it's not what it does, but why is it there...

Hello,

Thank you for your feedback.

We work on improvement the documentation experience including both the help articles and the API Reference. Your notes will help us to made it be more usable. The opinion the clients share is considered into our discussions on what should be changed when it comes to documentation.

May I ask you to share what specific problems have you met so that we could address it straight away?

Kind regards,
Didie
the Telerik team

You can see some of the problems that I experienced when I started working with Telerik Silverlight controls.

http://www.telerik.com/community/forums/community-forums/about-telerik/documentation-usage.aspx

Regards,
Goran

Hello Goran,

 Thank you for your valuable feedback and involvement into improving the documentation. For that reason I have updated your Telerik points.

Regards,
Didie
the Telerik team