Community
Participate
Working Groups
Currently, it is quite hard to debug "graphic is disposed" errors. The exception is thrown long after the image is disposed, making it hard to track down the buggy code that disposed the image. If it were possible to attach dispose listeners to Images, Fonts and Colors, then the owner of the object to attach a listener which throws an exception if some other code attempts to dispose its Image. This would generate a stack trace that includes the buggy code that disposed the image.
I'm sorry but we didn't get to this for 3.1. My current thinking would be to add this as part of a tracing API. The problem with adding callbacks to the objects themselves is that there can be two different graphics objects that have the same handle (ie. Control.getFont () can return a new instance) and both would need to have the callback.
The important part of this PR is that it would be possible to catch disposal errors when the graphic is disposed rather than the next time it is used. It would be possible to solve this without dispose listeners. Here's how: ALTERNATIVE 1: Reference counting Add incRef() and decRef() methods to Image, Font, Color, etc. Nothing special will happen when the refcount reaches zero (clients still need to dispose their graphics as normal), but if an attempt is made to dispose the graphic while the refcount is nonzero, it will immediately throw an SWTException. This would solve my primary use case, and it wouldn't matter if SWT shares handles behind the scenes. I'm not relying on the refcount to perform any cleanup -- I'm just using it to ensure that someone I hand an Image to won't try to dispose that Image. ALTAERNATIVE 2: Locking/unlocking It would also be possible to solve this problem by adding the following methods: void lock(Object key); void unlock(Object key); If an object is locked, any attempt to re-lock it, dispose it, or unlock it with a non-identical key will throw an exception.
Neither will work because instances of graphics objects aren't unique ... but that doesn't matter for the problem you are trying to solve.
Created attachment 23501 [details] Patch for org.eclipse.swt Adds a locking/unlocking scheme with integer keys and minimal overhead.
Steve: what if we had a global service I could listen to (sortof like Display filters) in order to monitor the disposal of graphics resources. Something like: Display.getCurrent().addGraphicDisposalListener(graphicObject, listener); Whenever a graphic resource is disposed, it could notify the listeners via the global service. It wouldn't rely on the resources being unique - disposing any copy of the resource would send the notification.
