We Keep Coding

C# window application GUI halt on re-sizing

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.

Make a Form's KeyDown faster

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.

Control not fires DoubleClick event because of code behind another event

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.

How To Keep Checking For Something Without a Timer?

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.

Detecting mousewheel over non-focused window?

My goal is to make a floating toolbar (as its own C# application), and when the user uses the scrollwheel over me I want to change the buttons that are visible. Sounds easy enough, should just be a matter of this one-liner:
MouseWheel += new MouseEventHandler(Form1_MouseWheel);
The problem I am having is that the mouse wheel handler is only invoked when my application has focus. That means the user has to first click, and then mousewheel. That won't do for what I'm trying to do.
I can hook the MouseHover event handler and call form.Activate() then, to get focus. That's suboptimal because if the user uses the scrollwheel immediately after mousing over my application (instead of waiting a little), the focus will still be on the previous app and it'll get the mousewheel event.
A natural thing to do would be to hook the MouseEnter event and call Activate() there, but then instead of my application coming to the front, its icon starts to blink on the task bar. I'm using Win7, but this problem is probably older than this.
Ideally, what I'd like to do would be to detect the mousewheel events without having to worry about whether my application has focus. It would really be better for the previous application to keep input focus, so for example if the user's in Notepad they can type, mouse over to my app, use the scroll wheel, look at what they see and decide to just resume typing in Notepad. Ideally I don't want them to have to click even once in this scenario.
I'll settle for a solution that switches focus to my application, though, if there's no other way.
What I have so far uses C# and Windows Forms, but I'd be open to using something different if that can solve my problems.
So: how can I see those mousewheel events without the user having to click to focus my application first?

If you need to catch mouse events outside your application, you can use a global system hook. There's a good .NET implementation here