Re: Dropping raster object?

[Barry McMullin]

At 12:30 15/10/96 +0000, I wrote:
>I expected that sending a -drop to a ZoomRaster class object would
>arrange for all appropriate cleaning up, including advising the TK
>interpreter to get rid of the corresponding widget.  However, when I
>try it, the widget seems to be left intact.  Further, my brief
>scan of the ZoomRaster (and Raster) source code didn't reveal any
>code to handle dropping the widget (unlike the case for probes, where
>there is clearly explicit code for doing this).  No doubt I can figure
>my way around this, but I thought I'd ask first whether anyone else
>has encountered/solved this problem?

Well, turned out I *had* to fix this, because the Tk interpreter was
crashing afterward if the raster wasn't properly cleaned up.

So - thanks to Manor - the problem has been analysed; Manor intends
to do a proper bug fix so that doing a drop on a Raster will indeed
do the required Tk cleanup; but, in the meantime, here is a quick
and nasty workaround: immediately before dropping the Raster object
do something like this:

  [globalTkInterp eval: "destroy %s", [[worldRaster getParent] getWidgetName]];

where, in this example, worldRaster is the Raster object we are about
to drop.

I can't guarantee that this totally fixes the problem (and you'll
have to remove this code again once the Raster class is actually fixed)
but it's a temporary workaround that seems to work for me...

Barry.


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Barry McMullin, Autonomous Systems Group,  |    address@hidden |
| School of Electronic Engineering,          |  Voice: +353-1-704-5432 |
| Dublin City University, Dublin 9, IRELAND. |  FAX:   +353-1-704-5508 |
| http://www.eeng.dcu.ie/~mcmullin/home.html |                         |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++