DoEvents In DLL
I would choose "do not" (either from a DLL or from a UI project). There are several things you can do to make the library code well-compatible with the user interface, including the same subtle tricks (with events and / or callbacks) you can use from the user interface. The simplest approach is that the library code just executes "as is" and if the UI comes up to spawn on a worker thread, 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 sync-context ( SynchronizationContext.Current
) to post messages to the UI thread (it actually works like Control.Invoke
and so on, but it's implementation independent - so a synchronized WPF context can go through the WPF dispatcher).
Can you add more context about what a script is? There are many things to do ...
source to share
Write an interface for EXE and specify its main form or main class. Then, register this object that implements the interface with the DLL. Assign it to an interface type variable Make a subroutine that is visible throughout the DLL. In subroutine validation check if the variable is nothing, if it is not then a subroutine that runs the method you created to run DoEvents. Anytime you need to do DoEvents, call the subroutine.
If you are using a three-tier organization for your application, place a subroutine or variable on an object that represents your entire application. Register a form with an Application object.
If you have trouble reconnecting, you can add a status variable and other helper functions to safely check what the application is doing. Note that it is much easier to implement this if you are using some type of layered design.
Another looking at this re-emergence is the problem, but similarly unresponsive user interface. In a complex application, there are circumstances in which you must skip the event loop.
source to share