PB app frozen whilst COM executes

[Simon Morgan]

Enough excitement (for the moment) on object capabilities in the next release: here’s a technical question to start off this new forum regarding current PB/Win COM features.

Whilst executing a call to COM method, my PB app is frozen. The message loop is totally suspended and it doesn’t even repaint the screen. This isn’t too much of a problem for most COM calls that execute reasonably quickly, but if I call something that waits for user input, for example:

OBJECT CALL oExcelApp.GetSaveAsFilename(FileFilter=vFileMask,Title=vText) TO oVnt

the user might task switch back to my PB app (perhaps for inspiration on what name to use) and find a messy partially updated but mainly blank dialog.

Is there a recognised way to avoid this problem?

[John Petty]

The COM call needs to be made from a seperate thread to the main screen, no different to calling a DLL that requests input or a part of code that is intensive and takes time.
MCM has a similar example in the source code forum

[Simon Morgan]

Thanks John, but it's not quite the same as calling a DLL function that creates a dialog and waits for the user's response.

If I call the GETOPENFILENAME or MESSAGEBOX API (for example) without supplying a window handle, my app continues running and responding to messages, yet my code will resume at the point where the API was called when the user closes the dialog. This effectively creates a modeless dialog without needding a new thread.

I was hoping there was an easier way to emulate this behavior with COM than having to run a thread function and monitor when it's finished.

[Michael Mattias]

Thanks John, but it's not quite the same as calling a DLL function that creates a dialog and waits for the user's response.

Actually, Mr. Petty is dead-on correct here. If you make any blocking call (and any single PB verb is a blocking call), the current thread is suspended until that call completes.

If I call the GETOPENFILENAME or MESSAGEBOX API (for example) without supplying a window handle, my app continues running and responding to messages,

Immaterial, becase GetOpenFileName is not calling the PB runtime, so it is not blocking. It does a lot of other cool stuff to support this desireable behavior, but that is not important now.

The bottom line is, if you want one of your dialogs to respond to messages, its thread cannot be blocked by anything. That means pure and simple if any PB instrinsic (in this case a CALL) takes longer than you are prepared to wait for your screen to refresh, you must use a separate thread of execution (assuming you are compling with the PB compilers).

Fortunately, there is a nicely-commented demo in the source code forum for you on this very subject, incuding the "bonus" feature of how to abort the other 'activity' :

GUI + Worker Thread + Abort Demo 11-24-07

MCM

[Theo Gottwald]

Good comment Michael.
To make it short: If your process is blocked somewhere your GUI may not be refreshed ).

[Michael Mattias]

I forgot about MSGBOX, which does NOT block. My bad.

(Basically MSGBOX works the same as GetOpenFileName() or any other modal dialog).

(Yes, DIALOG DOEVENTS *does*block.. it does not return until the underlying PeekMessage() returns. But that's usually pretty quick so you never notice the blocking).