🚀 go-pugleaf

In article <1097@venice.SEDD.TRW.COM> press@venice.sedd.trw.com (Barry Press) writes:
>In article <1991May16.190243.27809@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes:
>> ...
>>begin
>>  if Getmessage(msg,0,0,0) then
>>  begin
>>    Translatemessage(msg);
>>    Dispatchmessage(msg);
>>  end;
>>end;
>>
>>As long as I call this frequently enough, things are fine.  (I have a 
>
>Unless I misunderstand what you've done, you're processing any and all
>messages here.
>
>What this implies is that you've got this loop that runs, effectively, as
>a background process WHILE ALL FUNCTIONS OF YOUR PROGRAM ARE OPERATIONAL
>AND ACCESSIBLE TO USERS -- i.e., you can (recursively) call any function
>within your software.
>
>Did you really intend that?  What you desribed led me to believe that
>you just wanted to let other Windows programs (not yours) run while
>you finished this loop.  I concluded that your program itself was "busy"
>during that time.  If that's really what you wanted, then you'd best not
>allow any message at all, just the ones related to focus.

First of all, further testing showed that I really needed a Peekmessage
loop, not a single Getmessage call.  The current version of my Yield function
has first line

 while Peekmessage(msg,0,0,0,pm_remove) do

and works better than the above.  (I'm new at Windows programming.  Or could
you tell that already? :-).  That one happened to work because I
always had a paint message waiting.

As to whether it does what I want or not:  I'll have to give more background.  

As a first project in TPW, I decided to port a little DOS program I've got that
just does a scatterplot of data read from a file.  It was written in TP, and
used the BGI graphics there.  Since TPW doesn't come with anything remotely
resembling the BGI Graph unit that my program used, and it was written using
a toolkit that relied on BGI, I decided to get ambitious and write a Graph
unit replacement.  Ideally it would just be a drop in replacement to let
DOS graphics programs run under Windows and produce nicer output that could
be resized, moved, etc.

The way BGI graphics works is quite a bit different from Windows GDI.  For one
thing, it expects to own the output device exclusively, and to be able to 
paint an image a little bit at a time.  Since the programs that call it also
think they're single-tasking, they'll never voluntarily give up time slices:
hence the need for some sort of Yield function, which I decided to put
in the graphics output routines, hoping that they'd be called often enough
for it to work.  (The scatterplot application satisfies this:  it does almost
nothing but build the image.)

Since the programs that are going to be using this are warmed over DOS 
programs rather than Windows programs, they don't really need to know anything
about events coming in, other than the command to close the window, which
halts the program.  Thus it's fine to process any and all messages that come
along:  in fact it's necessary to process more than just messages about
the focus, because I want the output window to be resizable.

One outstanding problem:  I'd love to use a metafile to save the graphics 
commands (right now I'm maintaining my own list of them, and running into
trouble when there are too many of them).  The problem is that it doesn't
seem possible to write some stuff to a metafile, play it to the screen,
and reopen it to write some more.  Am I missing something?

Duncan Murdoch
dmurdoch@watstat.waterloo.edu