CSLA For SilverLight - PropertyStatus enhancment suggestionCSLA For SilverLight - PropertyStatus enhancment suggestion
Old forum URL: forums.lhotka.net/forums/t/6412.aspx
paupdb posted on Thursday, February 12, 2009
Hi Rocky and Magenic guys
The PropertyStatus is cool, I'm using it quite extensively with great results.
However I have one niggle with it - that being that it cannot be collapsed when not in use.
If I set the PropertyStatus.Visibility to Collapsed, then the PropertyStatus actions aren't visible at all.
Now the reason I would like to be collapsed is that I have layered the PropertyStatus on top of input controls like TextBox, ComboBox etc. When the PropertyStatus has it's Visibility = Visible, then users cannot click on the control underneath the area the PropertyStatus occupies.
Good news is I have an easy fix that it would be cool to see go into CSLA 3.6.2:
In the PropertyStatus ctor:
public PropertyStatus()
: base()
{
RelativeTargetPath = "Parent";
BrokenRules = new ObservableCollection<BrokenRule>();
DefaultStyleKey = typeof(PropertyStatus);
IsTabStop = false;
Visibility = Visibility.Collapsed;
And then in the GoToState method, add appropriate Visibility settings:
if (_isBusy)
{
this.Visibility = Visibility.Visible;
VisualStateManager.GoToState(this, "Busy", useTransitions);
}
else if (_isValid)
{
this.Visibility = Visibility.Collapsed;
VisualStateManager.GoToState(this, "Valid", useTransitions);
}
else
{
this.Visibility = Visibility.Visible;
VisualStateManager.GoToState(this, _worst.ToString(), useTransitions);
_lastImage = (FrameworkElement)FindChild(this, string.Format("{0}Image", _worst.ToString().ToLower()));
EnablePopup(_lastImage);
}
Let me know what you think. The above change works really well for me :)
davido replied on Friday, February 13, 2009
Could you explain this a bit more please?
"then users cannot click on the control underneath the area the PropertyStatus occupies"
Don't you want them to be able to click on the control underneath so they can fix the problem?
paupdb replied on Friday, February 13, 2009
The PropertyStatus control is transparent and 16 x 16 pixels in size by default.
When you layer it on top of a control - say a combobox with the PropertyStatus being right, top aligned - then user clicks hit the PropertyStatus instead of the combobox within that 16x16 area.
The user can still click the control anywhere else that the PropertyStatus doesn't cover, but the control appears "broken" to them when they click where the PropertyStatus is.
By collapsing the PropertyStatus my change enables the user click to hit the underlying control when the PropertyStatus is valid.
The current behaviour remains for cases where the PropertyStatus is invalid or busy.
To a user, when they can see the error or busy images, then not being able to click on the control underneath that area is OK - its only when the PropertyStatus is valid (transparent) that they come back with negative feedback about not being able to click the control in that area under the PropertyStatus.
ajj3085 replied on Friday, February 13, 2009
Just curious, why would you layer the PropertyStatus on top of the edit control?
paupdb replied on Friday, February 13, 2009
Its a long story, but I am dynamically generating the controls that appear on certain pages and in these pages the spacing between controls is fairly limited as it is.
If the PropertyStatus was stacked on the end of each control, I end up losing a fair amount of screen real estate across a line - 16pixels * 5-6 controls a line.
Also when the PropertyStatus is stacked on the end and displays an icon, then it looks pretty bad without decent spacing to the next control on the line.
Additionally because of the limited spacing, it became harder for the user to tell which control the PropertyStatus referred to - whether it was the control to the left or right.
By having the error icon appear over the control - tucked into the top right corner - I save space whilst clearly highlighting the control at fault.
So yeah its aesthetics primarily.
RockfordLhotka replied on Friday, February 13, 2009
My only concern with a change like this, is that it could mess up the UI layout for people who aren't layering the control over the top of an existing control.
I really wish Silverlight had the Hidden visibility, but it doesn't, and so there's always the risk of a collapsing control shifting the entire UI in some odd way.
paupdb replied on Friday, February 13, 2009
You could add a property to the PropertyStatus that toggles the behaviour I added - e.g. bool Hidden.
That way if the default Hidden setting (e.g. false) is to behave as the current PropertyStatus does, all people in my situation would need to do is explicitly set Hidden to true.
Either that or open up the PropertyStatus for subclassing - make GoToState a protected virtual method.
justncase80 replied on Wednesday, March 03, 2010
This might be worth discussing more.
The reason it's set to Hidden rather than Collapsed by default is because setting it to collapsed can affect layout. Meaning, if it's in a StackPanel (for example) when it's collapsed the things later in the stack will move. When the Collapsed control becomes visible your other controls would shift yet again.
If you put it in a Grid or Canvas where it can overlap other controls that's a different story, though I'm not sure I would recommend doing that exactly. However if you wanted to actually change the visibility to collapsed there's another easy solution with the current control:
<csla:BusyAnimation Visibility="{Binding IsBusy, Converter={StaticResource booleanToVisibilityConverter}}" />
This will set it to collapsed when IsBusy is false.
justncase80 replied on Wednesday, March 03, 2010
Actually I believe in that Binding you have to set RelativeSource={RelativeSource self} as well...
ajj3085 replied on Wednesday, March 03, 2010
Rocky does cover that, but personally I think it's a fine idea. Don't set Hidden unless you know what you're doing, basically.
I checked the bug though to see what ultimately came of this, but the issue tracker says no such bug.
RockfordLhotka replied on Wednesday, March 03, 2010
That bug was merged into another similar bug. Justin has the number.
But I don't think there's value to having PropertyStatus hard-code the ability to do this when it can be handled through binding. In fact, relying on binding means the flexibility is far greater than if we create one or two restrictive schemes.
My recommendation is to not act on the bugtracker item, since there's a very good solution as-is.
ajj3085 replied on Wednesday, March 03, 2010
Hmm, I must be confused about something then. Wouldn't be the first time.
RockfordLhotka replied on Wednesday, March 03, 2010
The bug was reported twice, and I merged the two reports.
http://www.lhotka.net/cslabugs/edit_bug.aspx?id=230
But it seems to me (now as it did then) to make little sense to have PropertyStatus hard-code some behavior when you can get the desired behavior through binding - along with other possible behaviors (such as making the control bigger/smaller, changing its appearance in other ways, etc).
In short, with Xaml I've come to the conclusion that less is more - at least when it comes to controls. It is better to expose properties and let people creatively bind them, than to hard-code limited behaviors and then have people come back in a few weeks/months and ask for yet another hard-coded behavior to be added.
Copyright (c) Marimer LLC
