Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!nosc!ucsd!orion.cf.uci.edu!uci-ics!venera.isi.edu!dick
From: dick@venera.isi.edu (Richard Gillmann)
Newsgroups: comp.windows.ms
Subject: Re: Yield?
Keywords: WM_TIMER
Message-ID: <7246@venera.isi.edu>
Date: 12 Jan 89 20:38:57 GMT
References: <33575@grapevine.uucp> <106580014@hpcvlx.HP.COM>
Reply-To: dick@venera.isi.edu.UUCP (Richard Gillmann)
Organization: Information Sciences Institute, Univ. of So. California
Lines: 18

In article <106580014@hpcvlx.HP.COM> bturner@hpcvlx.HP.COM (Bill Turner) writes:
>> One alternative is to break your painting into a number of smaller tasks
>> and do them in response to WM_TIMER messages, with the timer set up by
>> WM_PAINT.  In this way, other messages can be processed between the
>> timer messages.
>
>The only problem with this is that your application will still control the
>CPU, starving all other tasks.  Task switching isn't done unless the 
>messgae queue is empty.

Not true!  The WM_TIMER method does work.  I have used it for several
programs.  Other tasks are not starved, because the queue is empty between
timer messages.  Of course, you must set the timer interval to a sufficiently
large value, so that there are periods between timer messages when the queue
is empty.

But I do agree that a real pre-emptive multitasking system is much nicer.
All this falls out automatically in PM.