Some senseless babbling from Ivan Todoroski to Herbert Rosenau
on 21 Dec 98  14:44:00 about the PM message queue...

[snip]
 HR> Since OS/2 1.1 exists a rule for PM programmers: a message is to
 HR> handle in 1/10s. If this is impossible the handing is to shift to
 HR> another thread. This rule should free the system message queue in
 HR> short time. An other way to become the system queue unlocked is
 HR> POSTING a WM_USER to the same window - but NOT for truly time
 HR> consuming messages! You my create other threads and post them the
 HR> messages received from system queue.

 IT> I was also meaning to ask about how to deal with long operations and
 IT> STILL return quicky from the window procedure. Posting a WM_USER
 IT> message back to the same window seems like an excellent idea! It
 IT> seems so obvious when someone points it out for you... :(

 IT> But I don't understand why wouldn't this approach be desirable for
 IT> long time consuming tasks? Please explain.

Because your app's main thread would still be occupied with that task when 
new messages come in.  The queue would be clear for other apps to operate, 
but yours would be unresponsive, and make others unresponsive as soon as it 
has a new message to handle, but isn't free to post it back to itself 
again.

The best alternative is to have the main thread do absolutely nothing but 
relay messages from the system to worker threads.  This avoids the problem 
of having it do small tasks, only to find later on that those small tasks 
have grown, and it's not all that easy to get them onto another thread.

 IT> What bothers me now is this:

 IT> Let's say I have a complex graphics application, and it takes a very
 IT> long time to repaint the window. So what should I do when I get a
 IT> repaint message?

 IT> 1) Do all the redrawing in the WndProc, leaving the PM frozen for the
 IT> duration of the drawing (very ugly)

 IT> 2) Delegate the drawing task to another thread and return from the
 IT> WndProc immediately.

 IT> Naturaly, the second alternative is more desirable, since the PM will
 IT> continue to run and process messages. But what to do with other
 IT> messages that may arive during this redrawing period (user clicks on
 IT> the window etc.)? Is it safe to just ignore them and start receiving
 IT> messages again only after the drawing ended?

That's what I'd personally do.  If the thing is still redrawing, then input 
messages can't be terribly meaningful.  While you may want to assume that 
the user knows where the buttons and whatnot will appear, that can turn 
ugly when they're wrong.

I suppose such a thing should be handled with a semaphore from the drawing 
procedure that lets the main thread know when to start sending messages 
again; before which all input messages are dumped (obviously, close, 
shutdown, etc. messages should be heeded).

 IT> What if another window comes to the foreground and covers your
 IT> window while your'e still drawing? How would you go about coding
 IT> around this and still not hog the system message queue?

 IT> Thanks for all your help, it is much appreciated!

I'm not sure what happens then.  I would have to assume that PM is smart 
enough to handle that situation.  Since you're dealing with a PM 
presentation space, not actually the screen (this is obviously more 
complicated with DIVE), what you draw should not overwrite the intruding 
window, which presumably would have a presentation space that overwrites 
the portions of yours, regardless of what you're doing with them.

But I'm speculating.

Mike Ruskai
thanny{at}home.com


... After seeing Windows I realized Bill Gates is an idiot.
--- Renegade v05-11 Exp