How does VO do MDI?

[robert.pope]

I'm curious how VO handles having multiple modeless dialogs open at the same time.

The classic advice seems to be that the VO garbage collector is not thread safe. So I'll assume that it isn't multi threaded. If this is the case, I'm just wondering how VO pulls off multiple windows running concurrently. Is there some AppExec magic going on behind the scenes? How does one non-thread block on some code while another executes?

Or is the VO window manager written in C++ or something, and not subject to the same limitations that VO is?

Cheers.

[wriedmann]

Hi Robert,
VO uses the Windows message based approach, and since VO 2.0 the GUI classes are written completely in VO (apart from some CA C++ DLLs where the names start with CATO3x.dll).
If you have longer processes going, and you don't release processor time to other processes (and the GUI itself) with AppExec( EXECWHILEEVENT ) your application seems to be blocked and is not reponsive anymore.
Wolfgang

[robert.pope]

Hi,

So if I have a VO program with two modeless windows and if on one window I Sleep(1000000) (i.e. put it into a blocked state for a long time), I assume the code on the other window continues to run fine. Is it using some kind of time slicing within the VO runtime to make that happen? Does VO have some kind of scheduler that lets different windows execute their code on the main thread?

[wriedmann]

Hi Robert,
no, absolutely not. If you have two different MDI (i.e. modeless) windows, and are doing some longer calculations without freeing processor time using ApplicationExec( EXECWHILEEVENT ) in one window, the one remains blocked because it does not receive any processor time.
The same is true in the case you are doing some longer processing in one window and are trying to write some progress info to the window: it is displayed only if you release some processing time for this.
Wolfgang

[leon-ts]

Hello Robert,
As Wolfgang correctly explained to you, modeless windows in the UI are not provided by threads, but by transferring control from the central message dispatcher to the target windows. That is, the dispatcher in a loop selects messages from the general queue and calls the window procedure of the corresponding window for each of them. When the window procedure has processed the message, it returns control to the central dispatcher. Thus, user interaction with a window generates window messages corresponding to this action, which are sent to the general message queue. When control of the command flow passes to the central dispatcher and it gets to these messages in the general order, it will call the window procedure of this window and only at that moment this window will be able to process this message (react to it with some action, if any).

The fact that the entire UI runs on one main thread is the traditional approach. Therefore, you can often see recommendations to move long-running operations to separate threads so that they do not suspend the main UI thread (outwardly manifested as a hang of the graphical interface).

[leon-ts]

When control of the command flow passes to the central dispatcher...

You can force this moment when you need to by calling the operation that Wolfgang mentioned:

Code: Select all

App:Exec(EXECWHILEEVENT)

For example, in order for the central dispatcher to process the current messages accumulated in the queue, including WM_PAINT and the like, and transfer them to the corresponding windows for redrawing.

[robert.pope]

Thank you both for answering. That does make sense.

Is the same true for windows shown via non-VO DLL code? Assuming they don't go out of their way to create new threads. For example, in the past I've fixed a bug where some VO code was calling a 3rd party window, and then the VO code went into a sleep() while waiting for the 3rd party window to complete. From memory it was something like a Sleep(1000) then an AppExec. This starved the 3rd party window of CPU time. To fix that I had to implement proper event based programming in the VO code (i.e. events were going through the dispatcher again).

[leon-ts]

Robert,
In VO, this part of the work is implemented as expected for a desktop Win32 application. That is, it is not something invented by VO. It would also be written in C and other languages that don't hide this layer of direct interaction with Win32 functions and windows.Therefore, this is also true for Win32 windows created in a third party DLL that you load into your process.