This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
NotificationLineSupport doesn't display the notification until a dialog has been created. Doesn't work: desc.createNotificationLineSupport(); panel.setDialogDescriptor(desc); desc.getNotificationLineSupport().setInformationMessage("Hello"); Dialog dialog = DialogDisplayer.getDefault().createDialog(desc); Works desc.createNotificationLineSupport(); panel.setDialogDescriptor(desc); Dialog dialog = DialogDisplayer.getDefault().createDialog(desc); desc.getNotificationLineSupport().setInformationMessage("Hello"); desc.setValid(true); // works regardless whether or not the dialog has been created. So, NotificationLineSupport is inconsistent This was really frustrating to debug. If there's no fix for this inconsistency, at least an exception should be thrown.
Hmm. Haven't yet looked at its internal code, but seems to me some listeners should be hooked to the dialog in case of the descriptor being changed including its notification line support. Then, it is truly a descriptor. Here, it seems those method calls are directly related to the dialog and the components on them. To me, those values can be created and added to the dialog when they are created, and that would be correct. This doesn't seem correct to me currently, and just making it throw an exception would not make it correct, an actual descriptor, but it would help with the issue at hand until it can truly be corrected, but definitely it needs corrected. I may take a stab at it later this weekend because I can't stand things like that. I can at least provide a patch to see if everyone agrees.
Tagging it to find it later without assigning it to me @wadechandlerpatch. I'm just going to check it out to see what a patch for this will involve.
Read carefully Javadoc, it states in http://bits.netbeans.org/dev/javadoc/org-openide-dialogs/org/openid /NotifyDescriptor.html#createNotificationLineSupport() "Note: Call this method _before_ you call DialogDisplayer.createDialog(org.openide.DialogDescriptor)" Anyway, a Wade's prospective patch will be welcomed.
Look at issue 148730 where we discussed this API. In short, the reason for this API behavior is the backward compatibility. In a dialog contains NotificationLineSupport, the DialogDisplayer has to allocate some space for this support. In the case we allow users to attach this support for a already created dialog, there will be no space what this. Only two possibilities we have in this case: jump size of the dialog when createNLS or allocate that space defensively for all kind on dialogs. IMHO none of them are acceptable. Wade, if you know a way how to fix such problems, I'll glad to apply it. Thanks
@jrechtacek Why was the message area's size fixed? Seems using a JEditorPane with HTML support would have been optimal. Looks like a JLabel, but can have a scroll pane and can then be multi-line. Could do a couple things there. Say, if the message wraps more than two or three lines add a scroll pane and put the message there. That gives developers options at least. Too, why would resizing the dialog automagically not work? In case the panel and layout they are using doesn't resize to fit? Seems that would 1) be a guide rule for NB developers and 2) in RCP folks would see the issue in their testing and adjust their panels. However, if it is vertically resized it should be fine eiher way as the dialog shouldn't be taking up that much vertical space as is, and the UI panel they add, if a custom component is used as the message, shouldn't be resized for the overall dialog being resized vertically which is created from the descriptor. Too, can set the scrollable area to be a max of 4 or 5 lines...which ever is more readable to help with any possible too large vertical sizes. Then the message can be as long as needed and as visually descriptive as needed using HTML. That versus a longer message loosing context and ending with a ... (JLabel behavior) On the createNotificationLineSupport ... I think what David is writing, unless he has written it wrong, is that you have to call setXXXMessage after the dialog is created; he is calling createNLS before creating the dialog in both his examples. The way he said that actually worked is an anti-descriptor pattern. Basically the UI components have to be created before the message can be set. Seems the message should be set before the descriptor is used to create a dialog. My other point where I mentioned being able to call it after the fact by hooking some listener or something was based on the notion that the class is directly trying to use the UI components versus the descriptor being in charge of this information. Anyways, I need to look into the code, but setXXXMessage on NLS should be callable before creating the dialog, and should work that way; as a descriptor versus this mixed way of working. If it is important to keep it working the other way we can have the logic do one of two things 1) have createdDialog create and use the NLS from the descriptor and change how setXXXMessage works to set the property and access a UI component directly if it is set (dialog created) or 2) have createdDialog attach some listener to the descriptor, adding property events if needed, and have the dialog adjust to changes in the descriptor on the fly if needed after it has been created. Those calls can be forced to be on the event thread as needed. And, all setXXXMessage does besides setting a property is fires an event. Then if a dialog is created with an attached listener great and if not who cares.
@jrechtacek Pls, read the snippet in the first comment carefully. desc.createNotificationLineSupport(); is invoked before createDialog, in both cases The problem is desc.getNotificationLineSupport().setInformationMessage("Hello"); must be invoked after createDialog
John, I'm sorry. You are right, your snippet is not about sequence of calling createNLS and DialogDisplayer.createDialog but about NLS.setInfoMessage and DialogDisplayer.createDialog. Sorry for blaming you with a unrelated Javadoc. I agree this should be fixed. -jiri
Created attachment 74969 [details] proposed patch
Simple, just added getters for already existing setters.
Created attachment 74970 [details] api change
Looks like it already had support for properties. Made that part much easier indeed. Seems to work right from a source perspective. What did you think about the suggestion to allow multi-line comments and using a height limited JEditorPane? Might be able to spawn a new issue from this for that. I love multi-line comment capabilities and have those type things in dialogs in other applications is why I would like it.
Wade, I've filed another RFE for multi-line support - issue 155533.
Thanks. I'll try to work up a patch for that and if folks like it and agree then great.
I'll integrate it tomorrow.
fixed in core-main/rev/a4ad94a7c101
Integrated into 'main-golden', will be available in build *200812221122* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/a4ad94a7c101 User: Jiri Rechtacek <jrechtacek@netbeans.org> Log: #155401: NotificationLineSupport doesn't work until a dialog has been created