Comment 1 Steven Spungin 2014-06-08 09:37:25 EDT

Gerrit Review: https://git.eclipse.org/r/#/c/28176/

Comment 2 Paul Webster 2014-06-11 10:05:54 EDT

We can review this at the beginning of Mars.

Something to keep in mind:  What's the goal?  Because of its current usage, I don't think we can auto-create the arrowCursor if it's not there on a get*() ... the current users control the parent control of the cursor on creation, like org.eclipse.jdt.internal.debug.ui.jres.InstalledJREsBlock:

if (arrowCursor == null) {
    arrowCursor = new Cursor(cancel.getDisplay(), SWT.CURSOR_ARROW);
}
cancel.setCursor(arrowCursor);

So adding the getters and setters will smooth out what usage?

PW

Comment 3 Steven Spungin 2014-06-11 10:37:23 EDT

> What's the goal?

The arrow cursor is managed and must be disposed.  Furthermore, it is created on demand and is not available until the cancel button is created.  This is the whole point of having an accessor.

With this use case, adding additional buttons before or after calling super.createButtonsForButtonBar() should be able to access that member.  Current implementation results in a null value if accessed before.

> I don't think we can auto-create the arrowCursor if it's not there

Once the shell is available, can't we just do this in the getter?
if (arrowCursor == null) {
    arrowCursor = new Cursor(getShell().getDisplay(), SWT.CURSOR_ARROW);
}

Comment 4 Daniel Rolka 2014-06-12 03:37:54 EDT

(In reply to Steven Spungin from comment #3)

> if (arrowCursor == null) {
>     arrowCursor = new Cursor(getShell().getDisplay(), SWT.CURSOR_ARROW);
> }

Are you able to use the system cursor instead of creating the new one, as below?

arrowCursor = getShell().getDisplay().getSystemCursor(SWT.CURSOR_ARROW);


When you use the system resources you don't need to take care about disposing it

Daniel

Comment 5 Mickael Istria 2019-06-14 16:44:24 EDT

In your custom dialog, you can initiate the arrowCursor more eagerly, in the constructor or by overriding the createCancelButton() method for instance to set the arrowCursor to what's desired and then call the super.createCancelButton() implementation. There are null-check preventing from resetting the arrowCursor that won't make your earlier setting overriden.
If your cursor don't have to be disposed, you can override the clearCursor method to set the cursor to null before call super.clearCursor(), so arrowCursor.dispose() won't be invoked.

So it seems like the current API provides way enough flexibility to deal with custom arrowCursor or custom arrowCursor lifecycle.
Let's close it as extra API wouldn't really enable more things nor much ease already possible ones.