Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!ucdavis!csusac!unify!Unify.com!grp
From: grp@Unify.com (Greg Pasquariello)
Newsgroups: comp.windows.x
Subject: Re: WM_SAVE_YOURSELF
Message-ID: <1991Jan28.103909@Unify.com>
Date: 28 Jan 91 18:39:09 GMT
References: <1991Jan22.064227.4656@agate.berkeley.edu> <100920280@hpcvlx.cv.hp.com> <1991Jan25.201354.17242@agate.berkeley.edu>
Sender: news@Unify.Com (news admin)
Reply-To: grp@Unify.com (Greg Pasquariello)
Organization: Unify Corporation, Sacramento, CA, USA
Lines: 44

In article <1991Jan25.201354.17242@agate.berkeley.edu>, scott@graft.Berkeley.EDU
(Scott Silvey) writes:


> When WM_SAVE_YOURSELF (and not WM_DELETE) is noted, the window manager sends
>   the WM_SAVE_YOURSELF message, unmaps the client's window, and then appears
to
>   wait for a client response.  If the client responds, the application quits
>   by some mysterious mechanism after the WM_SAVE_YOURSELF callback returns.
>   If the client does NOT respond, the client gets wasted anyway.
> 
> MY QUESTION IS: How do I prevent my application from getting blown away by
>   the WM_SAVE_YOURSELF mechanism?  Is this even possible according to ICCC?
>   (I thought it was, but perhaps I am reading ICCCM wrong?).
> 

After the session manager sends the WM_SAVE_YOURSELF, and the application
responds, the session manager should continue doing what it was doing - term-
inating the application in this case, because the use selected CLOSE.  In 
practice, most session managers don't wait forever for a response, so after
some time, they generally continue anyway.  So, if the user selected CLOSE,
there is no way via the ICCCM to prevent your window from being wiped out.

What happens when WM_DELETE _and_ WM_SAVE_YOURSELF are present?


> What I would like to do is prompt the user with a dialog box that says "Do
you
>   really want me to quit?" and if the user clicks "No", then I'd like to go
on
>   with life and not get killed (Or have my window unmapped for that matter!).
> 

Because you can't prevent the window from being destroyed, it doesn't make
sense to prompt the user, and in fact, this is prohibited by the ICCCM in 
5.2.1.  

> | Scott Silvey
> | scott@xcf.berkeley.edu 
--

---
Greg Pasquariello	
Unify Corporation 	grp@Unify.Com