chewy@apple.com (Paul Snively) (04/10/90)
In article <3047@dciem.dciem.dnd.ca> juana@dciem.dciem.dnd.ca (Juana Chang) writes: > After a dialog has been displayed over my windows, chunks of my windows > have been erased by the dialog. Which functions should I use to re-draw my > windows ? > > Should I use: > > BeginUpdate( ptr_mywindow ); > re-draw window... > EndUpdate( ptr_mywindow ); > > ????? Yes. > Thanks for your help/advice in advance. You're welcome! __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. 1st Choice: Paul_Snively.DTS@gateway.qm.apple.com 2nd Choice: CHEWBACCA@applelink.apple.com Last Choice: chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
oster@well.sf.ca.us (David Phillip Oster) (04/11/90)
In article <7617@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: _>In article <3047@dciem.dciem.dnd.ca> juana@dciem.dciem.dnd.ca (Juana _>Chang) writes: _>> After a dialog has been displayed over my windows, chunks of my windows _>> have been erased by the dialog. Which functions should I use to re-draw _>my _>> windows ? _>> _>> Should I use: _>> GetPort(&savePort); SetPort((WindowPtr) event->messaege); _>> BeginUpdate( ptr_mywindow ); _>> re-draw window... _>> EndUpdate( ptr_mywindow ); SetPort(savePort); _>> _>> ????? _> _>Yes. _> That is not quite fair. A better answer would be that you should have code like that in your update event handler, and that if you are not calling your main event handler because you are stuck in some modal dialog, you should pass ModalDialog() or Alert a pointer to a filer function that checks the event->what field of its event argument. If it is an update event and the destination (event-.message) is not the FrontWindow(), then hand it to your main even yhandfler to dispatch to the appropriate window. -- -- David Phillip Oster - Note new address. Old one has gone Bye Bye. -- oster@well.sf.ca.us = {backbone}!well!oster
chewy@apple.com (Paul Snively) (04/12/90)
In article <17179@well.sf.ca.us> oster@well.sf.ca.us (David Phillip Oster) writes: > In article <7617@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: > >In article <3047@dciem.dciem.dnd.ca> juana@dciem.dciem.dnd.ca (Juana > >Chang) writes: > >> After a dialog has been displayed over my windows, chunks of my windows > >> have been erased by the dialog. Which functions should I use to re-draw > >my > >> windows ? > >> > >> Should I use: > >> > GetPort(&savePort); > SetPort((WindowPtr) event->messaege); > >> BeginUpdate( ptr_mywindow ); > >> re-draw window... > >> EndUpdate( ptr_mywindow ); > SetPort(savePort); > >> > >> ????? > > > >Yes. > > > That is not quite fair. A better answer would be that you should have code like > that in your update event handler, and that if you are not calling your > main event handler because you are stuck in some modal dialog, you should > pass ModalDialog() or Alert a pointer to a filer function that checks the > event->what field of its event argument. If it is an update event and the > destination (event-.message) is not the FrontWindow(), then hand it to your > main even yhandfler to dispatch to the appropriate window. > -- > -- David Phillip Oster - Note new address. Old one has gone Bye Bye. > -- oster@well.sf.ca.us = {backbone}!well!oster Oops. You're unquestionably right. I was (most likely erroneously) reading the post to mean "how do I update the blotched windows after the dialog has been dismissed," as opposed to "how can I avoid ugly un-updated regions in cases where I don't update between having occlusions that aren't completely subsumed by successive occlusions?" (Sorry for the contorted English!) In other words, I imagine that I misinterpreted the question. Given the second interpretation of the question, your answer is indeed the correct approach. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. 1st Choice: Paul_Snively.DTS@gateway.qm.apple.com 2nd Choice: CHEWBACCA@applelink.apple.com Last Choice: chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________