3 Answers, 1 is accepted
GridView (or RadTreeListView) columns do not have a HeaderCellStyleSelector property... Maybe because is unnecessary and it no has sense to have a StyleSelector for an unique element. HeaderCellStyle is set at column level and there's only one header per column, so you can define the HeaderCellStyle when you define the column. If you want to set different HeaderCellStyles you loose the facility to autogenerate the columns and you must set AutoGenerateColumns to false and type one per one the columns with the desired HeaderCellStyle.
If your columns are auto-generated you may subscribe to the AutoGeneratingColumn event of RadGridView and set the HeaderCellStyle from there:
The style1 is an explicit style which resides within UserControl's ResourceCollection.
If you need any additional info do not hesitate to contact us!
All the best,
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>
Sorry our columns are not auto-generated. They are entirely dynamic.
I can understand theat at first sight a Selector for this element is not valid which I can understand, however, to provide a more powerful scenario for grids, you should be able to bind the columns to a column collection and provide a more suitable way for the users to perform dynamic grid binding against unknown data set structures. At first glance a selector may seem pointless, but with inherited and extended column objects bound to an ObservableCollection<Column...> the selector may well have a use.
We currently employ a mechanism whereby our columns relate to "dates", we may extend the date-range dynamically and as such build our own "internal" set of date columns and provide a custom binding (with parameter) for each column.
We may further wish to alter a flag on one of our (extended) bound columns for example "Is a working day" and show the column header with a different colour (hence the selector). All of this is user-driven data and fully dynamic. If we *could* bind our columns to an ObservableCollection<> and use a notify change event we could get around this issue.
I have not yet found a way to bind the columns to a collection and just update the elements of that collection accordingly.
A great improvement to the suite would be the ability to bind the columns to an ObservableCollection<> and let the control take care of the rest for us on a collection change and style selector. So maybe it is logically valid after all. :-)
I guess for now I will need to re-fresh the columns myself in code.