views:

195

answers:

1

I have a strange problem with a Windows Forms event. To be exact, it's a KryptonHeaderGroup's ButtonSpec Click event, but it also happens with a plain vanilla System.Windows.Forms.Button.

In the click event, the user interface is brought down (there's a label and a cancel button left), and then an expensive LINQ query is built from previous user input, compiled and then executed. There are Application.DoEvents() calls in the foreach which actually executes the query (it's LINQ to objects, so it's lazy). This enables the user to press cancel, and after the DoEvents, a cancel flag is tested and the foreach is cancelled, and some clean up happens. So far, so good.

However, when I press the Cancel button after the first few results come in (the label shows how many are already there), the whole Click event handler is restarted! After adding some traces, it seems that this happens before the previous handler returns. In other words, it happens in one of the DoEvents calls. The button is, of course, not pressed again. It does not happen if the button is disabled in the event handler. But since the button is not pressed, it should not fire its Click event again, should it?

I'm baffled. Obviously the workaround is to disable the button, but I'd like to know what may be the actual problem here. Can the event handler be restarted if DoEvents is called before the handler finishes? Is calling DoEvents not recommended / allowed in event handlers? But then, since everything is an event handler in an event-driven application, you could never call it :)

Additional hints that may be required to answer this question:

  • The LINQ query takes a long time initially before supplying first results, i.e. before the first DoEvents call is made.
  • The LINQ query runs in the GUI thread because it would not make sense to allow the user to access the rest application, because the access will interfere with the underlying API both the GUI and the LINQ query use.
  • I know I should load the LINQ query into a separate app domain and execute it there, to be able to unload it. But there will only be few different queries run by a typical user, and the resulting assembly is cached (for the same query string).
  • The problem no longer happens if I either have a break point enabled (sigh - Heisenberg, anyone?) or if I cancel later during the query.

I appreciate anything that would explain the behaviour, even if it's just speculation :)

+1  A: 

DoEvents will process GUI messages so it will allow any further clicks or messages to be processed. I would recommend you don't call it in an event handler and to be honest I'd avoid using it at all.

From MSDN: Calling this method can cause code to be re-entered if a message raises an event.

Long term:

If this is a long running query you want to look at running it on a background thread and disable the button. This is the general pattern for this type of activity.

Matt Breckon
The problem with DoEvents is that, in this case, it fires an event again that did only happen once. There was no second click on the button. I agree with the background thread thing in general, I did however not do it in this application since the underlying API that is used in the query and the application is not thread-safe, and it is accessed from the GUI thread anyway in the main part of the application. I think I'll still try it in a separate thread, if rather for the chance to cancel the query automatically when closing the main window.
OregonGhost
Ok thats not nice but you've got to do what you've got to do. Another though: Are you sure you haven't subscribed to the event twice? Otherwise what about the Krypton library how about using reflector on that to see what it is doing?
Matt Breckon
As I said, this happens with a simple SWF button as well, and I definitely only subscribed once. If I repeatedly click on the Cancel button, it will repeatedly restart the event handler, yet they're all finished after it once went through (they're executed completely nested).
OregonGhost
Looking on MSDN there is a caution that code can be re-entered if a message raises an event. A comment on the bottom of the page also describes the issue you are seeing.
Matt Breckon
Thanks. With that additional information, your answer is the correct one (the "disable the button" bit, specifically).
OregonGhost