We have the requirement that on some undeterministicly fired hardware events, depending on the event, the GUI changes. Due to the GUI cmnplexity this may take a few seconds.
Now the problem. If I click on a button while GUI is still busy sometimes the wrong button is invoked because after GUI layouting this button is now at the mouse coordinates where the click occured before.
Iam sure with Windows Forms the behaviour was different. Can I get around this behaviour?
You can :
Hide or cover the UI when it is refreshing (with a Busy Indicator for example)
Optimize the refresh (see MSDN Wpf Optimization category, especially Layout and design)
The quick and dirty - store a IsRefreshing variable and use it to diable the buttons or cancel your buttons handlers
EDIT
The real question is : what is your bottleneck ? the UI refresh or the logic behind ?
Related
I have an "odd" situation.
I've got a form with a binding source and a binding navigator.
In this instance, I've got 161 records (via EF6) to display.
The databinding to the controls works nicely.
But what I find is that the expected events for the binding navigator don't happen consistently. Then they settle down.
I've got event handlers (additional to the default ones, but the same thing happens when I remove the default ones as well)
I set the binding source one the navigator, and the "Position Changed" event is raised (as I'd expect)
Clicking on any of the "Move" buttons, or editing the position field will result in:
No event being raised (not the item click events, not the binding source Position Changed) roughly 3 out of 4 times.
Then the event raises, all the expected navigation occurs, and repeat.
But it doesn't seem to be permanent, because after a while almost all the records have the navigation all starts working properly.
This happens with and without the debugger connected.
The other thing I notice is that when it fails, the icon in the taskbar flashes once.
It's not something in any of my handler code, because it never gets to my code.
It might be a property setting.
It's not an exception, because even with "break on all exceptions", no exception is reported.
When you talk about "move" buttons, I take it that you mean the next/previous record navigation buttons on the BindingNavigator. Those buttons are not full-fledged Windows controls, but rather they are "lightweight" controls. I've seen issues in the past because of this.
While I do not have all the details fresh in memory, it had to do with the fact that they don't steal the focus away from other controls as regular Windows controls do, and this caused some events to not be raised.
I suggest you create your own navigation buttons, which is what I ended up doing on all my Windows Forms project. Those regular buttons can then call the BindingSource methods such as MoveNext and so on.
As I am trying to make my own custom "WinForms", I am left confused on when does each mouse event occurs. I have made my own custom classes, but now the events are something I have to rework, as they won't work right.
I have a custom class for controls. Objects from that class can contain other controls, which can contain other controls and so on. There is a main control, which gets input from a picture box. That input is what is where the mouse is and what even has been activated in the picture box.
So far I have figured, that MouseMove, MouseHover and MouseDown events are the simplest to write, as they occur in simple conditions. But the rest require additional data about the mouse's location, state and past. MouseDoubleClick seems to activate after a specific sequence of events (strictly down-up-down-up, down-up-down-move-up and down-up-down-move-leave-enter-move-up, with the movement events not activating). With that in mind, I am even more confused.
In what conditions and sequences does each mouse event occur?
EDIT
Further testing made things even more confusing. For one, now I want to know at what rate is the MouseMove being registered, and testing it shows that between each event there is a different time (or so does my use of a StopWatch say). This is important, because then that raises the question when is Hover being triggered.
Click is down-up, where moving is allowed between the two.
DoubleClick proved to be simple enough - down-up-down-up, where moving is allowed explicitly only between the second down-up.
Hover activates only once after each Enter, when the mouse remains stationary; if you want to trigger Hover again, the mouse has to leave and then re-enter.
So the question now is how the system tracks the mouse's activity - how does it detect the mouse moving, being held down and being released. Hopefully that would help me get the full answer.
From a production application, we notice that our WPF buttons fire the ICommand.Execute method twice on fast double click.
Now, on every Command, the application is covered with a full-screen spinner animation, preventing any further interaction with the application.
This github repo contains a minimalistic repro of the issue. Note that:
when the Button's Command fires, the "IsBusy" flag is set to true
as a consequence, the BusyIndicator overlay will be shown
as a consequence, the Button cannot be pressed again until after 300ms
However, especially on slow computers, when fast double-clicking (really fast, like gaming fast that is), it is possible to fire the command twice without the BusyIndicator blocking the second call (this can be seen if the output shows 2 'click' lines right after one another).
This is unexpected behavior to me, as the IsBusy flag is set to true right away on the UI thread.
How come a second click is able to pass through?
I would expect the IsBusy Binding to show the overlay on the UI thread, blocking any further interaction?
The github sample also contains 2 workarounds:
using the ICommand.CanExecute to block the Execute handler
using the PreviewMouseDown to prevent double clicks
I'm trying to understand what the issue is.
What work-around would you prefer?
Diagnosis
This is only my guess and not a solid and confirmed info, but it seems that when you click the mouse button, the hit-testing is done immediately, but all the mouse related events are only scheduled to be raised (using the Dispatcher I presume). The important thing is that the control that is clicked is determined at the time the click occurred, and not after the previous click has been completely handled (including all UI changes that potentially follow).
So in your case, even if the first click results in showing the BusyIndicator covering (and thus blocking) the Button, if you manage to click for the second time before the BusyIndicator is actually shown (and that does not happen immediately), the click event on the Button will be scheduled to be raised (which will happen after the BusyIndicator is shown), causing the command to be executed again even though at that point the BusyIndicator will possibly be blocking the Button.
Solution
If your goal is to prevent command execution while the previous one is still executing the obvious choice is to make the Command.CanExecute result depend on the state of the IsBusy flag. Moreover, I wouldn't even call it a workaround, but a proper design.
What you're facing here is a clear-cut example of why you shouldn't make your business logic rely on UI. Firstly, because rendering strongly depends on the machine's processing power, and secondly because covering a button with another control by far does not guarantee the button cannot be "clicked" (using for example UI Automation framework).
The title sounds like some easy well-known problem, but please check out this:
I've got some WPF window that handles a list of Threads and shows ProgressBar for each Thread. The invoked GUI refresh is working for most threads showing right number of percent and also for unknown progress the IsIndeterminate state is animated. After the thread is done some animation fades out the ProgressBar.
However, for some of my heavy tasks the ProgressBar is not visually updated. For example, the IsIndeterminate state refreshes only if I force the GUI to redraw by some mouseover events or by moving the form. The fade out animation shows the same problem.
I think this is no usual stucking because the UI thread is not blocked by further operations (there's only one invoke setting IsIndeterminate = true). Until now, I wasn't able to find out what's the different between heavy tasks that result in this behavoir and tasks that do not.
Please notice that the replacement of the Thread by a BackgroundWorker shows exactly the same problem (I'm also not sure why people say BackgroundWorker will not freeze the GUI but Threads allegedly do - this seems not entirely right). Please also notice that although the thread is paused by Thread.Suspend() (yes, I know it's obsolete but this is an essential feature I need, since the task content is unknown) the GUI will not show up the IsIndeterminate animation if no other GUI element forces the refresh of the window.
Any ideas what that problem might be and how to fix it? I just need the usual refreshing rate for drawing animated controls...
I am working on the touch screen application which is running on Windows XP Standard. With current hardware to invoke a right click user has to click and hold for couple of seconds, but this might interfere with other actions like holding a repeat button in the scrollviewer, so I have decide to disable a right click.
I would ideally wan't to disable a right click on the application level, but if it is not possible, disable right click on windows level would also work for me.
The OnPreviewMouseRightButtonDown/Up approach did not work for me.
There is a property Stylus.IsPressAndHoldEnabled on UIElement however. Set that to false to get rid of the press and hold right click behavior. I tested this on Windows 7 with .NET 4.0, but the property is available from .NET 3.0.
<RepeatButton Stylus.IsPressAndHoldEnabled="false" ... />
There is also a blogpost here that provides a code sample for a similar disabling of press and hold at window level. But with this in place, the PreviewTouchDown and TouchDown events will not be raised as soon as the finger touches the screen (which would be necessary for a RepeatButton I guess), only later. Read the 'Remarks' on this msdn page.
You can override the OnPreviewMouseRightButtonDown on the Window and set Handled to true. You also need to handle OnPreviewMouseRightButtonUp (thanks to Vitalij for pointing this out)
That should do the trick.