Hi,

I was wondering if there are any further questions on this topic.

Please let me know if I can be of any further help.   

Hi All,

I have already given Jake the response from our developers thru the case I created for him but I'm sure others on this thread are looking for the same information so I'll add their explanation here. 

Their explanation assumes that you have a style defined in your resources, something like this one.

<Style TargetType="TextBlock" >

    <Setter Property="FontSize" Value="18"/>

    <Setter Property="FontFamily" Value="Calibri"/>

</Style> 

And have then added styles for the other editors, including the XamComboEditor, setting font sizes. 

This is not a bug. This behavior is the result of the way the .NET framework works with regards to how it gives precedence to style setters over inherited value of an inherited property (FontSize is inherited). So if a control uses TextBlock in its hierarchy of elements to display content, that textblock will end up using the font size specified on the TextBlock style. Any FontSize specified on the control itself will not be used by any TextBlocks that are inside the control. This behavior is observed by the following usage of ComboBox in this sample:

<ComboBox SelectedIndex="0" FontSize="40" >

<ComboBox.Items>

<sys:String>A</sys:String>

<sys:String>B</sys:String>

</ComboBox.Items>

</ComboBox>

If you use above combobox in a sample, it will not display 40 font size. It will display 18 font size as set on the TextBlock. Furthermore if you set the IsEditable to true on the above ComboBox, you'll notice a different behavior in that it's edit portion will be 40 font size but the drop-down will be 18 font size. Basically controls typically don't have any logic to explicitly template-bind textblock's font related properties to the control's properties because they are inherited. If you however created TextBlock styles, then these kinds of issues will popup in a lot of different controls, (not only our controls but .NET framework's controls).

 I hope this helps explain the behavior you are seeing.  Please let me know if you have any questions.

Hi,

I've logged this behavior as a development issue after consulting with our development staff. I will be opening a case for each of you and linking your cases to the development issue so that you will be notified directly of progress with this issue.

I appreciate your patience while I worked thru my investigation.

Hello Anastas, Can you give us an update on this please?

Thank you.

Yes, we understand why the XamEditor switches font size & your answer essentially restated to what we reported 2 days ago. We expect the XamEditor to maintain the ASSIGNED font size at all time regardless of what the global size is. This is how other wpf controls work where client can override inherrited dependency properties. In this case, the XamEditor picked up the correct size in normal mode but failed in edit mode. We suspect the fix is some where in the EditTemplate.

Please log this as a bug and let us know when it will be fixed. Thanks.