How to reset a silverlight control's visual state back to "Normal" on change of visibility
In the above link, the same thing was discussed, though i have some problem with changing the state.
I have read an article says that if VS is in a state and if we force it to Goto that state it just returned with true. this is fine but in my cause, am having a button and that button is in a popup. when the button clicks, am closing the popup. while open the popup again seems the mouse hover state is applied till. Though am forcing the Vs for Normal state in popup open event it remains in the old state. While forcing the VS it returns true which means Normal state s applied but UI remains still in the Mouse hover state.
What might be the cause?
Related
According to the Developer Guide, to make a toggle button I should run setToggle(true) on a CheckBox. I couldn't get that to work at first, so I tried on a new theme and it worked just fine. After some experimentation I found that this only happens when includeNativeBool constant is set to false.
When I press the button, it changes to the pressed state, but when I release it, it changes back to the unselected/selected state. However, when I press it a second time, it doesn't change to the pressed state at all (maybe because it's internally "checked" already), and when I release it nothing happens. When I press it a third time, it behaves like the first, and so on.
I suggest not removing the includeNativeBool, you will run into basic complexities.
The toggle button works just as well without includeNativeBool but the the styles for ToggleButton won't be in the theme. Assuming you styled Button just use setUIID("Button");
I've got a window (which acts as a kind of popup window) with a couple of buttons inside. The popup disappears after some time. However, when the window is activated I don't want it to disappear until it is deactivated. I achieve this by listening to the Activated and Deactivated events.
The problem arises when I start calling Focus() on the elements inside the window. This focuses the element as expected, however, additionally IsActive of the window seems to change to true.
This is not the behavior I am after. Surprisingly, this is also not visible in the UI. The window does not get styled as if it is activated (black shadow).
Can I move the focus in a window, without activating it?
I have a threestate RadioButton (same issue with ToggleButton) with a custom template in WPF (using Blend 4.0) and I turn it to 'Indeterminate' state on Load. This works fine, and I want to keep it in that state till the user clicks it. The problem is it changes to Unchecked state as soon as the user puts the mouse over it.
How can I prevent this unwanted change of state from happening? Is this the default behavior or something I might have changed accidentally?
I also would like that after clicked it would chang directly to the 'Checked' state but that's a different question and I've read it might have to do with changing the order of states.
I have a top-level menu item which is responsible for refreshing a datagrid in the same window. My current control flow is:
User clicks on refresh
In the click event handler, I:
Disable the menuitem, by setting oMenuItem.IsEnabled = false.
Dispatch an action to refresh the grid and in that action, I re-enable the menuitem, by setting IsEnabled = true
The problem is that the user can click refresh even when it's disabled and it's as if the clicks get queued up. When the action returns it goes on to process the remaining, "queued-up" clicks. What I expect is: all clicks while the menuitem is disabled are ignored and only when it's enabled, the clicks are acknowledged.
The weird thing is that if I just disable it and never enable it it stays that way, i.e., it is disabled.wpf,
"Dispatch an action" you mean by calling Dispatcher.BeginInvoke() or some other kind of async opetation?
Anyway, in both cases you can get a "handle" to the operation (DispatcherOperation or IAsyncResult) and store it as a field when you dispatch your operation. When it completes - set this field to null.
In the click event handler of the menu-item check this field. If it's null it means it is safe to start the operation. If it is not null - return immediately and do nothing.
And something not related to your question but important - why not use Commands? That way you don't need to play with event handling and enabling/disabling. And of course commands can be invoked by multiple means (for example - the user selected the command from the menu using the keyboard and pressed Enter. No mouse clicks involved, but should do the same as clicking the menu item).
Alex.
I have a button which launches a "modal dialog" - it just creates a transparent grid covering everything, with the "dialog" created on top of that.
However I have a strange issue - if I double/triple click the button really fast (or add some delay in the event code), the button click event is executed multiple times, creating multiple overlapping modal dialogs. If the first action in my event is to disable the button (IsEnabled=false) it seems to prevent this.
My guess is that Silverlight is being multithreaded with input - it is not only recording the second click in another thread (while the button's click event is running), but it is jumping the gun by evaluating which control should be the target before the previous event has finished executing. Even though that event alters what control is at those mouse coordinates, it doesn't matter.
Does anyone know anything about this behavoir, or a way around it? If I have something like a save window, where the user clicks a save button, a blocking grid ("Saving...") is placed up while it saves, and then the whole "window" is closed, I'd like to avoid the user being able to queue up multiple save event clicks (this could lead to unpredictable program behavoir).
If you've ever worked with WinForms or WPF, this is expected behavior. Your button is broadcasting its Click event until your modal dialog covers it up. Unfortunately, there is some amount of time between your first click and when the modal dialog covers the button which allows multiple clicks to the original button.
You have two solution choices:
Disable the button after the first click and then re-enable after the modal dialog returns. You've already mentioned that this works.
Write code in the Event Handler of the button to determine if a modal dialog is already being displayed. This way, you're putting the responsibility in one location rather than splitting it up (disabling and re-enabling the button). This would be my preferred solution.
I think what you're seeing is the behaviour of Silverlight's routed events.
You can set the Handled property of the event arguments to true to prevent the event from bubbling.