[comp.windows.news] references, references, where are those references

spock@ihlpf.ATT.COM (Weiss) (06/04/89)

I have a litewin that contains some buttons.  The following code
runs when one of the buttons is pushed:

	{
		newprocessgroup
		/foo bar send
	} fork waitprocess pop
	/bar null store
	/destroy self send

the /foo method creates an object with its own event manager.
The problem is the window doesn't go away.  There must still
be a reference to it somewhere.  If I make the code look like:

	/foo bar send
	/bar null store
	/destroy self send

the window goes away!  What am I missing?  Where is the extra
reference coming from?  How does forking a process to invoke
the method change things, especially since the process dies?

If I make the code look like:

	{
		newprocessgroup
		(foo) pop
	} fork waitprocess pop
	/bar null store
	/destroy self send

the window goes away.  I'm real confused.
-- 

Ed Weiss	   "I thought it was generally accepted, sir, that
att!ihlpf!spock     vulcans are an advanced and most honorable race."
		   "They are, they are.  And damn annoying at times."

spock@ihlpf.ATT.COM (Weiss) (06/07/89)

I previously posted an article under this subject that described
a problem with creating a process from a window.  One thing I learned
is that if you want the process to live past the death of the
window, you have to put it in its own process group (/destroy of a
window does a killprocessgroup).  The real problem that I am having
is that when this process does live past the death of the window,
the process somehow keeps a reference to the window (so the canvases
are not garbage collected [and don't get removed from the screen if
they are mapped]).

Well it appears that my problem is that when you fork a process
it gets a copy of its parent's /SendContexts.  Why this happens, I
have no idea.  It seems to me that the child's /SendContext should
just be the current object.  Am I missing something obvious?

If I try to modify the /SendContext I get a invaildaccess.  Which is
probably a good idea, except if it is wrong.  Has anyone else come
across this problem?  Any fix/workaround?
-- 

Ed Weiss	   "I thought it was generally accepted, sir, that
att!ihlpf!spock     vulcans are an advanced and most honorable race."
		   "They are, they are.  And damn annoying at times."