🚀 go-pugleaf

In article <127200007@inmet>, lipsett@inmet.UUCP writes:
> Either I am missing something obvious, or I have to call my deactivate
> routine explicitly before calling NoteAlert, or I am just trying to be
> too fancy with my refcon's, or...???

     The various Alerts (and ModalDialog, by the way) swallow all the events
that occur while the Alert window is brought up.  That's why you're missing
the deactivate events.  They call HiliteWindow (indirectly) themselves, and
your code for deactivation never gets called.
     For your code, just do a deactivate (really a fake deactivate, see below)
before you call an Alert.  Dialogs don't cause this problem because the
activate/deactivate events are generated by [Get]NewDialog and not by
ModalDialog.  There are exceptions to this, such as SFGetFile and SFPutFile.
Those guys handle their "own" events, so you need to do a fake deactivate
before calling them.
     You also run into this problem with desk accessories.  Some DAs may
choose to put up an Alert or a standard file dialog.  DAs cause other problems
as well; you can't do a real deactivate because a DA might not bring up a
window.  (It might just install a menu item, for instance.)  This is why I
said you should do a "fake" deactivate.

     I had this problem with a TextEdit-based application where I had globals
that pertained to the frontmost (i.e., active) window.  When I got a
deactivate, I stored them in a record pointed to by the refCon field in the
window record.  I couldn't call TEDeactivate for these fake deactivates since
a DA without a window would leave one of my windows in front that was Hilited,
but without an active TE record, so I didn't have an insertion point or
selection range.

     Depending on what you're doing, you might not have to do a so-called
"fake" deactivate.  I had to fake it because I didn't want to call
TEDeactivate unnecessarily.  You might be able to call your real deactivate
routine.  This leads to your next problem...
     One of the features of my TE application was that it didn't hurt to copy
those globals to the refCon record twice (once for a fake deactivate and once
for a real deactivate, in case I got a real one in the case of a DA.)  In your
case, you can only compress once, so you have to be careful about not
recompressing compressed data.  With your code, you know exactly when you
won't be getting the deactivates.  With DAs, you won't know and you can't find
out.  Either don't allow DAs (a travesty in some peoples' minds) or leave a
flag around telling you whether the data has been compressed or not.  I think
you should do the latter.  Perhaps there are other solutions besides the two
that I have mentioned.

     Good luck.

Brian H. Powell
		UUCP:	...!uunet!ut-sally!brian
		ARPA:	brian@sally.UTEXAS.EDU

   _Work_					 _Not Work_
  Department of Computer Sciences		P.O. Box 5899
  Taylor Hall 2.124				Austin, TX 78763-5899
  The University of Texas at Austin		(512) 346-0835
  Austin, TX 78712-1188
  (512) 471-9536