Bug 196200 - Provide a closing option similar to JDialog.DO_NOTHING_ON_CLOSE
Provide a closing option similar to JDialog.DO_NOTHING_ON_CLOSE
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Dialogs&Wizards
6.x
PC Linux
: P3 with 3 votes (vote)
: 8.0
Assigned To: Stanislav Aubrecht
issues@platform
: API, API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-03 00:01 UTC by David.m Beer
Modified: 2013-09-17 08:03 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Patch to add described feature (32.57 KB, patch)
2011-03-04 16:23 UTC, David.m Beer
Details | Diff
Diff (31.49 KB, patch)
2011-08-04 12:16 UTC, David.m Beer
Details | Diff
Test Project to test patch (18.07 KB, application/zip)
2011-08-04 12:25 UTC, David.m Beer
Details
Diff (2.79 KB, patch)
2011-08-09 11:19 UTC, David.m Beer
Details | Diff
New patch (10.60 KB, application/octet-stream)
2013-09-12 12:36 UTC, Stanislav Aubrecht
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David.m Beer 2011-03-03 00:01:36 UTC
Would be nice to have a closing option similar to JDialog.DO_NOTHING_ON_CLOSE, so that you can stop dialogs from being closed. There maybe rare occasions when this is needed. For example upon first run of an application and setting default or admin credentials. As the application depends on a admin user.
Comment 1 Stanislav Aubrecht 2011-03-03 09:44:10 UTC
you can use DialogDisplayer.getDefault().createDialog(...) to create a new Dialog instance, cast it to JDialog and adjust default close operation yourself.

if you need a new api for that - i'll happily integrate a good patch:)
Comment 2 David.m Beer 2011-03-03 13:21:19 UTC
Thanks for the information. I managed to use JDialog.DO_NOTHING_ON_CLOSE option by using the method you described. I can't help but feel there is a better and more simple way of doing this. Could a simple change in NbPresenter.java to stop the dialog from closing when the array option is empty and an option stop the 'Esc' key from closing the dialog.
Comment 3 David.m Beer 2011-03-04 16:23:19 UTC
Created attachment 106719 [details]
Patch to add described feature

Changed NbPresenter to set WindowConstants.DO_NOTHING_ON_CLOSE when an empty array of closingOptions is set. This also sets the ESC key command to do the say. This means that the closing of the dialog must be handle by the user when setting setClosingOption(new Object[]{}).
Comment 4 David.m Beer 2011-06-23 10:04:28 UTC
Hi 

Would be nice to have this in either 7.0.1 or 7.1. I have a lot of projects planned for NB platform use and it would be good to know this feature is there.
Comment 5 Stanislav Aubrecht 2011-08-03 10:07:03 UTC
there are several problems with the patch:
- it has a lot of unrelated changes (probably line endings, added/missing empty lines). please do not reformat the code
- there is no documentation for the API change. apichanges.xml must have a new entry for this
- WindowConstants.DO_NOTHING_ON_CLOSE is zero and NotifyDescriptor.YES_OPTION is also zero. i think the descriptor value should be null in this case
Comment 6 David.m Beer 2011-08-04 10:29:44 UTC
Hi

Thanks for the reply. A few points.

1. Please don't assume I made the formatting change. Or that I changed anything else.

2. I was not aware of having to make a change to the apichange.xml file at all.

3. A little more guidance on this might have helped get this resolved quicker.
Comment 7 David.m Beer 2011-08-04 12:16:50 UTC
Created attachment 109790 [details]
Diff
Comment 8 David.m Beer 2011-08-04 12:21:21 UTC
Comment on attachment 109790 [details]
Diff 

New patch which includes changes to apichanges.xml.
Comment 9 David.m Beer 2011-08-04 12:25:29 UTC
Created attachment 109791 [details]
Test Project to test patch

This suite project demonstrates that the patch fixes the issue with both OK_OPTION and the YES_OPTION from DialogDisplayer
Comment 10 Stanislav Aubrecht 2011-08-04 12:43:40 UTC
try using hg diff -git to generate the patch, it might be more readable then.

the change should also be document in NotifyDescriptor c'tor and DialogDescriptor c'tor
Comment 11 Jesse Glick 2011-08-04 14:54:24 UTC
(In reply to comment #6)
> Please don't assume I made the formatting change.

Intentionally or not (*), you made the formatting change, and now that is part of the patch, which is unreadable: what should be a few diff lines is instead hundreds. The onus is always on the submitter to prepare a clean patch for review (or on a committer to produce a clean changeset).


[JG01] I am not sure about compatibility (and addition="yes" in apichanges.xml is wrong); some current code might be creating a dialog with no visible closing buttons but still expecting ESCAPE or the window close button to work. Maybe an explicit flag to disable the window close button and ESCAPE would be more discoverable as well as safer.

(By the way, this is unusual UI. Generally you would permit the dialog to be closed, but just behave accordingly - e.g. shut down immediately in your original example.)


(*) If you use "Remove Trailing Whitespace" in the NB IDE's editor, be sure it is set to "From Modified Lines Only". "Always" is unsuitable for work in a versioned repository that historically has some trailing whitespace. And never use Reformat on versioned sources except on a line range you have just written/edited.
Comment 12 David.m Beer 2011-08-04 17:31:53 UTC
For the documentation do you mean the JavaDoc at the top of the NotifyDescriptor and DialogDescriptor classes.

Or Do I need to change some other documentation.
Comment 13 David.m Beer 2011-08-04 17:56:27 UTC
(In reply to comment #11)
> (In reply to comment #6)
> > Please don't assume I made the formatting change.
> 
> Intentionally or not (*), you made the formatting change, and now that is part
> of the patch, which is unreadable: what should be a few diff lines is instead
> hundreds. The onus is always on the submitter to prepare a clean patch for
> review (or on a committer to produce a clean changeset).

I have fixed the issue with the formatting and will upload a new diff.
> 
> 
> [JG01] I am not sure about compatibility (and addition="yes" in apichanges.xml
> is wrong); some current code might be creating a dialog with no visible closing
> buttons but still expecting ESCAPE or the window close button to work. Maybe an
> explicit flag to disable the window close button and ESCAPE would be more
> discoverable as well as safer.
> 
This would be my prefered way of doing things however I do not know enough about the NetBeans APIs yet to make this sort of change.

> (By the way, this is unusual UI. Generally you would permit the dialog to be
> closed, but just behave accordingly - e.g. shut down immediately in your
> original example.)
> 

If I could handle the ESC key as well as the close button on a DialogDescriptor or NotifiyDescriptor then this would be the desired behaviour. Casing to a JDialog didn't exactly solve my problem. Or other peoples that I know of.
Comment 14 David.m Beer 2011-08-09 11:19:26 UTC
Created attachment 109883 [details]
Diff

The diff shows the proposed changes without the extra formatting added.
Comment 15 David.m Beer 2011-08-09 11:20:37 UTC
I am happy to learn about how the API could be changed to make things better I just need some guidance. I am happy to work with you to  make this happen.
Comment 16 Jaroslav Tulach 2011-08-09 13:35:04 UTC
Y01 Typos in API changes
Y02 Document this behavior in javadoc of setClosingOptions method
Y03 Write a unit test
Comment 17 Jesse Glick 2011-09-02 13:00:18 UTC
(In reply to comment #13)
> This would be my prefered way of doing things however I do not know enough
> about the NetBeans APIs yet to make this sort of change.

This would be a new bean-like property in NotifyDescriptor that would need to be interpreted by NbPresenter.


>> Generally you would permit the dialog to be
>> closed, but just behave accordingly - e.g. shut down immediately in your
>> original example.)
> 
> If I could handle the ESC key as well as the close button on a DialogDescriptor
> or NotifyDescriptor then this would be the desired behaviour. Casting to a
> JDialog didn't exactly solve my problem.

I am a bit confused - was this really a response to comment #11, or a response to comment #1?

If you _can_ somehow behave gracefully in response to cancellation, you do not need to deal with JDialog directly - DialogDisplayer will return CLOSED_OPTION if the dialog is closed using the window close box or ESCAPE key. So this API change would be useful just for cases where there is no sensible response to a cancellation of the dialog and the user must work with it somehow.


[JG01 cont'd] <compatibility addition="yes"> is still wrong. This is a theoretically incompatible change in behavior and should be marked with the according attributes on <compatibility> and a nested <p> explaining the possible impact on existing code. I.e. in the hypothetical case of a module calling setOptions(new Object[0]) but expecting the user to be able to close the dialog as a last resort, that code should be modified to call at least dd.setOptions(new Object[] {DialogDescriptor.CLOSED_OPTION}), and possibly to also include CANCEL_OPTION.


[JG02] 'pressedOption = WindowConstants.DO_NOTHING_ON_CLOSE' makes no sense and should probably just be removed. There is no such option defined in NotifyDescriptor.


Y02 refers to DialogDescriptor.java; the apichanges.xml entry should be in openide.dialogs.


Y03 may be hard to satisfy since this is GUI code. I would have no idea how to test such a change meaningfully.


By the way it seems that while the close button can be made to do nothing, it cannot be removed: http://stackoverflow.com/questions/942056/remove-x-button-in-swing-jdialog
Comment 18 David.m Beer 2011-09-05 15:26:53 UTC
Hi All

I can make changes Y01 and Y02 I am not sure how we could write a Unit test for this. 

Having given this some more thought would it be better to add a new constant that can be used for this behaviour keeping the existing API as it is?
Comment 19 Jaroslav Tulach 2011-09-06 12:56:28 UTC
New constant would be slightly more compatible. As the test goes: there are some in openide.dialogs as well as in core.windows. Try to copy one of them adopt it to test your case.
Comment 20 Stanislav Aubrecht 2013-09-12 12:36:49 UTC
Created attachment 139985 [details]
New patch

I've a new patch for this issue. It introduces NotifyDescriptor.setNoDefaultClose(boolean) method to turn off both ESC closing and dialog's title bar close button (by using JDialog.DO_NOTHING_ON_CLOSE)
Comment 21 Stanislav Aubrecht 2013-09-12 12:37:41 UTC
If there are no comments I'll integrate the changes next week.
Comment 22 Stanislav Aubrecht 2013-09-16 08:28:50 UTC
I'll integrate the changes tomorrow.
Comment 23 Stanislav Aubrecht 2013-09-17 08:03:15 UTC
core-main c18ea2115f59


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo