On Tuesday, 8 December 1998,
     HERBERT ROSENAU wrote to IVAN TODOROSKI about the PM message queue

 IT>>      When I dragged windows around, the beeping simply stoped!

 HR> This depends on your hardware. Dragging of a full sized window is
 HR> a resource (cpu) consuming operation in high priority. Even the
 HR> kernel - and drivers runs multithreaded and with different
 HR> priority.

  It turned out that it DID have higher priority than default, and the
  source of that higher priority was the Window Boost that the scheduler
  was applying to the window procedure of the window being dragged.

  Removing the Window Boost from the kernel priority table fixed it. Now
  apps don't freeze in the background when I drag windows, they just
  slow down (expected behaviour).

 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.

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

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

  What bothers me now is this:

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

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

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

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

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

  Thanks for all your help, it is much appreciated!

                                                            - Ivan -

.!. Please return stewardess to original upright position.
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ