-1

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?

Joscplan
  • 1,024
  • 2
  • 15
  • 35
  • 9
    That completely depends on what your code is doing. However, a 30K-line method is _never_ a good idea. – SLaks Jun 29 '14 at 14:23
  • What is it that you are trying to do in your KeyDown event that takes 30,000 lines of code? –  Jun 29 '14 at 14:23
  • @SujaySarma Using different Keyboard layouts it reproduces a sound when you press a designed key. – Joscplan Jun 29 '14 at 14:25
  • 1
    @SLaks is absolutely right: the problem is your 30 kilo-lines of codes, not a KeyDown event per se. Fix your code. Rgds, – Alexander Bell Jun 29 '14 at 14:27
  • @JoseCardama: It sounds like you want a dictionary. – SLaks Jun 29 '14 at 14:28
  • a 30K line method? Is it the 70's again? – Mitch Wheat Jun 29 '14 at 14:30
  • Damn 30k :D what the hell are you doing in it? – RvdK Jun 29 '14 at 14:38
  • Is this some kind of joke? 30k for a "sound" - did you hard-encode the wav-information there? - BTW to make this faster bring down the code to the max-3-liner it is needed: https://stackoverflow.com/questions/4125698/how-to-play-wav-audio-file-from-resources – Random Dev Jun 29 '14 at 14:52
  • _did you hard-encode the wav-information there_ ROFL _The KeyDown event is long, occupying almost 30k lines, and that brings up a problem._ No. That doesn't _bring up_ a problem, it __is__ the problem. And no, processing thousands of conditions will not take a minute, nor will it only the first time, nor only when debugging. Are you doing I/O there? Loops? – TaW Jun 29 '14 at 14:59
  • 1
    Can you upload this method somewhere? For researchpurposes? – CSharpie Jun 29 '14 at 15:39
  • "research" like ROFLcopterism? – Random Dev Jun 29 '14 at 15:39
  • I've seen it. People don't know database. So they extract *every single row in the table* (using find & replace I guess) to find a match. And it was code used in production. Honest. – kevin Jun 29 '14 at 15:54

1 Answers1

2

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.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536