Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!spool.mu.edu!think.com!linus!agate!graft!scott
From: scott@graft.Berkeley.EDU (Scott Silvey)
Newsgroups: comp.windows.x
Subject: Re: WM_SAVE_YOURSELF (again)
Message-ID: <1991Feb1.194833.29532@agate.berkeley.edu>
Date: 1 Feb 91 19:48:33 GMT
References: <9101312333.AA06556@spurr.wr.usgs.gov>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Reply-To: scott@xcf.berkeley.edu
Organization: UC Berkeley Experimental Computing Facility
Lines: 34

gjw@spurr.wr.usgs.GOV (Gregory J. Woodhouse) writes:
|> Assume an application supports both the WM_DELETE and WM_SAVE_YOURSELF proto
|> cols.  Under what normal circumstances will mwm send a save yourself request
|> to the application?

Well, I can tell you this:  When the user does something to invoke mwm's f.kill
  function, f.kill first looks for WM_DELETE.  If it doesn't find it, it looks
  for WM_SAVE_YOURSELF.  If it doesn't find this, it just blows the client 
  away without warning.

"Quick, Massive, and Decisive."


|> Ultimately, I want process A to be able to kill process B and restart it
|> at a later time, but in the state in which it exited.  What I can do is have
|> it write a command on the root window (to what I call _XP_COMMAND), but I'd
|> think this all ought to involve the save yourself protocol somehow.

Try to avoid using the root window as much as possible, since every time you
  tweak something, you will wake up a myriad of sleeping processes that are
  waiting for new and unusual things to happen there...

Use clientMessage events or, if you must, WM_DELETE.  According to ICCCM, 
  a client can't avoid being shut down by a WM_SAVE_YOURSELF message.  However,
  WM_DELETE can be overridden by the client and there is no nasty timeout
  in case you have a lot to do to save your state.


/-----------------------------------------------------------------------------\
| Scott Silvey           | DOD Spokesman Pete Williams on Cruise Missiles:    |
| scott@xcf.berkeley.edu |   "We just don't discuss that capability.  I can't |
|                        | tell you why we don't discuss it because then I'd  |
| Flames to /dev/null    | be discussing it."                                 |
\-----------------------------------------------------------------------------/