Visible buttons changing depending on the mode

[Patrick]

Hello,

I have a RadWindow with 5 buttons, with only one or two of them visible at a given time. I would like, for example, that the Escape keyboard key has the Close action when in view mode and the Cancel Changes action when in edit mode.

To do this I use the tk:RadWindow.ResponseButton="Cancel" attribute for both buttons.

The problem is that the RadWindow logic is to look for the first button with this attribute and simulate a Click event on this button. I suggest that you make a small change to this behavior, to look for the first visible and enabled button with this attribute. By Visible, I mean with the Visibillty property set to Visible.

I know that I can process the Escape key myself, but why reinvent the wheel?

Best regards

[Martin Ivanov]

Hello Patrick,

Thank you for the feedback.

Actually, the response button functionality is looking for the first button which IsEnabled property is True. Can you consider using this in your case and see if it helps? Basically, when changing the visibility, you can also update the IsEnabled property of the button.

Regards,
Martin Ivanov
Progress Telerik

[Patrick]

Hi Martin,

Yes I can, as I can also process myself the keyboard events.

For 5 buttons with 4 different modes, that's 40 additional lines of code, that makes the code less readable and more error prone.
I think that the change I propose is a welcome addition to the RadWindow behavior.

 

Regards

[Martin Ivanov]

Hello Patrick,

You can consider the following approach and see if it works for you.

<StackPanel x:Name="buttonsPanel">
	<StackPanel.Resources>
		<telerik:VisibilityToBooleanConverter x:Key="VisibilityToBooleanConverter" />
		<Style TargetType="telerik:RadButton">
			<Setter Property="IsEnabled" Value="{Binding RelativeSource={RelativeSource Mode=Self}, Path=Visibility, Converter={StaticResource VisibilityToBooleanConverter}}" />
		</Style>
	</StackPanel.Resources>
</StackPanel>

The idea of this approach is to bind the IsEnabled property of the buttons to their Visibility, in order to take advantage of IsEnabled's integration with the ResponseButton behavior. You can add this implicit style in the Resources of the panel that holds the buttons. This way you won't need to support 40 additional lines of settings. 

I've attached a small example showing this approach. I hope it helps.

Regards,
Martin Ivanov
Progress Telerik

[Patrick]

Hi Martin,

Thank you for your info, I will try itafter my holidays.

In between, two remarks:

1. The online documentation of VisibilityToBooleanConverter doesn't give any information: we have three values for Visibility and two for Boolean; how are the values converted?

2. The offline documentation doesn't talk about VisibilityToBooleanConverter...

[Martin Ivanov]

Hello Patrick,

I have logged an internal task to describe the VisibilityToBooleanConverter in the Converters article. You can find your Telerik points updated for bringing this to our attention. In the meantime, here is what the Convert and ConvertBack methods of the converter do. If this doesn't help you can write your own IValueConverter that executes custom logic.

public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
	return value is Visibility && (Visibility)value == Visibility.Visible;
}

public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
	return (bool)value ? Visibility.Visible : Visibility.Collapsed;
}

About the online documentation differences, currently the VisibilityToBooleanConverter class is presented in the API Reference documentation - both in the online and offline versions.

Regards,
Martin Ivanov
Progress Telerik

[Patrick]

Hi Martin,

Thank you for the information.

I would like to tell you that you can improve your VisibilityToBooleanConverter, by using the ConverterParameter to define the Visibility to return when the Boolean value is False. Having a default value of Collapsed will have the converter work the same way when no parameter is specified.

 

Your converter code can also optimized:

public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
  var Value = value as Visibility;
  return (Value != null) && (Value == Visibility.Visible);
}

 

Doing so will avoid casting the value parameter twice (once for the is test and once for the cast), as casting can be slow.

 

Note also that the ConvertBack method doesn't check whether value is a Bool before casting, so it can generate an exception.

Final note: it would be nice if the converter can accept a Nullable<Bool>, as, for example CheckBox.IsChecked.

[Martin Ivanov]

Hello Patrick,

Thank you for the suggestions. Based on this I've logged a feature request to implement an InvertedVisibilityToBooleanConverter (similar to the InvertedBooleanToVisibilityConverter). This will cover the first part of your feedback, with the ConverterParameter idea, and it will keep the API more consistent. I also included your feedback about the casts and the nullable bool in the already existing converter. 

Regards,
Martin Ivanov
Progress Telerik

[Patrick]

Martin,

there is no need to implement "InvertedXxx" converters, because converters can have parameters.

In my WPF library, I have implemented a TrueIfNullConverter that can be used to have the true value when a property is null or not null, the converter is used in the following way in app.xaml.

<os:TrueIfNullConverter             x:Key="TrueIfNullConverter" />
<os:TrueIfNullConverter             x:Key="TrueIfNotNullConverter" IsInverted="True" />

So I can use the TrueIfNullConverter and the TrueIfNotNullConverter converters in my XAML code!

[Martin Ivanov]

Hello Patrick,

Thank you for the feedback on the converter parameter. I see your point here and it is meaningful, but I've logged the item with a separate class name (InvertedVisibilityToBooleanConverter) in order to be consistent with the currently existing API. Currently, there are few inverted converters. However, I've included your converter parameter suggestion in the internal item, so when we plan to implement the converter, we will review it and decide what approach to use. 

Regards,
Martin Ivanov
Progress Telerik