TIP: Click on subject to list as thread! ANSI
echo: os2prog
to: MIKE RUSKAI
from: IVAN TODOROSKI
date: 1999-01-05 23:08:00
subject: the PM message queue

On Monday, 4 January 1999,
     MIKE RUSKAI wrote to IVAN TODOROSKI about the PM message 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.

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

  Once again, I managed to prove beyond any reasonable doubt my unique
  abillity to totally miss the obvious! :(

  Thanks for taking the time to explain.

 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!

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

 MR> But I'm speculating.

  If your speculations are true, and the PM takes care of this, then I
  must admit that the PM isn't all that bad after all! :)

  That SIQ "problem" can be worked around quite effectively, it's just a
  matter of dumping those ugly DOS/Win programming habits... this SIQ
  situation actually enforces cleaner program design and encourages
  multi-threading, which in turn results in more responsive
  applications.

  Win9x may deliver messages asynchronously, but the badly written apps
  themselves are stoned while processing them, so if you don't design
  the apps properly, you don't really gain anything by asynchronous
  message processing!


P.S. Talk about optimism... :)

                                                            - Ivan -

.!. If it works, rip it apart and find out why!
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ  
* Origin: GET ALL YOUR FIDO HERE! telnet://bbs.docsplace.org (1:3603/140)
SEEN-BY: 396/1 632/0 371 633/260 262 267 270 371 635/444 506 728 639/252
SEEN-BY: 670/218
@PATH: 3603/140 396/1 633/260 635/506 728 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.