.NET CF / Windows CE Threading

Lately, I was baffled by a problem in my current Windows CE/ Windows Mobile project. The scenario is quite simple:

• I have a Keydown event on my form.
• On the keydown event handler, I need to do some task which just takes around 500msec to complete.
• On that keydown event handler, I placed a C# lock construct to block the incoming keypresses (and with some Application.Doevents to pump the message queue).
• Then I did some destructive testing. The outcome: If I press a lot of key within the 500msec, the application throws an StackOverflowException.
• Next, I used the Monitor.TryEnter/Monitor.Exit so no blocking will occur. I did the same test. The result: StackOverflowException.

It seems to me that the code is being executed again despite it is inside a lock construct. Normally, what I will do on a PC-based .NET application is to set the control's Enabled property to False, then issue an Application.DoEvents before enabling the property again. Doing this in .NET Compact Framework with a device that is not as fast a PC,  gives an undesirable aesthetic effect. Our device's screen painting is quite slow and doing this method grays out the entire form then back to normal again.

Going back to topic and to illustrate my point:

• I created a sample Windows Form Application. Source code
• There is a keydown event. This must display an incrementing number, have a delay of 750msec, increment the counter, then exit the handler.
• The expected behavior is to display incrementing number each time a key is pressed.

I did an experiment using lock (See the function LockingUsingDotNetLock on the source code). If I press keys within 750msec, the textbox will display the same numbers! It must be incrementing! What happened? I would like to admit that I missed a crucial information regarding C# lock. Just yesterday, I researched more about it (Google, MSDN, StackOverflow.com) and found out that C# lock is re-entrant. It will block access to other threads but it can be acquired again and again by the same thread (Re-entrant Mutex).

Now I know the problem. What will be the solution? Here are the solutions that I could think of as of the moment:

• Using ordinary volatile variable for the locking (See the function LockingUsingVolatileVariable on the source code). It is a very simple solution. If I press keys, only one key will register and the incrementing number will display correctly. Most of the time, this is the behavior that we need.
• Using lock, but this time, we spawn another thread inside the handler (See the function LockingUsingDotNetLockOnAnotherThread on the source code). If I press keys, the key's will queue up, and will display incrementing numbers with respect to the 750msec delay in the code.
• Using Monitor.TryEnter and spawn another thread inside the handler (See the function LockingUsingTryMonitorOnAnotherThread on the source code). This will have the same behavior with Solution #1.

Chain Of Responsibility Design Pattern (Minus the repeated codes)

Last week, I studied Chain Of Responsibility Design Pattern. It was a good design pattern, but from the sample codes that I had seen, one common thing is that there are lots of duplicated codes. I would like to improve these and here are my main goals:
- As much as possible, eliminate or minimize the repeated codes.
- The concrete classes must not worry about the successor as much as possible and must not contain if else statements to call the successor's methods in case the caller can not perform the operation.
- If the additional logic statements for handling of next successor will be removed from the concrete classes, it will be easier to reuse those concrete classes.

I uploaded the code on my github. Link