I did not find the answer anywhere, so I'll make new question. I have datagrid, where is some code after SelectionChanged event. And some code on DoubleClick(tried MouseDoubleClick, CellDoubleClick and DoubleClick). On fast PC there is no problem, but on my windows 8 tablet with Intel Atom, where is the app slower, is not fired DoubleClick because of SelectionChange.
If I comment code on SelectionChange, then DoubleClick is fired. But when I leave the code, it seems like it is so slow, that it did not recognize DoubleClick. I have to click realy fast (7-8 times) to fire it.
I thought there is some kind of queue. So that DoubleClick should be fired after SelectionChange at least.
I can't wait after SelectionChange is fired to see if it is not a DoubleClick. Then will look the app slow even on fast pc.
How can be this event lost?
It sounds like you may be doing work on the main thread, try using a different thread to do your processing, freeing up your UI thread to receive the double click.
You will need to do some synchronizing, but it should relieve the race condition if done correctly.
You shouldn't do any long calculations in an event handler. I suggest starting a new thread (or borrow one from the threadpool, or start a new task), and do the longer running code on a background thread.
Related
C# windows application's GUI halt on re-sizing application and i have to kill the process from task Manager.
I have search for the issue and got a link that point me to background invoker and other point me to userpreferencechange events.
I have check the userpreferencechange event and its fired but don't know how to handle this issue in this event.
The problem is most likely in one of these four:
OnSizeChanged() method
OnResize() method,
SizeChanged event handler, or
ReSize event handler.
They all get fired whenever your gui get's resized. I suspect that in one of these event handlers/methods you have some code that tries to do something fancy that either results in an exception, recursion or an infinite loop.
But, without you providing more detailed code, this is, of course, merely an educated guess.
I've got a form that uses KeyDown. The KeyDown event is long, occupying almost 30k lines, and that brings up a problem. The first time I press down a key when debugging, the form freezes for a minute or two until I think reads all the conditionals of my KeyDown event. Then it works perfect until you close that form and load it again.
Note: This only happens when KeyDown event, KeUp event works normally.
I would put the code but as I said its 30K of lines full of conditionals, so my question is, is there a way to make KeyDown event faster or not to freeze like that, something besides reducing the ammount of lines or conditionals?
This requires psychic debugging, this question you asked is most relevant.
You didn't actually subscribe the Form.KeyDown event. You subscribed another KeyDown event, provided by a library that uses a low-level keyboard hook. Underlying winapi call is SetWindowsHookEx(). So you can detect keystrokes while your form doesn't have the focus.
And yes, that misbehaves exactly like you describe. The operating system called the hook's callback function which triggered the KeyDown event. You set a breakpoint on it, now the callback cannot complete. Windows goes catatonic for a while, it cannot process the next keystroke until the callback is completed.
It doesn't wait forever, after several seconds it decides that your program is misbehaving and it unceremoniously destroys the hook. Pretty important of course. You are noticing this delay.
You are going to have to do this differently if you want to have a shot a debugging this monstrosity. You need to setup another machine and connect to it with the remote debugger. It is not a golden solution, you still get the hook destroyed, but at least you regain control on your own machine a lot quicker. Using a unit test that just emulates the callback event would be very, very wise.
If I have a form that has a timer to check for some stuff in its toolbar button and now I use this form as a child form insde another application, does the timer still run? any possible threading issue that might cause it to stop working?
The reason I am asking is that I have such a scenario and the toolbars are not updated if I open this app in another app, wanted to make see if the issue is coming from here and any possible fixes?
A System.Windows.Forms.Timer will raise its Tick event on the same thread it was created on, so if the parent application somehow blocks its main thread, the code in the Tick event will not get run until the thread clears, this might be the cause of the issue you are seeing, however, the rest of the UI should be unresponsive in that scenario as well.
A System.Timers.Timer will raise its Tick event on a seperate thread, however this will be of little use if your UI thread is being blocked anyways, since this would prevent you from updating the toolbar even if the code runs.
I need to be able to check if the mouse is within a certain area on the form continuously. I want to be able to do this without the use of a timer, though. How would I go about doing this?
I'm using C# btw.
Have you tried attaching a handler to the MouseMove event, and checking on each movement?
If the area is a screen control, you can use MouseEnter, MouseLeave, MouseHover and MouseMove events.
I think the mouse events suggested by others is the best solution, but as another alternative to timers, you could write a small function to check the mouse and then keep invoking it on your main window dispatcher with an "application idle" priority. This will continuously run your check without freezing the UI.
Again, hooking into the mousemove event is still a cleaner solution, IMO.
If hooking the MouseMove event triggers too often - or if you want to avoid hooking that event on every form, consider hooking the Application.Idle event instead.
This event fires every time the application is about to go idle - all pending messages (including repaints) have been processed and there's nothing left to do. In most WinForms applications, this happens several times a second, providing a good way to do "just in time" processing.
You need to define events over that area.
Use OnMouseEnter and OnMouseLeave together to decide if mouse is in this area or not !
OnMouseEnter until OnMouseLeave means that mouse is still in that area.
I want to show a BalloonTip in the Application.Idle event of my program, but for some reason the Application.Idle event only fires after I mouse over the NotifyIcon. What gives?
Are you sure that Application.Idle is not getting fired? Simple way would be to log into the file whenever code enters the event and see if this happening.
Also understand that this event may not be suitable for your needs - it happens when message pump becomes empty (typically no keyboard/mouse input) - so as such you would probably receive this event too frequently (see this SO thread to understand more). In this case, I suspect that windows is suppressing the balloon tip perhaps because it is being shown too frequently.
As such, you can code to show the tip only if it has not been shown say in last 2-3 seconds. You may want to look at different implementations of Idle detection to suit your requirements - have a look at:
http://ellisweb.net/2008/02/detecting-application-idle-state-in-windows-forms/
http://blog.opennetcf.com/ctacke/2009/05/19/DetectingApplicationIdle.aspx
http://www.codeproject.com/KB/miscctrl/Application_Idle.aspx