[comp.windows.news] Hunh?

bice@hbo.UUCP (Brent A. Bice) (07/19/90)

   I've got a strange question.  I have a window that has a menu.  One menu
entry I want to have a function that will spawn a completely independent
window.  When the main window gets Zap'd, it should go away, but not kill
the window/s that it spawned.  I have a piece of code that does this, but
the main window won't die until all of the other window/s that it spawned
also are zapped.   Howcomeforwhy?   Am I missin' somethin' here?



/MainDict /ThisIsIt def

% Make a window with a new processgroup and a clean environment.
/makewin {
         {
            % Clean up dictionary stack
            {
               currentdict /MainDict known { exit } if
               end
            } loop
            clear   % clean up regular stack
            newprocessgroup
            framebuffer /new LiteWindow send dup
            /reshapefromuser exch send   /map exch send
         } fork pop
} def


% Here's the main window.  It has a menu entry that merely calls makewin.
framebuffer /new LiteWindow send
dup {
   /ClientMenu [
      (MAKEWIN)    { makewin }
   ] /new DefaultMenu send def
} exch send
dup /reshapefromuser exch send
/map exch send

laukee@canon.co.uk (David Lau-Kee) (07/19/90)

bice@hbo.UUCP (Brent A. Bice) writes:

...
>entry I want to have a function that will spawn a completely independent
>window.  When the main window gets Zap'd, it should go away, but not kill
>the window/s that it spawned.  I have a piece of code that does this, but
>the main window won't die until all of the other window/s that it spawned
>also are zapped.   Howcomeforwhy?   Am I missin' somethin' here?

Yeah, I found this too.  I never did get round to understanding what was
happening, but I worked around using a separate file and runprogram (which
is actually closer to the semantics I want anyway).

Something like:

/buttoncallback
{
	/graphic exch send /thing exch send
	{
		(Images) { /spawnimagebrowser self send }
		(Book) { /spawnbook self send }
		(Viewer) { /spawnviewer self send }
	...
	} case
} def

/spawnimagebrowser
{
	(/usr/vpl/demo/imagebr.ps) runprogram
} def

-------------
David Lau-Kee
Canon Research Centre Europe,
17/20 Frederick Sanger Rd, Surrey Research Park, Guildford, Surrey, GU25YD, UK.
NRS: laukee@uk.co.canon, INET: laukee%canon@nsfnet-relay.ac.uk
UUCP: laukee@canon.uucp, PATH: ..!mcsun!ukc!uos-ee!canon!laukee
Tel: +44 (0) 483 574325 Fax: +44 (0) 483 574360

siegel@booga.Eng.Sun.COM (Josh Siegel) (07/20/90)

In article <1990Jul19.153846.1586@canon.co.uk> laukee@canon.co.uk (David Lau-Kee) writes:
>bice@hbo.UUCP (Brent A. Bice) writes:
>
>...
>>entry I want to have a function that will spawn a completely independent
>>window.  When the main window gets Zap'd, it should go away, but not kill
>>the window/s that it spawned.  I have a piece of code that does this, but
>>the main window won't die until all of the other window/s that it spawned
>>also are zapped.   Howcomeforwhy?   Am I missin' somethin' here?

Below is the code:
    /MainDict /ThisIsIt def
    
    % Make a window with a new processgroup and a clean environment.
    /makewin {
             {
                % Clean up dictionary stack
                {
                   currentdict /MainDict known { exit } if
                   end
                } loop
                clear   % clean up regular stack
                newprocessgroup
                framebuffer /new LiteWindow send dup
                /reshapefromuser exch send   /map exch send
             } fork pop
    } def
    
    
    % Here's the main window.  It has a menu entry that merely calls makewin.
    framebuffer /new LiteWindow send
    dup {
       /ClientMenu [
          (MAKEWIN)    { makewin }
       ] /new DefaultMenu send def
    } exch send
    dup /reshapefromuser exch send
    /map exch send

Problems,
  A send command locks the DictStack so that you cannot "end" your
way into a class dictionary.  Under NeWS 2.0, this generates
a dict_underflow error.  Under some other versions of NeWS, I think
this fails silently (I don't remember which ones).  The proper 
solution is to replace:

                {
                   currentdict /MainDict known { exit } if
                   end
                } loop

 with
                clearsendcontexts

and get rid of the /MainDict noise.

    --josh