[comp.lang.smalltalk] Smalltalk V/286 TopPanes

yon@apollo.HP.COM (David Yon) (01/03/90)

Has anyone had trouble with seemingly "orphaned" TopPanes (and
their associated subpanes and editors)?

I'm working on a prototype which has a lot of activity in terms
of creating new TopPanes (for editing objects) which only remain
open for a short time.  I first noticed a problem when I tried to
remove my subclass of TextEditor called "LineEditor", a specialized
Editor for single-line text panes.  Since I recieved the Goodies#2
with the Field Pane Class, I no longer had any use for it.

At any rate, when I tried to remove LineEditor from the system, I got the
message, "has instances".  I evaluated "LineEditor allInstances" and
lo and behold there were around 10 instances remaining.  Curious,
I also evaluated "TopPane allInstances", and found that even though
there were only 5 windows opens on the screen, there were 23 instances
of TopPane in the system dictionary.  Upon closer inspection, I found
that these were instances of windows that I had closed long ago.

Why would these still be around?  When I created the TopPanes, they
were attached only to temporary variables.  Why wouldn't they disappear
when I clicked the close box?

Any help appreciated...

MUHRTH@DB0TUI11.BITNET (Thomas Muhr) (01/04/90)

This is a response to David Yon's message, where he wonders about image-
filling panes left in the system without an appearant handle to get rid
of these. I had these kind of problems too, and with a little help from
the very knowledgeable people here got finally (hopefully) rid of them.
The problem is that every time you open a view on a model the dependencies
between them is recorded in a classvariable of Object, 'Dependents'.
Upon closing a view these dependencies are (very radically!) removed from
the Dependents-dictionary. But, if the dispatcher didn't get the chance of
performing a correct close, which can have lots of reasons (we all produce
erronous code sometimes...), the dependencies stay in the list.
You should do the following: Dependents inspect. Than remove all models,
which you are sure are NOT the ones which are needed (Transcripts TopDispatcher
 etc.) This should help.
Another way of getting rid of instances, which is more harmful, because you
can 'saw the branch you are sitting on' (I don't know, if this is a valid
english idiom...) is the following:
! Behaviour methods!
eraseAllInstances
self allInstances do:[:inst| inst become: String new].
You can now erase ALL instances of a class by: CLASSxyz eraseAllInstances.
BUT, TextPane eraseAllInstances will give you a hard time......
Good luck, Thomas

-------
Thomas Muhr, Technical University of Berlin, BITNET: muhrth@db0tui11
   Project ATLAS - Computer Based Tools for Qualitative Research
         "Computers, like every technology, are a vehicle
      for the transformation of tradition." (WINOGRAD/FLORES)

bwk@mbunix.mitre.org (Kort) (01/05/90)

In article <47d02008.20b6d@apollo.HP.COM> yon@apollo.HP.COM (David Yon) writes:

 > At any rate, when I tried to remove LineEditor from the system, I got the
 > message, "has instances".  I evaluated "LineEditor allInstances" and
 > lo and behold there were around 10 instances remaining.  Curious,
 > I also evaluated "TopPane allInstances", and found that even though
 > there were only 5 windows opens on the screen, there were 23 instances
 > of TopPane in the system dictionary.  Upon closer inspection, I found
 > that these were instances of windows that I had closed long ago.

You probably have dependencies between the panes and their contents.
Evaluate "Scheduler reinitialize" to get rid of this crud.  (This
will cause *all* windows to go away, leaving you with a fresh Transcript
window.  You can then open a fresh Browser and WorkSpace.)  If you want
to keep some things around, you will have to inspect Dependents and
manually release just the ones you no longer want.

--Barry Kort