don@BALLAST.CS.UMD.EDU (Don Hopkins) (05/11/88)
Here is a function I wrote to put in the /destroy method of a window
that won't go away when I zap it. I was using text items in the
window, and they were not revoking their keyboard interests. This was
leaving references to the canvas around, and it was not getting GC'ed.
This function walks a canvas tree and revokes any interests expressed
therein. My window's /destroy method calls it right before going
"/destroy super send". Now the window goes away when I zap it!!! How can
I get text items to clean up after themselves, or do I have to do it
by hand? They don't have a /destroy method!
/nuke-interests { % can => -
begin
Interests {revokeinterest} forall
TopChild {
dup null eq {pop exit} if
dup nuke-interests
/CanvasBelow get
} loop
end
} def
The TextCanvas object that nterm uses seems to leave a couple of event
managers hanging around after it's destroyed. (nterm works OK, but I
was having problems using it for my own purposes.) I fixed this bug by
making the following change to TextCanvas's /KeyboardHandler method
(in /usr/NeWS/clientsrc/client/nterm/textcan.ps), so it remembers all
the interests to revoke when it's eventually sent a /destroy.
Old:
% --- Handler for keyboard, InsertValue, and Deselect events
/KeyboardInterest Can addkbdinterests def
Can addselectioninterests
% Get rid of LiteUI's mouse interests
1 get revokeinterest
Can addfunctionstringsinterest pop
New:
% --- Handler for keyboard, InsertValue, and Deselect events
/KeyboardInterest [
Can addkbdinterests aload pop
Can addselectioninterests aload pop
% Get rid of LiteUI's mouse interests
revokeinterest
Can addfunctionstringsinterest
] def
Other than that small problem, the TextCanvas that nterm is built on
is really nice, and fast too! I can't wait to see what it does when
it's past the prototype stage!
It's great that NeWS 1.1 now has "send" implemented as a C primitive,
as opposed to a PostScript function. But there seems to be a bug, in
that a newly forked process inherits its parent's /SendContexts. (The
key in the process that returns a stack of objects to which there are
pending sends on the process's return stack) I think that a newly
forked process should start out with an empty /SendContexts stack,
since only its parent can ever return to complete the sends. The
current behavior could cause problems, since it leaves extra object
references floating around.
-Don