There is a severe exception occurring in NetBeans 6.8 that I first observed in NetBeans 6.7. For no identifiable reason, when attempting to access the project properties dialog in the NetBeans UI, nothing happens whether attempting to access the project properties dialog via right-clicking on a project for the pop-up menu or from the NetBeans menu bar.
The only way to remove the problem requires completely uninstalling NetBeans including the user data, then reinstalling NetBeans. If the user data is not deleted during the uninstall, the problem persists after NetBeans is reinstalled.
I had hoped that this problem had not been inherited from NetBeans 6.7, but that unfortunately appears to be case. Whether it now persists in the newly released NetBeans 6.9 is to be seen.
This is a very serious problem.
Never heard of such a problem. Need a way to reproduce; or info about what exact files in the userdir, when removed, fix the problem; or relevant log file excerpts showing an error.
This same problem occurred repeatedly with version 6.7, and I reported it: https://netbeans.org/bugzilla/show_bug.cgi?id=177335
The problem never occurred in version 6.5, and, was therefore, created by something that was changed between versions 6.5 and 6.7. I have been using version 6.8 for months on a daily basis and had not observed it until yesterday. The only remedy is to completely uninstall NetBeans along with the user data, then reinstall NetBeans. It's possible that something in the IDE is corrupting data being stored in the user data that makes modifying the project properties impossible.
Just because someone who's been working on NetBeans hasn't heard of a particular problem before doesn't mean that it can simply be dismissed and declared "resolved" when nothing was done to identify the problem and repair it. I'm sorry that I don't have log data to provide to you, but when I was using version 6.7 and this problem was occurring far more often, there was no relevant information being stored in the log about what was happening and the only way to restore the ability to modify a project's properties was to delete that information (along with all the user data) along with NetBeans in order to make NetBeans usable again.
I never knew when the problem was going to happen before with version 6.7. I would be using NetBeans, opening, editing & closing files contained within a project; then, if I needed to modify the project's properties, it would be inaccessible. There was no way to predict or reproduce the problem and several coworkers also using NetBeans experienced the exact same problem and, like me, never knew when it was going to occur.
What ever this problem is, it is certainly not resolved and I am marking it as such.
There is no way I could identify the problem without more information from you, which is what the INCOMPLETE resolution signifies. See for example: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
If deleting the user directory (or simply using a new one, with --userdir) causes the problem to disappear, then presumably some file in the userdir is a trigger. If so, a simple bisection procedure can be used to identify that file: back up your userdir first; then delete half of it randomly (e.g. half of the top-level subdirectories), and restart the IDE. If the problem still occurs, try to delete half of the remaining files. If it does not, restore half of the deleted files. Continue until the responsible file has been identified. The identity of this file on its own might be enough for me to guess what the actual problem is, or it might serve as a starting point for constructing a reproducible test case. (It is possible for problems to arise from deleting some but not all of a set of userdir files unrelated to the bug being investigated; but in general NetBeans is designed to treat userdir files as optional overrides of a default configuration, so that for the most part they can be freely deleted if they pose any problems.)
Or the problem might be triggered by some environmental change, such as to XP's window management settings, or to the JDK used by NetBeans.
Definitely if any warnings or exceptions appear in the IDE's log file when the problem appears (but not before), that would be relevant information.
Jesse, please see:
I talk about it some there. Anyways, the file storing the settings is:
and that is a feature to keep the position. I added it with another NB dev a while back. All the original code I provided is not there though. See:
and look for the usages of CUSTOMIZER_DIALOG_HEIGHT. You'll see what it is doing with the other information along with the height (x,y, width, height).
I'll try to fix it and provide you a patch and a check in if satisfactory sometime soon unless you see it right off. But, the issue is if the x or y, either one, is less than or greater than the current displays max or min in either case then x and y should be recalculated to center on the display which WindowManager.getDefault().getMainWindow() resides and then perhaps the width and height should be recalculated to fit on that screen more correctly, but only in the situation where x and y must be recalculated.
The reason that feature is there, to keep coordinates and size, is that one resizes the project properties dialog to see certain things depending on their screen size and the amount of information they want to see on the screen. I do that quite often. By storing that information for the next time the dialog is shown, the developer/user doesn't waste time resizing the dialog over and over. This is often needed to be able to see paths better in tables etc and other values which are too long for the default dialog sizes and positions. Sometimes I will have the dialog resized over mutliple displays too. So, this helps support multiple monitors better as well.
I added the original feature because I found myself wasting quite a bit of time on projects with longer paths in certain fields I couldn't see right off.
*** Bug 186402 has been marked as a duplicate of this bug. ***
*** Bug 177335 has been marked as a duplicate of this bug. ***
Am I getting the summary correct? And can I confirm that there is a tested workaround, to delete projectuiapi.properties? If a fix can be verified this might be appropriate for backporting, TBD.
Yes, deleting the file after stopping the IDE, then restarting would fix the issue for that time at least. Too, there are workarounds related to asking to OS to move the invisible window using the keyboard and shortcuts.
For instance, on windows when it happens, one can ALT+SPACE, choose move, and then use the keyboard arrows to put the window back in the visible area. Closing the window after that will correct the issue until it happens again as it will overwrite the values.
I have used both methods on this single system of mine which the issue has arisen. I suppose it happens on this one because I use it with multi-monitors, no external monitor, and sometimes am using a docking station. Something in between all the switching around buggers it up pretty good.
This should really only affect systems which have been using multiple monitors at some point and the positions and sizes have been changed etc.
I need to see if I can figure out exactly how to reproduce the situation easily so I can verify a patch. I will try to work up a patch in the next so many days and get that verified unless you beat me to it. I first need to try to see if I can make it happen more often. Maybe I can move my monitors orientation around a bit while opening and closing project properties and break it. Will report back sometime tomorrow.
A patch would probably not be difficult to write but I am not sure I could properly verify it, so assistance would be great. Certainly I could change screen resolution between IDE runs, but that would not capture problems with multihead displays (which I do not own).
Just an update. I've been trying to make this happen again on my system. No real luck, but haven't had too much time to devote. Will try to figure out more a little later this week and hopefully the patch can be done over the weekend.
If you can produce a tested patch by Friday this can probably be released in a 6.9.x update; otherwise it will have to wait for 7.0.
I'm generating a diff which fixes this. I found I could reproduce on this system by moving my displays inverse of each other while opening and closing the project property dialog. Should have the .diff file attached shortly. This was made against the release691 branch of the releases repository.
Created attachment 102430 [details]
Patch to fix the issue
This patch was made against the releases repository branch release691
The patch is attached Jesse. Sorry it took me until Friday evening instead of morning. I tried to get it last night, but the repos had changed on mercurial (hg.netbeans.org) so I had to reget etc and patch and all.
*** Bug 190228 has been marked as a duplicate of this bug. ***
Can you review & verify the patch?
Committed core-main #98cb87ec9336 with only minor modifications (unused bogus import; simplified comments & formatting). I am not personally able to verify since (as previously noted) I do not have the right kind of hardware to trigger the bug in the first place. I can verify on Ubuntu that if I open the Properties dialog for a (Maven) project, move it partly offscreen, hit Enter to close, and then reopen the dialog, it is restored to a fully visible position (even after an IDE restart). The patch looks sane but it would be nice to have some more formal verification that it works.
Thanks, I will talk to QE tomorrow if I can get the fix verified before integrating
Integrated into 'main-golden', will be available in build *201010190000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Log: #187608: Project Properties inaccessible after reduction in screen dimensions.
Transplanted from main http://hg.netbeans.org/releases/rev/1bd3984d76bb
cannot reproduce in 6.9. patch2, marking verified.