Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!uwm.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!parc.xerox.com!janssen From: janssen@parc.xerox.com (Bill Janssen) Newsgroups: comp.soft-sys.andrew Subject: Re: view_FullUpdate(view, view_Remove, ...) Message-ID: Date: 31 May 90 23:19:40 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 23 Excerpts from ext.andrew: 31-May-90 Re: view_FullUpdate(view, v.. Zalman Stern@andrew.cmu. (1273) > FullUpdate should only be called by im, another FullUpdate routine, or an > Update routine (after the visual area has been cleared). This is necessary > since FullUpdate requires that there be a valid graphical context > available. Synchronizing update routines to the interaction loop guarantees > that the graphic and window system state will be valid. As you note, FullUpdate with view_Remove is really for a different purpose than FullUpdate. Perhaps a valid graphical context is only guaranteed if the type of FullUpdate is view_FullRedraw? > Therefore, a better solution to Bill's problem would be to fix frame to > generate a view_Remove FullUpdate on the old view when the view is being > switched. It is perhaps plausible that this could be piggy backed on the > LinkTree/UnlinkTree protocol, but I'm not sure that it would work in all > cases. Sounds good to me. The protocol problem isn't fixed by this, but it would solve my problem. Bill