CompuServe Thread

Drawing in Windows

4 messages in this thread
#163425From: Spec BowersMar 11, 1994 10:52 AM
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).
#163687From: SyndesisMar 13, 1994 1:12 PM
Could you elaborate on the benefits of why an app should send invalidate messages immediately, and only draw when it gets the update events?
#163735From: Steve StockmanMar 13, 1994 5:42 PM
>>> 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
#163763From: Spec BowersMar 13, 1994 9:02 PM
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