DDT and multithreading

[Chris Holbrook]

While writing one of my first multithreading applications, I found that updating some DDT controls did not seem to work. Then I read Mr Mattias's comments in one of his excellent examples (read more in the thread over here)

' I had to use a string ptr here instead of CONTROL GET TEXT because the calling thread was in a wait
' state (WaitForSingleObject) and apparently (undocumented but not reasonably) CONTROL GET TEXT does
' "something" which must execute in the context of the same thread (suspended) as the dialog.
' Apparently (that means also not documented), DIALOG GET USER does not need to execute anything in the
' context of the thread in which the dialog was created.

And I wondered: What DDT statements should I not use, or use differently, or use after precautions, in a seperate thread? And if there are any such DDT statements, what are the limiting circumstances, and why?

Has anyone else had similar experiences? Or am I getting worked up about nothing?

[Michael Mattias]

As I pointed out in other thread, I think you *ARE* getting worked up about nothing.

My comment above has actually NOTHING to do with 'multithreaded' programs. What I say there is, "However PowerBASIC Inc. implements the proprietary DDT 'CONTROL GET TEXT' statement, it requires the thread in which the target window (dialog) not be suspended; this requirement is not documented under CONTROL GET TEXT."

Multi-threaded programs themselves are not the problem; the problem I encountered was, I was unable to use CONTROL GET TEXT when I had *deliberately* suspended the thread in which the target dialog executes.

So what I did to get around that problem was, "Don't use CONTROL GET TEXT when the thread of the target dialog is in a wait state."

(FWIW, you get a deadlock if you do this... but this problem is easily solved with Task Manager: End process).

MCM

[Chris Holbrook]

As I pointed out in other thread, I think you *ARE* getting worked up about nothing.

You are right, I was confusing "SUSPENDED" as in "THREAD SUSPEND" with "not being executed when the message is sent", which is not always the same thing.

[Michael Mattias]

THREAD SUSPEND will get the same result as will WaitForSingleObject: that thread ain't executing any code until THREAD RESUME or the wait is satisfied! (THREAD RESUME is NOT a 'substitute' for satisying a "WaitFor...." . When "WaitFor..." is called, that thread is active... but it is going to do nothing until the WaitForxxxx returns).

But there is no reason to use THREAD SUSPEND in the demo program.

The only time I use SUSPEND is on the THREAD CREATE statement.. so I can set the priority using THREAD SET PRIORITY (oops, that don't exist so I use SetThreadPriority()) before ANY code of the thread function executes.

However, I actually do this quite often... I set the priority of "worker" threads DOWN so my GUI remains responsive to other requests.

MCM