Bug 196200

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:)

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.

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[]{}).

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.

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

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.

Created attachment 109790 [details]
Diff

Comment on attachment 109790 [details]
Diff 

New patch which includes changes to apichanges.xml.

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

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

(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.

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.

(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.

Created attachment 109883 [details]
Diff

The diff shows the proposed changes without the extra formatting added.

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.

Y01 Typos in API changes
Y02 Document this behavior in javadoc of setClosingOptions method
Y03 Write a unit test

(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

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?

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.

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)

If there are no comments I'll integrate the changes next week.

I'll integrate the changes tomorrow.

core-main c18ea2115f59