Retrieving handle for cursor leads to non-disposed resource error

[HeikoKlare]

Mirror ticket for:

• [Win32] Retrieving handle for cursor leads to non-disposed resource error eclipse-platform/eclipse.platform.swt#2355

[ShahzaibIbrahim]

Problem

Currently, when retrieving a handle for a specific zoom level via win32_getHandle, a new Cursor resource is internally created just to obtain the native handle. This leads to two major issues:

• The temporary resource is never disposed, causing resource leaks.
• We cannot safely return a handle from a previously disposed Cursor instance.

---

Proposed Solution

To fix this, the Cursor class should be refactored to manage zoom-level-specific handles more robustly and safely. The following changes are needed:

1. Extract OS Handle Creation Logic
   Move the logic responsible for creating native OS handles out of the constructors and into a separate method. This allows win32_getHandle to lazily create and cache handles on demand.

2. Always Initialize Default Zoom Handle
   Upon creation of a new Cursor, always initialize and store the handle for the default zoom level (100) immediately. This ensures that the cursor is usable right after construction.

3. Remove handle Field
   Eliminate the dedicated handle field from the class. All handle accesses should go through the zoomLevelToHandle map, which now acts as the single source of truth for all zoom levels.

4. Update All Related Methods
   Refactor all methods that previously relied on the handle field to instead use zoomLevelToHandle. This includes:

   • hashCode()
   • equals(Object obj)
   • isDisposed()
   • destroy()

---

Benefits

• Eliminates resource leaks by ensuring that all handles are properly tracked and owned by the cursor instance.
• Enables safe, lazy creation of per-zoom handles when needed.
• Ensures default usability by initializing the zoom=100 handle at construction time.
• Simplifies and centralizes handle management logic for better maintainability.