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.
Related
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.
I am new to Winforms development and I do not see a solution yet on Stackoverflow, but may have missed it.
I have a dialog box that comes up, but due to application startup processing, it is only half displayed for the first 2 seconds or so (i.e. shows border and the background except where controls will be shown). The control locations are white until controls are displayed after that initial 2 seconds.
I understand I could put a delay in the application while it is starting up, but would prefer something like a Suspend() / Resume() pair in strategic locations. I have tried putting in the load event, but that had no effect. Also, it looks like Refresh() breaks the Suspend/Resume. Ideas appreciated since I would like to use this strategy elsewhere in the application as well. I am wondering what is an approach that will work for this and other areas that flicker badly (or outright show a long delay before fully displaying like this startup dialog box as described).
Try putting your long-running code in the Load event handler instead. By putting it in the Shown event handler, it causes the form to freeze until it's done loading because the shown event handler is not letting other events in the message loop, e.g. the Paint event -- get processed. At least if you put it in the Load event, all the long running code will occur before anything gets displayed at all.
If you don't like having any delay, consider putting the long running code in a timer that kicks off in the Shown event.
Then there's always the BackgroundWorker if you want to get more advanced with long-running code.
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.
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