RadTabItem background color can't be changed?

[Rob Ainscough]

I'm using the lastest UI for Silverlight controls and setting the RadTabItem.Background to a color doesn't work.

 

<telerik:RadTabItem x:Name="AddFeeTabItem" FontWeight="Bold" Header="Add Fee" IsSelected="{Binding AddFeeSelected}" IsEnabled="{Binding AddFeeEnable}" BorderBrush="{x:Null}" >
               <telerik:RadTabItem.Background>
                   <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
                       <GradientStop Color="#FFFEFEFE" Offset="1"/>
                       <GradientStop Color="#FFFF0101"/>
                   </LinearGradientBrush>
               </telerik:RadTabItem.Background>

 

[Petar Mladenov]

Hello Rob,

When a RadTabItem (RTI) is Selected - you see its background applied from the "SelectionVisual" TemplatePart. Attached you can find an approach in which the default Style of RTI is modified so that the SelectionVisual's Background is bound to the Background of the RTI:

<Border x:Name="SelectionVisual" Background="{TemplateBinding Background}" BorderBrush="#FF848484" BorderThickness="1,1,1,0" CornerRadius="3,3,0,0" Margin="0" Opacity="0">
                              <!--<Border.Background>
                                  <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
                                      <GradientStop Color="White"/>
                                      <GradientStop Color="#FFFAFAFA" Offset="1"/>
                                  </LinearGradientBrush>
                              </Border.Background>-->
                              <Border BorderBrush="White" BorderThickness="1,1,1,0" CornerRadius="2,2,0,0"/>
                          </Border>

We hope this is what you needed.


Regards,
Petar Mladenov
Telerik

 

 

[Rob Ainscough]

Ok, but why on earth would I want to over complicate this?  Just want to set the Background to a color and be done with it ... some of the most simple tasks are being over thought and over complicated which just increases development time.

This is what has always puzzled me about Telerik, I have to build styles, templates, overrides, etc. etc. ... if I have to do all that work, then why would I use a Telerik control in the first place?

I hope you can understand my point, I purchase third party tools to speed up my development and NOT to slow it down.  I can do everything you mentioned on standard Microsoft controls which does indeed beg the question why use Telerik?

Something as simple as setting the background color of a tab becomes an "ordeal" with attached projects.   That really shouldn't be the case.

Rob.

 

[Petar Mladenov]

Hello Rob,

We understand your point. Indeed, sometimes more effort is needed to change a small visual thing (brush / color / margin / border etc). However, please try to understand our design decision too. We usually try to solve 90% of our client requirements with wide range of Themes and public / protected set of methods / properties. Also in some of our new Themes (Green, Visual Studio, Office 2016 coming in R3 2016) we have mechanism for changing just set of brushes which control all colors used by the theme. On the opposite, imagine we introduce dependency properties for normal, selected, mouseover, mouseoverselected, disabled, etc states. Some controls have inner controls and inner sates and the potential count of such properties might be in terms of 10-100. This will definitely hit the performance of the majority of our clients. This also requires additional code to support runtime change / theme change / collisions with animation states which have higher priority than local value set. In an ideal world every control might have properties for everything you can imagine, but in real world this costs a lot in terms of WPF / Silverlight rendering performance and also in terms of maintenance. We believe both Microsoft and our competition follow this unspoken rule and are critical to the number of dependency properties they introduce.

One additional point, if you use no-xaml binaries and you include the xaml theme files into your application, changing such backgrouds / brushes cost simply finding a few lines / visual states and replacing a brush. 

Regards,
Petar Mladenov
Telerik by Progress

[Rob Ainscough]

Hi Petar,

I'll disagree with you.  I/we buy 3rd party controls to speed up our development NOT to slow it down, we just what them to look reasonably modern and we do NOT want to get that involved in UI as small development groups rarely have resources or the budget for dedicated "UI developers" ... just not how the real world works.  Small dev teams have a very different focus and hence their desire to purchase 3rd party controls that just get the job done with minimal effort.  If we had a UI developer, then we probably wouldn't be using 3rd party controls at all.

But what if I don't want the change to impact my entire application?  What if I just want a Red Tab, nothing more, nothing less?  What if I don't use animations because they are resource intensive and provide NO benefit to my clients?  I don't know who your majority clients are and I really should need to know ... again, 3rd party controls are about RAD, we buy controls so we DON'T have to focus on the UI.

Telerik's no-xaml/xaml binaries was a VERY bad decision for those of us that need to focus on other aspect of core development NOT the UI.  We just don't need "themes" as it does nothing for our clients and doesn't help us generate revenue for my company ... they need speed, performance, and a "good enough" UI that looks reasonably modern.

I realize Silverlight has long ago been abandon by Microsoft and as such is probably not a focal point for Telerik, but your company still sells Silverlight UI controls and still updates them (and we've been long time subscribers).  I feel your focus is simply wrong.  Again, it's all about rapid application development (RAD), there is NOT going to be a long term re-usability with Silverlight (come 2021 it'll no longer be support by any browser).  Code re-use at the UI level is close to non-existent, the re-use is primarily in business logic and back-end SQL/Database.  UI's change so frequently it just doesn't make sense to chase that white rabbit from a development resource standpoint.

Sadly there is NO web technology that is as powerful as Silverlight ... it's ability to look like Windows forms apps (OOB) is the primary reason we're still developing with Silverlight - our clients demand a better UI experience that what HTML5 can offer ... enter Silverlight OOB.  HTML5 can't operate anywhere near the performance and consistency of Silverlight ... in fact HTML5 is not even an option for my company going forward (restrictions on simple things like printing, setting control focus, and host of other restrictions that may or may not work pending browser used and sub versions ... chasing that is a fools game and a huge waste of development resources) .  We're going to shift back to Windows Forms (maybe WPF if we can fine the right 3rd party controls that focus on RAD).  Windows forms apps are just so much more secure than HTML5 and/or Silverlight.

But it sounds like what you are suggesting is that Telerik is not a good fit for RAD and my company's development needs.

Rob.

[Martin Ivanov]

Hello Rob,

Thank you for sharing your thoughts.

I am sorry to hear that you are not satisfied with the usability of our controls. I can also agree with that in some cases achieving a specific behavior is not very straightforward task, despite the fact that we are trying to provide the most convenient mechanisms for setting up the controls. However, with UI for Silverlight we are trying to cover the majority of the common scenarios and requirements applicable for the specific controls. This requires a balance between RAD, performance and good looking, and customizable UI. Indeed, some of the design decisions, both UI and development, might not be the most convenient when it comes to RAD, but they are made in order to keep this balance.

About the NoXaml assemblies and the implicit styles theming, we decided to provide this mechanism because the old one (StyleManager) has many known issues and limitations. The new approach requires a little bit more effort but it brings some benefits over the manager. You can take a look at the Implicit Styles versus StyleManager blog post. Additionally, if you do not want to use themes and NoXaml, you don't need to. You can use the Xaml dlls which have the default Office_Black theme built-in.

As a side note, if you don't prefer using the approach with the control template editing, you can use the methods of the ChildrenOfTypeExtensions class to get the specific element from the visual tree of the control and make the required changes in code. This way you will avoid the long styles and templates, but you still need to know where is located the searched element or what is its name. This is by far the best approach, but I think it is much easier to maintain then the whole style. Especially, when it comes to upgrade.

If you have further thoughts, advices or any feedback in general, don't hesitate to share it with me.

Regards,
Martin
Telerik by Progress