🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.atari.st
Article #40246

GEM windows programming problem

#40246
From: Joe Gilray
Date: Thu, 11 Jan 1990 01:13
50 lines
2532 bytes
Here is a GEM programming problem:

I've written a multiwindow GEM application, everything was fine until I
added a "feature" that allows users to edit window data in a dialog box.
The dialog box editing function allows the user to edit data that may
appear in several windows that are currently open on the screen.

Here's the difficulty, when the dialog box closes, the window(s) receive
a WM_REDRAW message which is fine, but data may have changed in an area
of a window (or two, or three) that is not covered by the dialog box and
therefore does not appear on the redraw rectangle list.  When the uncovered
part of the window(s) is redrawn the window data looks wrong because the
part of the window that was not covered is old.

Solutions and commentary:

1) When traversing the rectangle list set the clipping area to the
   whole window instead of the just the covered part, then draw the
   entire window's data.

   results: YECH.  This doesn't work because the windows are drawn in
            somewhat random order (any ideas here?) and windows that are
            beneath other, already drawn windows may pop through them
            when drawn.

2) When the window(s) are "dirtied" (that is their data is changed), use
   appl_write() to send a redraw message for the entire desktop.

   comments: I haven't tried this yet, but it seems pretty good.  The
             questions that come to mind are:

             a) will this new WM_REDRAW message get merged with the
                one from the dialog box closure?  I know that redraw
                messages will get merged, I have used this before when
                I wanted to force a redraw whenever windows were sized
                (normally window sizing only causes a redraw event if
                one of the window's dimensions is increased).

             b) Will this look bad even if the redraws are merged?
                I'll have to try this and see.

3) Variation on (2) above, send multiple redraw messages, one for each
   dirtied window. 

   Will these messages all get merged?


Anyway, any ideas and comments are appreciated!
-Joe Gilray
Technical Details
Message-ID: <11830069@hpldola.HP.COM>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!hplabs!hpfcso!hpldola!jg

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!hplabs!hpfcso!hpldola!jg
From: jg@hpldola.HP.COM (Joe Gilray)
Newsgroups: comp.sys.atari.st
Subject: GEM windows programming problem
Message-ID: <11830069@hpldola.HP.COM>
Date: 11 Jan 90 01:13:36 GMT
Organization: HP Elec. Design Div. -ColoSpgs
Lines: 50