I have known for a long time that you can register an nvo as a shared object and have it run in a separate thread, but never really never paid it much attention.
In my mind a shared object was meant for background processes, so the user didn’t have to wait, whilst long winded retrievals or other processing took place. But what if the process was not a database process that blocks the main thread. What if the process was mainly in the client in the main thread and it was acceptable for the user to wait as long as he or she could see the process progressing? Then all we do is setmicrohelp and set arrow to hourglass!. We might even create a little window with a progress bar and post progress to it… Trouble is; when the showing progress is competing with the real process; as soon as the user clicks anywhere to see what is happening, the whole thing goes pale and the progress window stops showing progress.
After a bit of experimenting I discovered that you can actually open a window from a shared object. This window, happily opens and is running in a different thread, is responsive and a perfect candidate for a progress window.
To open a progress window in a different thread, create and nvo with a couple of functions to set progress and messages, instantiate it using SharedObjectRegister and code it to open the progress window when it is call upon to show progress…
Example: w_main with invShared as instance variable instantiated in the Open event.
Pretend process with calls to the progress window via invShared:
note that the invShared instance variable ibCancel can be interrogated between steps.