Do you have any ideas how to call DoEvents from a C# DLL
+14
A:
Don't. It's sketchy enough when you are the app controlling the event loop; pumping messages from a DLL just adds to the risk that you'll end up hitting code a naive programmer didn't make safe for re-entrancy.
Shog9
2008-11-11 18:18:15
I utterly concur.
Vincent McNabb
2008-11-12 08:19:58
I agree that DoEvents is not to be used. But what if the DoEvents that cause problems comes from a 3rd party DLL for which you do not have the source? I've had a redraw problem nightmare in my application and I suspect its because the control calls DoEvents and my main application loops ends up being surrogate to that control, so whenever the control is not shown, my entire application stops redrawing properly.
Anthony Brien
2009-05-21 01:42:21
@Anthony, that's exactly why you shouldn't use it in a DLL, *especially* not a DLL that you'll be giving, sans source, to someone else. Unfortunately, unless you can ditch the library entirely, you're probably stuck trying to figure out how to write your app around the selfish behavior of this 3rd-party DLL... you have my sympathy!
Shog9
2009-05-21 02:02:15
I agree. Like any tool, there are times when it is a good idea and times when it's a bad idea. That's up to the developer to decide, though, isn't it?
configurator
2008-11-12 12:06:38
@configurator: if the developer owns the message-processing code for the thread, then yes. If the developer is writing a DLL loaded and called by a thread he doesn't own, then no.
Shog9
2008-11-12 14:33:16
A:
Write a interface for the EXE and have your main form or main class implement it. Then register that object implementing the interface with the DLL. Assign it to a variable of the that interface type Make a Subroutine that is visible throughout the DLL. In the Subroutine check to see if the variable is nothing if isn't then the subroutine that fires method you created to fire DoEvents. Anytime you need to do a DoEvents then call the Subroutine.
If you are using a three tier organization for your application put the subroutine or variable on the object representing your entire application. Have the form register itself with the Application object.
If you have re-entrancy problems you can add status variable and other helper functions to safely check what the application is doing. Note that is far far easier to implements this if you are using some type of multi-tier design.
To other looking at this re-entrancy is a problem however so is a non-responsive UI. In a complex application there are circumstances where you have to let the event loop fire.
RS Conley
2008-11-11 19:57:01
+2
A:
I'd echo the "don't" (either from a dll or a UI project). There are several things you can do to make library code play nicely with a UI,including the same threading tricks (with events and/or callbacks) that you might use from the UI. The simplest approach is for the library code to simply execute "as is", and if the UI happens to spawn it on a worker thread, then it is the UI's job to handle any events and marshal them (Control.Invoke/BeginInvoke) to the UI thread for UI updates.
For more complex scenarios, you can use the sync-context (SynchronizationContext.Current) to post messages to the UI thread (this is actually how Control.Invoke etc work, but it is implementation independent - so a WPF sync-context can go through the WPF dispatcher).
Can you add more context on what the scenario is? There are many things that can be done...
Marc Gravell
2008-11-12 06:59:07