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