Drawing in Windows
4 messages in this thread
In a multi-window environment – Mac, Windows, Motif, etc. – there is a
very important technique which is not immediately obvious, not
emphasized in the documentation, but which makes all drawing work
much better.
You probably are writing directly into a window in response to a user
event. E.g. when your user clicks a button you create your graph
window, then draw directly into it.
The right technique is to draw into your windows only in response to
update events, not in response to user actions. You should maintain
data structures that describe the contents of your windows, then draw
(redraw) a window from these data structures whenever the windows
need to be redrawn (I.e. whenever the Mac delivers an update event).
You respond to user actions by updating your internal data structures,
then issuing InvalRect toolbox calls to tell the Mac that portions of
your window are out of date. The Mac creates an update event, to
which your application responds by drawing the contents of the
window. Later, as windows are covered and uncovered, the Mac will
issue more update events, and your program will redraw the window
contents.
You'll still do things like DrawString, MoveTo, etc. but you'll do
them from your UpdateMainWindow routine instead of in the various
parts of your code that respond to clicks, keystrokes, etc.
In the case of a dialog you'll usually put the drawing code into a
draw proc for a user item. The toolbox Dialog Manager will
automatically call the draw proc as needed (provided that you issue
the appropriate InvalRect calls to tell the Mac that parts of your
dialog need to be redrawn).
Could you elaborate on the benefits of why an app should send invalidate
messages immediately, and only draw when it gets the update events?
>>>
Could you elaborate on the benefits of why an app should send invalidate
messages immediately, and only draw when it gets the update events?
<<<
1) It keeps all the drawing in one place, because you _have_ to do the drawing
in response to an update event anyway.
2) It improves response to other events. During the time between first
invalidating the window and actually updating it, several other events might be
received. If any of these would also affect the appearance of the window in
question, only the cumulative effect need be drawn when the update event comes
around. Whereas drawing immediately would hold up the other events, and you
would have to draw each change instead of a cumulative change.
There are legitimate reasons for drawing immediately. For example, controls
and control-like entities have to be partially redrawn when the mouse is
pressed over them, and then redrawn again as the button is released or the
mouse is dragged in and out of the area. But if you are using real controls,
this redrawing is handled by TrackControl(), so you needn't worry about it.
Steve
John,
Your app has to be able to respond to update events and redraw its windows. So
you'll have to have a bunch of code that draws to the screen. If that code is
in one place, the update handler, your app will be much simpler than if you
have drawing code scattered all over your app.
Spec