Rodney Foley
Top achievements
Rank 1
Rank 1
Rodney Foley
asked on 23 Jun 2012, 09:33 PM
Right now if you change the RadTreeListView.FontSize it changes ALL FONTS on the control.
I want to be able to independently set the Font Size of the data displayed in the rows and the column headers. Basically I want to fix the column header text to one size, and then allow the user to change the font size of the data in the rows.
However it looks really bad when the user is changing this and the header changes with it. I basically have hooked up the scroll wheel to change the font size on the TreeListView and it works just kind of looks bad that the header is changing with it and would like to lock that down if possible.
Thanks.
I want to be able to independently set the Font Size of the data displayed in the rows and the column headers. Basically I want to fix the column header text to one size, and then allow the user to change the font size of the data in the rows.
However it looks really bad when the user is changing this and the header changes with it. I basically have hooked up the scroll wheel to change the font size on the TreeListView and it works just kind of looks bad that the header is changing with it and would like to lock that down if possible.
Thanks.
10 Answers, 1 is accepted
0
Hi Rodney,
I am attaching a sample project that you can use for a reference. Is that the behavior that you require ?
Kind regards,
Maya
the Telerik team
You can try setting a style targeting GridViewHeaderCell like follows:
<Style TargetType="telerik:GridViewHeaderCell"> <Setter Property="FontSize" Value="15" /> </Style>I am attaching a sample project that you can use for a reference. Is that the behavior that you require ?
Kind regards,
Maya
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>
0
Rodney Foley
Top achievements
Rank 1
Rank 1
answered on 25 Jun 2012, 04:26 PM
I want to be able to set the font size of all cells independently of the font size of the column headers. One would think that the FontSize property on the TreeListView would only set the font size for the data in the cells. Then it would be nice if there was a FontSize property on the GridViewDataColumn so you could set each header independently or bind them all to the same value.
I require something that can be done programmatically in a ViewModel and an Attached Behavior (Interactivity.Behavior). Setting by style is very complex in C# for something that should just have an exposed property to override the style.
I was hoping I was missing something in my attempts.
If it helps the REASON I want to do this, is to implement a form of ZOOMING in and out on the TreeListView. I just want to change the font size of the data cells within a preset bounds. When I do this the header changes size as well. I also tried using a ScaleTransform on various things like the LayoutTransform but it scaled everything including the ScrollBars which I don't want. Not enough is exposed within the TreeListView that I can find where to apply the ScaleTransform on the contents of the ScrollView so as to avoid the scrollbars. This would scale the headers but it would look just like Excel scaling so would be acceptable as it wouldn't require re-sizing columns and rows.
However scaling by changing font size if the rows and columns could be autosized on the fly would look a lot nicer if the header didn't change size.
So I have looked at a couple solutions none of which i could get to work well on a TreeListView. Any guidance would be appreciated especially if it doesn't REQUIRE modifying styles.
I require something that can be done programmatically in a ViewModel and an Attached Behavior (Interactivity.Behavior). Setting by style is very complex in C# for something that should just have an exposed property to override the style.
I was hoping I was missing something in my attempts.
If it helps the REASON I want to do this, is to implement a form of ZOOMING in and out on the TreeListView. I just want to change the font size of the data cells within a preset bounds. When I do this the header changes size as well. I also tried using a ScaleTransform on various things like the LayoutTransform but it scaled everything including the ScrollBars which I don't want. Not enough is exposed within the TreeListView that I can find where to apply the ScaleTransform on the contents of the ScrollView so as to avoid the scrollbars. This would scale the headers but it would look just like Excel scaling so would be acceptable as it wouldn't require re-sizing columns and rows.
However scaling by changing font size if the rows and columns could be autosized on the fly would look a lot nicer if the header didn't change size.
So I have looked at a couple solutions none of which i could get to work well on a TreeListView. Any guidance would be appreciated especially if it doesn't REQUIRE modifying styles.
0
Hello Rodney,
Maya
the Telerik team
I do understand your requirements. However, if you set FontSize for the grid, you will set it to each of its elements - both cells and headers as they all belong to it.
Please take another look at the sample attached - as you can see you can create fairly simple style targeting GridViewHeaderCell and have the behavior you require - to be able to change FontSize of the cells only. Do you have any troubles with the implementation of this approach ?
Maya
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>
0
Rodney Foley
Top achievements
Rank 1
Rank 1
answered on 26 Jun 2012, 03:40 PM
I did look at it, and it is interesting that when you set/override the font via a Style that you built in that the TreeListView's FontSize doesn't over ride it, however if you leave it set based on the theme style it does.
Too me this is a sign of a bug, as you guys know not to change it but only if the style set it as an override or something but otherwise nope and you make the assumption that should be changed by the TreeListView's FontSize. To me that means you meant for them to be different but that you are not consistent in all causes it is a bug.
Also a sign that you should have a FontSize for the Header exposed as a property as well so as to avoid having to use use a style to do something so simple.
Too me this is a sign of a bug, as you guys know not to change it but only if the style set it as an override or something but otherwise nope and you make the assumption that should be changed by the TreeListView's FontSize. To me that means you meant for them to be different but that you are not consistent in all causes it is a bug.
Also a sign that you should have a FontSize for the Header exposed as a property as well so as to avoid having to use use a style to do something so simple.
0
Hello Rodney,
Maya
the Telerik team
Will it be possible to share why the approach suggested above is not appropriate ? Do you have any troubles implementing it ?
As mentioned previously, setting FontSize of RadGridView will change this property for all its elements - cells, header cells, etc. Changing only the property of the cells will not be the expected behavior since FontSize is set at the grid level, not on the cell one.
Maya
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>
0
Rodney Foley
Top achievements
Rank 1
Rank 1
answered on 27 Jun 2012, 03:05 PM
I think I have been very clear about this. I have no issues with understanding what is going on, or implementing this if I chose to. Its not the number of lines of the solution or simplicity of it. So let me try to reiterate what I have already stated.
So I really do appreciate your help so I mean no offense and will always welcome it. It just after seeing your style hack to workaround the issue it opened my eyes to this really needs to be implemented so that the control has TWO font size settings as to decouple the data in the cells from the header because it seems like you already have the separation in code you just need to expose a property to allow control much more easily via Xaml and C#.
- Styles should not be used to HACK around issues that should be fixed in the control
- Clearly you have code in the control that takes into account the style font sizes and that when you set it on the control property that you know not to change the ones set by the style.
- Based on #2 this means you are aware of users wanting to have different font sizes for the different sub-controls on the main control.
- Therefore you should just expose the property for each one of these sub-controls to setup it individuality instead of having one MASTER property and then having to resort to a style hack to override this.
So I really do appreciate your help so I mean no offense and will always welcome it. It just after seeing your style hack to workaround the issue it opened my eyes to this really needs to be implemented so that the control has TWO font size settings as to decouple the data in the cells from the header because it seems like you already have the separation in code you just need to expose a property to allow control much more easily via Xaml and C#.
0
Hi Rodney,
Maya
the Telerik team
Exposing properties on the main control level for each of those that are present on its child elements is not a recommended approach when developing a Silverlight/ WPF control (as it is in this case - to expose separate properties for FontSize of the headers and cells). This can be easily achieved by creating a simple style targeting the corresponding elements.
You can prove that on DataGrid control as well - it has the exact same behavior as RadGridView, RadTreeListView, etc. (I am attaching a sample project illustrating it).
Furthermore, changing the current state will lead to breaking changes that is anything but what we want.
I do hope you understand our concerns on this issue and do not accept this as a bug.
Maya
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>
0
Rodney Foley
Top achievements
Rank 1
Rank 1
answered on 28 Jun 2012, 04:53 PM
So you are saying FontSize and HeaderFontSize is just to much for you guys to handle because you don't think its a good idea even though you are already doing this in the code and only exposing it via a style which is OKAY, but exposing it via a Property is a NO-NO. Hmmm seems like you are conflicted and can't make up your mind.
Styles are not the answer to do simply things like this. Also the property doesn't have to be exposed their, I also mentioned it would be nice if it was exposed on the GridViewDataColumn class which is close to the "source" so to speak. Or you can bring it up a level or something too.
Either way you guys should not bring up "Recommended Approaches" unless you can point a credible source for the recommendation, and then that you are consistent in your application of the approach. Also you can't just use recommended approach when it suits you when you don't want to do something. The key word is RECOMMENDED meaning that it is usually a good idea, and it is always a judgement call, and there are times with not doing the "recommended approach" is perfectly fine. SO its not a creditable answer to this issue.
Just be truthful, and state that you refuse to accept this as a bug or even as a feature request from your customer and we should take a hike and be quite.
Styles are not the answer to do simply things like this. Also the property doesn't have to be exposed their, I also mentioned it would be nice if it was exposed on the GridViewDataColumn class which is close to the "source" so to speak. Or you can bring it up a level or something too.
Either way you guys should not bring up "Recommended Approaches" unless you can point a credible source for the recommendation, and then that you are consistent in your application of the approach. Also you can't just use recommended approach when it suits you when you don't want to do something. The key word is RECOMMENDED meaning that it is usually a good idea, and it is always a judgement call, and there are times with not doing the "recommended approach" is perfectly fine. SO its not a creditable answer to this issue.
Just be truthful, and state that you refuse to accept this as a bug or even as a feature request from your customer and we should take a hike and be quite.
0
Hi Rodney,
Thank you for your input on the matter. After another internal discussion we are under the persuasion that the current implementation of RadTreeListView is correct and the provided options for modifying the font size of column headers are properly exposed. Any change of this behavior will affect negatively all of our clients and this is the other reason which restrains us from such changes.
Kind regards,
Hristo Maradjiev
Product Unit Manager
the Telerik team
Thank you for your input on the matter. After another internal discussion we are under the persuasion that the current implementation of RadTreeListView is correct and the provided options for modifying the font size of column headers are properly exposed. Any change of this behavior will affect negatively all of our clients and this is the other reason which restrains us from such changes.
Kind regards,
Hristo Maradjiev
Product Unit Manager
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>
0
Rodney Foley
Top achievements
Rank 1
Rank 1
answered on 03 Jul 2012, 05:45 PM
Understood.
Why does this have to be a breaking change that would impact existing customers? If implemented wisely it wouldn't have to be a breaking change? I can already think of a way that it would not have to be breaking, and I would assume you could think of a dozen more.
For example:
If you set the main FontSize property only then it works as it always has. If however you ALSO set the additional property (where ever you would put it) for the Header Font Size then it would set the font size for the header only and let the other font size apply to the cells. Just like you do with the style if provided. If you provide ONLY the Header Font Size then the default setting for the TreeListView FontSize would apply to the cells only and the header setting to the header. So by default if no header font size is provided the main TreeListView FontSize is used instead. Simple. So all existing code that has never used the new property since it didn't exist when running against the new code would still work exactly as it always had.
This is a simple workflow that works with your EXISTING WORKFLOW you have with your Style override example and the logic it already uses when its provided. So you sound like you already have a workflow for overriding only header font size using a style, adding a property to do the exact same thing is not a breaking change.
I do not understand why you guys are so resistant to making life easier for a developer when it doesn't require much if any new workflow and wouldn't break any existing customers. May be its cultural thing and I just will never understand. It just adding a property that is optional but would make life so much easier to developers who don't what to touch style's or override them.
Why does this have to be a breaking change that would impact existing customers? If implemented wisely it wouldn't have to be a breaking change? I can already think of a way that it would not have to be breaking, and I would assume you could think of a dozen more.
For example:
If you set the main FontSize property only then it works as it always has. If however you ALSO set the additional property (where ever you would put it) for the Header Font Size then it would set the font size for the header only and let the other font size apply to the cells. Just like you do with the style if provided. If you provide ONLY the Header Font Size then the default setting for the TreeListView FontSize would apply to the cells only and the header setting to the header. So by default if no header font size is provided the main TreeListView FontSize is used instead. Simple. So all existing code that has never used the new property since it didn't exist when running against the new code would still work exactly as it always had.
This is a simple workflow that works with your EXISTING WORKFLOW you have with your Style override example and the logic it already uses when its provided. So you sound like you already have a workflow for overriding only header font size using a style, adding a property to do the exact same thing is not a breaking change.
I do not understand why you guys are so resistant to making life easier for a developer when it doesn't require much if any new workflow and wouldn't break any existing customers. May be its cultural thing and I just will never understand. It just adding a property that is optional but would make life so much easier to developers who don't what to touch style's or override them.