8 Answers, 1 is accepted
0
Hi Chad,
You can use the following implicit style to enable vertical scrollbar in RadMaskedTextInput for example:
This requires that you are using NoXAML binaries and our implicit styles theming mechanism so that yo can inherit the MaskedInputTextBoxStyefrom our themes (by using the BasedOn property). You can find more information about the mentioned approach here.
Regards,
Evgenia
Telerik by Progress
You can use the following implicit style to enable vertical scrollbar in RadMaskedTextInput for example:
<telerik:RadMaskedTextInput Mask="" Width="150" MaxHeight="100"> <telerik:RadMaskedTextInput.TextBoxStyle> <Style TargetType="telerikMaskedInput:PreviewInputTextBox" BasedOn="{StaticResource MaskedInputTextBoxStyle}"> <Setter Property="TextWrapping" Value="Wrap" /> <Setter Property="Width" Value="100" /> <Setter Property="AcceptsReturn" Value="False" /> <Setter Property="ScrollViewer.VerticalScrollBarVisibility" Value="Visible"/> </Style> </telerik:RadMaskedTextInput.TextBoxStyle> </telerik:RadMaskedTextInput>This requires that you are using NoXAML binaries and our implicit styles theming mechanism so that yo can inherit the MaskedInputTextBoxStyefrom our themes (by using the BasedOn property). You can find more information about the mentioned approach here.
Regards,
Evgenia
Telerik by Progress
Do you need help with upgrading your AJAX, WPF or WinForms project? Check the Telerik API Analyzer and share your thoughts.
0
Chad
Top achievements
Rank 1
Rank 1
answered on 28 Sep 2016, 09:34 PM
Thank you Evgenia.
Seems like a bit of a run-around to get the scrollbars implemented not to mention that it might require additional maintenance on version upgrades if I understand the process correctly. Can we add native scrollbars properties as a feature request for the MaskedTextInput?
Regards,
0
Hi Chad,
The code snippet I provded doesn't require no maintenance on version upgrades. Let me explain why in more details. The Style I provided targets the PreviewInputTextBox control (it inherits standart TextBox and is responsible for handling the masked input provided) that is part of the control template of the RadMaskedTextInput control. Since you are using the RadMaskedTextInput control you simply imitate TextBox control (no Mask needed). How would you make a native MS TextBox into multiline one -- by setting TextWrapping property to Wrap or WrapWithOverflow (to automatically wrap lines of text to multiple lines). Also if you want the user to be able to press Enter or Return to move to a new line, you can set the AcceptsReturn property to true. Finally to visually indicate that a TextBox has more lines than currently fit into the visible region of the TextBox you'll want to set the VerticalScrollBarVisibility property to Auto or Visible.
That's exactly what the style I provided is doing - tweaking the mentioned properties for the PreviewInputTextBox inside RadMaskedTextInput.
As you can see -- we exposed many dependency properties for different situations in our MaskedInput control. However we don't see reason to add more just to tweak properties that should manage the inner PreviewInputTextBox control firtsly because this is easily achievable with style as already demonstrated and secondly because we don't want to affect the performance of the control with such modifications.
Regards,
Evgenia
Telerik by Progress
The code snippet I provded doesn't require no maintenance on version upgrades. Let me explain why in more details. The Style I provided targets the PreviewInputTextBox control (it inherits standart TextBox and is responsible for handling the masked input provided) that is part of the control template of the RadMaskedTextInput control. Since you are using the RadMaskedTextInput control you simply imitate TextBox control (no Mask needed). How would you make a native MS TextBox into multiline one -- by setting TextWrapping property to Wrap or WrapWithOverflow (to automatically wrap lines of text to multiple lines). Also if you want the user to be able to press Enter or Return to move to a new line, you can set the AcceptsReturn property to true. Finally to visually indicate that a TextBox has more lines than currently fit into the visible region of the TextBox you'll want to set the VerticalScrollBarVisibility property to Auto or Visible.
That's exactly what the style I provided is doing - tweaking the mentioned properties for the PreviewInputTextBox inside RadMaskedTextInput.
As you can see -- we exposed many dependency properties for different situations in our MaskedInput control. However we don't see reason to add more just to tweak properties that should manage the inner PreviewInputTextBox control firtsly because this is easily achievable with style as already demonstrated and secondly because we don't want to affect the performance of the control with such modifications.
Regards,
Evgenia
Telerik by Progress
Do you need help with upgrading your AJAX, WPF or WinForms project? Check the Telerik API Analyzer and share your thoughts.
0
Chad
Top achievements
Rank 1
Rank 1
answered on 03 Oct 2016, 10:19 PM
Thanks Evgenia,
I appreciate the effort in your explanation but I'm referring to prerequisite of "This requires that you are using NoXAML binaries and our implicit styles theming mechanism" from your first response. Also going that route will require us to keep the 'imported' telerik xamls in sync and secondly deprive us from the currently built-in multi-themed application support. Please tell me I'm wrong :).
Regards,
Chad
0
Hello Chad,
I understand your point but I still think that there is no need to keep the xaml styles synced with the ones we provide manually. Here's why -- you won't do a copy-paste of the implict style files we are shipping in your project unless you are doing a custom theme where you directly modify our predefined styles.
What I really meant is that you'll only add the setters I mentioned and the BasedOn will do the major work -- inheriting the default style for the MaskedInputTextBoxStyle from the corresponding theme. How you'll achieve this -- by merging the style files directly from the theme assembly and not from a local folder in your project. On upgrade when you change the assembly -- the style files will automatically be synced:
Some time ago I wrote a detailed explanation on why we highly recommend implicit styles theming mechanism to our clients and how exactly it works so please take your time to see it (here is link to it).
Let me know how this works for you.
Regards,
Evgenia
Telerik by Progress
I understand your point but I still think that there is no need to keep the xaml styles synced with the ones we provide manually. Here's why -- you won't do a copy-paste of the implict style files we are shipping in your project unless you are doing a custom theme where you directly modify our predefined styles.
What I really meant is that you'll only add the setters I mentioned and the BasedOn will do the major work -- inheriting the default style for the MaskedInputTextBoxStyle from the corresponding theme. How you'll achieve this -- by merging the style files directly from the theme assembly and not from a local folder in your project. On upgrade when you change the assembly -- the style files will automatically be synced:
<Application.Resources> <ResourceDictionary> <ResourceDictionary.MergedDictionaries> <ResourceDictionary Source="/Telerik.Windows.Themes.Office_Black;component/Themes/System.Windows.xaml"/> <ResourceDictionary Source="/Telerik.Windows.Themes.Office_Black;component/Themes/Telerik.Windows.Controls.xaml"/> <ResourceDictionary Source="/Telerik.Windows.Themes.Office_Black;component/Themes/Telerik.Windows.Controls.Navigation.xaml"/> <ResourceDictionary Source="/Telerik.Windows.Themes.Office_Black;component/Themes/Telerik.Windows.Controls.GridView.xaml"/> <ResourceDictionary Source="/Telerik.Windows.Themes.Office_Black;component/Themes/Telerik.Windows.Controls.Input.xaml"/> <ResourceDictionary Source="/Telerik.Windows.Themes.Office_Black;component/Themes/Telerik.Windows.Controls.Data.xaml"/> </ResourceDictionary.MergedDictionaries> </ResourceDictionary> </Application.Resources>Some time ago I wrote a detailed explanation on why we highly recommend implicit styles theming mechanism to our clients and how exactly it works so please take your time to see it (here is link to it).
Let me know how this works for you.
Regards,
Evgenia
Telerik by Progress
Do you need help with upgrading your AJAX, WPF or WinForms project? Check the Telerik API Analyzer and share your thoughts.
0
Chad
Top achievements
Rank 1
Rank 1
answered on 10 Oct 2016, 02:32 AM
Hi Evgenia,
Sadly after two days and two attempts we'll have to give it a miss. Although it's working and after a ton of styling rework on a 65(loaded) project solution the memory footprint increase and stability is just not worth the risk. I've done everything in my power in the allotted time to try and decrease the memory footprint to within range of our baseline application to no avail. We have also noticed some slowdowns in certain areas and after optimizing by hand could not get the original performance back. This is by no means a simple app where you just throw the themes into an app.xaml and then start styling.
Here is what I done...
[done] Replaced all standard binaries with the NoXaml binaries.
[done] Rename existing RadFooStyle to something like MyRadFooStyle. (never knew about implicit styling names)
[done] Remove all theme references from app and libs.
[done] Update code and code gen templates that utilized above style names.
[done] Added style for each control used and dependent element.
[done] Update the BasedOn for all code and code gen templates that used nested styles(mostly to apply automation ids).
[busy] Moved all local styles out to be dynamically applied to decrease memory footprint.
[done] Update build scripts on build server to utilize the new NoXaml dlls.
[busy] Test end results using UI tests, manual tests
So in conclusion, breaking a stable application to implement implicit styles just to be able to add scrollbars to a RadMaskedTextInput is not worth the risk. Have we known from day one that adding basic functionality to rad controls would require "Implicit Styles" we would not have bothered with the default styling mechanism. It also raises the question to that's the point of the default styling mechanism if you can't even style the basic 'textbox' replacement to enable scrollbars.
The failure is most likely due to some error on our end but also due to your assumption of the simplicity of converting an existing large project to use "Implicit Styles". Believe me when I tell you that we would have loved to have implicit styles working but right now the risk/reward ratio is making implicit styles no longer an option.
Do you have any other suggestions or should we just revert back to our old controls that exposed the necessary styling to allow for scrollbars?
Regards,
Chad
Sadly after two days and two attempts we'll have to give it a miss. Although it's working and after a ton of styling rework on a 65(loaded) project solution the memory footprint increase and stability is just not worth the risk. I've done everything in my power in the allotted time to try and decrease the memory footprint to within range of our baseline application to no avail. We have also noticed some slowdowns in certain areas and after optimizing by hand could not get the original performance back. This is by no means a simple app where you just throw the themes into an app.xaml and then start styling.
Here is what I done...
[done] Replaced all standard binaries with the NoXaml binaries.
[done] Rename existing RadFooStyle to something like MyRadFooStyle. (never knew about implicit styling names)
[done] Remove all theme references from app and libs.
[done] Update code and code gen templates that utilized above style names.
[done] Added style for each control used and dependent element.
[done] Update the BasedOn for all code and code gen templates that used nested styles(mostly to apply automation ids).
[busy] Moved all local styles out to be dynamically applied to decrease memory footprint.
[done] Update build scripts on build server to utilize the new NoXaml dlls.
[busy] Test end results using UI tests, manual tests
So in conclusion, breaking a stable application to implement implicit styles just to be able to add scrollbars to a RadMaskedTextInput is not worth the risk. Have we known from day one that adding basic functionality to rad controls would require "Implicit Styles" we would not have bothered with the default styling mechanism. It also raises the question to that's the point of the default styling mechanism if you can't even style the basic 'textbox' replacement to enable scrollbars.
The failure is most likely due to some error on our end but also due to your assumption of the simplicity of converting an existing large project to use "Implicit Styles". Believe me when I tell you that we would have loved to have implicit styles working but right now the risk/reward ratio is making implicit styles no longer an option.
Do you have any other suggestions or should we just revert back to our old controls that exposed the necessary styling to allow for scrollbars?
Regards,
Chad
0
Accepted
Hello Chad,
I see your point and indeed I should confirm that by not knewing all details about your project Implicit Styles seemed like the best solution to me. Also I should confirm that migrating to implicit styles from StyleManager is not a smooth process and will require big timeframe on your side (having in mind how big your project is). And yes -- you are correct, I don't see point in migrating to implicit styles theming mechanism just to make your MaskedTextInput multiline.
Luckily I have a solution that will let you stick with the StyleManager theming mechanism and will make it possible to add the required properties to the MaskedInputTextBox PreviewInputTextBox. There's no need to retemplate nothing in XAML.
The solution I'm suggesting is to create a custom MaskedInputText control that inherits our RadMaskedInputText control. The purpose is to override its OnApplyTemplate method. This method's body makes it possible to traverse the control template and find the PreviewInputTextBox by its name when the template is loaded. Now you can add the properties that I previously described to make this TextBox appear multiline with vertical scrollviewer. Here's sample code snippet:
And XAML:
Please don't forget to set the required DefaultStyleKey for the custom control you are creating as described in our documentation.
Let me know if you need any further assitance with this approach.
Regards,
Evgenia
Telerik by Progress
I see your point and indeed I should confirm that by not knewing all details about your project Implicit Styles seemed like the best solution to me. Also I should confirm that migrating to implicit styles from StyleManager is not a smooth process and will require big timeframe on your side (having in mind how big your project is). And yes -- you are correct, I don't see point in migrating to implicit styles theming mechanism just to make your MaskedTextInput multiline.
Luckily I have a solution that will let you stick with the StyleManager theming mechanism and will make it possible to add the required properties to the MaskedInputTextBox PreviewInputTextBox. There's no need to retemplate nothing in XAML.
The solution I'm suggesting is to create a custom MaskedInputText control that inherits our RadMaskedInputText control. The purpose is to override its OnApplyTemplate method. This method's body makes it possible to traverse the control template and find the PreviewInputTextBox by its name when the template is loaded. Now you can add the properties that I previously described to make this TextBox appear multiline with vertical scrollviewer. Here's sample code snippet:
public class MultilineMaskedTextInput : RadMaskedTextInput { public override void OnApplyTemplate() { var previewInnerTextBox = Template.FindName("EditorSite", this) as PreviewInputTextBox; previewInnerTextBox.AcceptsReturn = false; previewInnerTextBox.TextWrapping = System.Windows.TextWrapping.Wrap; ScrollViewer.SetVerticalScrollBarVisibility(previewInnerTextBox, ScrollBarVisibility.Visible); base.OnApplyTemplate(); } }And XAML:
<local:MultilineMaskedTextInput Mask="" Width="150" MaxHeight="100" />Please don't forget to set the required DefaultStyleKey for the custom control you are creating as described in our documentation.
Let me know if you need any further assitance with this approach.
Regards,
Evgenia
Telerik by Progress
Do you need help with upgrading your AJAX, WPF or WinForms project? Check the Telerik API Analyzer and share your thoughts.
0
Chad
Top achievements
Rank 1
Rank 1
answered on 17 Nov 2016, 10:57 PM
Hi Evgenia,
Time flies and today I was able to implement the solution, works great, thank you.
Regards,
Chad