This question is locked. New answers and comments are not allowed.
A little background: We have a screen where we give the users the ability to customize the look and feel of the results grid for reports. The user selects a report and we load a GridView with a single row of data and the user then can change the sort, grouping, order, visibility, and frozen column. As the user makes changes to certain properties, we display a message showing what has been changed. For example, we display the value of the FrozenColumnCount property. We then use the PersistenceFramework to save the configuration and to use it later.
The Problem: The FrozenColumnCount value includes columns that are not visible. This is possible when the user sets the frozen column then in another control that is bound to the GridView columns sets one of the columns within the frozen section to be not visible. This wouldn't be much of an issue to the user who initially creates the format as they could understand the discrepancy. But there would be confusion for the next user who goes to edit the configuration when they see graphically that 3 columns are frozen but textually that 4 columns are frozen. I can't imagine that it makes sense that the FrozenColumnCount would include columns that are not being displayed.
The Problem: The FrozenColumnCount value includes columns that are not visible. This is possible when the user sets the frozen column then in another control that is bound to the GridView columns sets one of the columns within the frozen section to be not visible. This wouldn't be much of an issue to the user who initially creates the format as they could understand the discrepancy. But there would be confusion for the next user who goes to edit the configuration when they see graphically that 3 columns are frozen but textually that 4 columns are frozen. I can't imagine that it makes sense that the FrozenColumnCount would include columns that are not being displayed.
2 Answers, 1 is accepted
0
Hi Josh ,
I have talked to the team regarding your concern. There were actually two opinions and I can not deny that your point is valid to some extent. Indeed the current implementation includes the invisible columns in the count.
From a programmers point of view - this is the count of the columns in a collection regardless of their visual state . Additionally the state can be changed runtime - e.g .turn the visibility on and off. In such case we do not have to explicitly take care of the frozen columns count as well ( e.g. change it with the count of columns shown or hidden).
The result is - we have intuitive API for coders and introduce some confusion for end users in scenario like yours.
Most of the team were negative about changing the logic to exclude hidden columns from count as this would introduce some breaking changes to the existing codebase of many of our clients.
Regards,
Pavel Pavlov
the Telerik team
I have talked to the team regarding your concern. There were actually two opinions and I can not deny that your point is valid to some extent. Indeed the current implementation includes the invisible columns in the count.
From a programmers point of view - this is the count of the columns in a collection regardless of their visual state . Additionally the state can be changed runtime - e.g .turn the visibility on and off. In such case we do not have to explicitly take care of the frozen columns count as well ( e.g. change it with the count of columns shown or hidden).
The result is - we have intuitive API for coders and introduce some confusion for end users in scenario like yours.
Most of the team were negative about changing the logic to exclude hidden columns from count as this would introduce some breaking changes to the existing codebase of many of our clients.
Regards,
Pavel Pavlov
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
0
Josh
Top achievements
Rank 1
Rank 1
answered on 19 Jul 2012, 12:36 PM
Hi Pavel,
Thanks for the response. That certainly makes sense and I can understand the reasoning not to change it. In fact, I believe we have enough justification to warrant creating a new property for visible frozen column count. I think we agree that there is a valid requirement for providing this data.
Thanks,
Josh
Thanks for the response. That certainly makes sense and I can understand the reasoning not to change it. In fact, I believe we have enough justification to warrant creating a new property for visible frozen column count. I think we agree that there is a valid requirement for providing this data.
Thanks,
Josh