| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.