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.
I started NB, got a UnexpecteException dialog with a [Show details] on the left and an [OK] button on the right. I pressed the OK button, but by then some new exception had come in and it had shifted left to leave room for [Next >] and that is what I ended up pressing. Moral of the story ... don't move buttons around!
Possible solution is add both buttons Next and Previous,disable it until will not be need, but this is question for UI/HIE guys. UI, provide propose solution and assigne back, thanks in advance.
Ivan, I found your reasoning sound and forced Ok button to stay on very right in all situations.
x
Oops, I was just as fast as Marian and fixed this issue in the same time Marian moved it to ui bugs. Ui, if you don't agree with my fix, please suggest other implementable solution.
I am sorry.
Hmm, Dafe in my opinion would be better to have Next,Ok and Previous button visible and enabled or disbaled depends on next/previous exceptions. UI please, is Exception dialog according to your all UI and HIE specs ?!
No feedback from UI, ok it's new habit :( verified in [nb_dev](20020628)
marians suggestion is good - provide the buttons and enable them when needed.. i guess this comment is coming in way too late..
Ok, thanks Maya. Reopen and changing version to 4.0 dev.
Yes, it's way too late. We won't make this very end user visible change that late in the release cycle. High resistance this Wednesday !
Target milestone was changed from '3.4' to TBD.
*** Issue 27267 has been marked as a duplicate of this issue. ***
Could be target milestone changed to something closer than TBD.
Hi, is this for 3.4? Why the version is 4.0 then? Or not? Can this come into 3.4.1?
> Hi, is this for 3.4? Yes, it is. > Why the version is 4.0 then? because it was founded in the dev build of next release. > Can this come into 3.4.1? Yes, it can, but it isn't fixed still.
Changed version to 3.4, since it happens in 3.4 too, Please, correct me if I did something wrong. Also added 3.4.1_CANDIDATE If someone volunteers to fix it, I'll include it to 3.4.1 Thanks for you patience ;-) Maxym Mykhalchuk
??? IS IT Fixed or Not ??? David wrote: > Oops, I was just as fast as Marian and fixed this issue and but Marian Mirilovic wrote: > verified in [nb_dev](20020628) but Marian Mirilovic also wrote: >... it isn't fixed still.
Clarification: Original issue was fixed by me, Ok button is now not moving around, but other buttons are appearing and disappearing, like previously. But this way of fixing didn't attract UI nor Marian, that's why he reopened. They want buttons Prev, Next, Ok visible all the time, only disabled when some of them has no function (Next on last exception, Prev on first exception in the list). I tend to agree with them that this solution is better. So: We need someone to change the code to perform dynamic buttons enable/disable instead of current appearing/disappearing. Ugh, it is clear now? I think Marian needs to be more exact next time ;-)
> I think Marian needs to be more exact next time ;-) Ok, thanks for clarification, next time I will be more exact, I promise.
Oh Marian, take it easy, didn't you see the smile?...or grin :-)
changed owner Dafe -> Peter Z.
Hi. This issue is marked as 3.4.1_CANDIDATE. It means that it should be integrated into release341 one branch. The plan at http://www.netbeans.org/devhome/docs/releases/34/index.html expected beta1 to be produced on Dec01. That did not happen due to a lot of outstanding not integrated candidates like this one. Would it be possible to spend few minutes by backporting this fix? Thank you in advance.
Removing 3.4.1_CANDIDATE keyword. This issue was not fixed yet, therefore it is not possible to integrate anything. Moreover, it is still unclear to me what it the actual problem. Please could anybody provide some test case explaining it?
Dafe has fixed Ok button position to 3.4 release. To Peter: But I have had another suggestion (HIE agreed) , that buttons Next,Previous, Ok should be visible, depends on situation will be enabled/disabled (prohibit adding/removing buttons).
Could anybody explain why TM is set to 'future'? Thanks
*** Issue 51430 has been marked as a duplicate of this issue. ***
As I saw P2 I thought wow it will be finally fixed after almost 3 years, but ... it's only enhancement :(
Created attachment 20731 [details] preview w/ disables buttons
Look on the attached picture. There is a exception dialog with with disabled Next/Back buttons. I don't like it, should be considered by any UI expert. Opinion?
Input needed from UI team...
(In reply to comment #32) > Look on the attached picture. There is a exception dialog with with disabled > Next/Back buttons. I don't like it, should be considered by any UI expert. > Opinion? Jiri, please read my original first comment. The picture you posted is a static picture. But our world is a dynamic world and that's where problems arise. This happens in NB especially more because it's so multithreaded. That things shouldn't jump around should be a basic principle of the whole IDE. Not to mention that if I wanted to watch animations of things I'd go watch the cartoon channel. Things jumping around, flashing etc is distracting. Call me old fashioned but that's why I stick to newspaper rather than reading web news. Even /. is going down that slippery slope. What is it that you don't like about the dialog? Buttons are an "Elephant in a phone booth"?
The position of displayed buttons must not change (with the exception of auto-aligning during window resize), there is no question about that. Moreover, changing dialog size in response to user actions in the dialog is also bad practice. However, showing disabled controls may suggests to users that they might become active as result of some user action in the dialog; if this is not the case they may also be perceived as (slightly) misleading. To come up with a reasonable suggestion it would be good to know whether is it more common to see just one exception message, or a collection of several messages ? It seems to me that the case of a single exception being thrown is frequent enough to take it into account as a case that would benefit from cleaner dialog contents than in the case of multiple messages. This does not mean to have different dialog - just that some elements may not be relevant if only one exception is to be reported. It is also good to take into account that at first just one exception may be reported, but more can appear during the dialog lifetime and the dialog will need to adjust itself to inform about the newcomers. See the attachments. I suggest to have a dialog with fixed positions of all buttons, Show Details aligned left and Prev, Next, Review and Report and Cancel aligned to the right. This would also impose the minimum size of the dialog which should be respected at all times. However, as long as no more than one message is to be shown - i.e. at the beginning - there is no need to have the buttons Prev and Next visible. The same holds for the dialog title - in case of just one message keep it related to the one message only. Only when the next message comes up, the dialog would be adjusted in two ways: both buttons Prev and Next would be made visible in their fixed position (in correct enabled/disabled state) and the title would be extended by " x of y" postfix with x being the number of the current message and y being the total number of messages. This change to the dialog is done only once, until the dialog is closed all buttons are displayed in their given position and the only thing that may change is their enabled/disabled status depending on which message is currently displayed. Note that in this case no UI components are moved around, and no change of dialog size should take place. The Prev and Next buttons would come into play only if more than one message would have to be displayed. Thus, in the fairly common case of a single message the dialog UI would remain as clean as possible. comments?
Created attachment 119302 [details] Suggested message dialog showing one message only
Created attachment 119303 [details] Suggested message dialog when more than one message needs to be displayed