smith@canon.co.uk (Mark Smith) (08/21/90)
Well, at the risk of looking like a complete and utter prat, I throw
myself on the mercy of comp.windows.news in the hope of finding an
explanation for some very bizarre behaviour in OW 2.0. Below is a
simple window class definition, followed by 4 lines which create a
window on the desktop:
------------------------------------------------------------------------
/TestFrame OpenLookBaseFrame
dictbegin
dictend
classbegin
/newinit
{
(newinit userdict:\n) printf
userdict ==
(\n\n) printf
/newinit super send
} def
/destroy
{
(destroy userdict:\n) printf
userdict ==
(\n\n) printf
/destroy super send
} def
/place
{
reshapefromuser
} def
classend
def
/win ClassCanvas [] framebuffer /new TestFrame send def
/place win send
/activate win send
/map win send
------------------------------------------------------------------------
If you start up a psh and stuff this into it, you should see
the current userdict shown in the psh when newinit is executed.
Next, position and size the window on the desktop as usual.
When you choose Quit from the window's frame menu, you'll see
the current userdict in the psh again when destroy is executed.
The window doesn't go away since /win in userdict has a reference
to it. Now comes the weird part. If you remove the last reference
by, for instance, typing "userdict /win undef" in the psh, the
destroy method gets called *again*, this time in an apparently
different context (userdict is empty). You won't see this in the
psh; you'll need to have the server's stderr redirected to a file.
I start up Open Windows with "openwin 2>/tmp/owlog" and run
"tail -f /tmp/owlog &" in my console window. In my case,
as soon as I remove that last reference in the psh, I see
destroy userdict:
dict[
]
in the console. So why does destroy get executed the second time?
Am I nuts or what? Enquiring minds want to know.
(I'm running OW2.0 on an SS1. I don't know if this happens under 1.0.)
=========================================================================
Mark Smith smith@canon.co.uk
Canon Research Centre Europe ..ukc!uos-ee!canon!smith
-------------------------------------------------------------------------
soft driven slow and mad like some new languagesiegel@booga (Josh Siegel) (08/22/90)
In article <1990Aug21.144958.6645@canon.co.uk>, smith@canon (Mark Smith) writes: >Well, at the risk of looking like a complete and utter prat, I throw >myself on the mercy of comp.windows.news in the hope of finding an >explanation for some very bizarre behaviour in OW 2.0. [... code deleted ] --- > >If you start up a psh and stuff this into it, you should see >the current userdict shown in the psh when newinit is executed. >Next, position and size the window on the desktop as usual. >When you choose Quit from the window's frame menu, you'll see >the current userdict in the psh again when destroy is executed. >The window doesn't go away since /win in userdict has a reference >to it. Now comes the weird part. If you remove the last reference >by, for instance, typing "userdict /win undef" in the psh, the >destroy method gets called *again*, this time in an apparently >different context (userdict is empty). Once the window is created, there are 32 links to the canvas object (which that window is contained in). 31 of which are soft. If you remove the definition of win from userdict without "quiting" the window, the window will also kill itself. The reason for this is that once all the hardlinks are removed, a obsolete event is generated and the window /destroys itself. When you "quit" the window, all the links except for 2 soft links and 1 hard link are removed. When you THEN undef /win, the final hardlink is removed and that very same obsolete event is generated (again calling destroy). Does this answer your question? --josh