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.
How to reproduce: - Use a project with multiple java files, including forms - In one file with a form, ensure that properties window, pallete window and inspector window are open - In this file, ensure that you select the form and not the source - Switch to another source file without form with [Alt+Arrow] - Keep swiching until you hit the file with the form again - Try to switch once more, with the same key as before Expected behavior: The next source file should become current Actual behavior: The form stays current and the keystroke for switching is ignored. Observation: When switching to the file with the form, then one of the windows "Properties", "Pallette" and "Inspector" gets on top and gets focus. That window appears to block everything. Please examine my other issues regarding window top position/focus. Each of these individual issues may seem to have a minor impact. However, the number of different bugs that are experienced by a single user in a singele session is very large. This combination of a high number of bugs (not thhis bug alone) renders Netbeans useless in SDI mode, at least when running on the reported platform. I am encouraging the assignee to escalate this problem.
This is issue in form editor. Reassigning to form.
It works correctly in MDI and I don't see any problem on our side. Reassigning to Window System - the activation of TopComponents should work consistently in MDI and SDI. TopComponentGroup.open() in SDI calls JFrame.setVisible(true) on the Palette, Properties and Component Inspector windows. Both the setVisible() and open() calls return back before the windowActivated() method is invoked on the listeners on these frames. So, the active TopComponent is correctly set when the call to TopComponentGroup.open() finishes. Unfortunately immediately after that the windowActivated() methods of listeners are invoked and the focus is moved to one of these frames. Window System should somehow distinguish between activation of the Frame by user's gesture and openning of the TopComponent. It should not change the activated TopComponent in the second case.
reassigning, i've done related stuff lately.
actually I think this one is unfixable or at least not fixable in a clean way. setVisible(true) on frames will *always* front that frame (so palette/inspector/props components get fronted.) when the OS activates these, swing schedules a focus transfer to the activated window. the activation and focus transfer do not happen in the same thread as the setVisible() call, thus can very hardly be overriden (So calling toFront() on the correct frame after opening the new ones won't help) From our code we cannot open the frame without fronting it AFAIK. What we could do is attach a listener to the newly opened frames, and when all get windowActivated() callback, just front the correct frame to be activated. This still doesn't have to work 100% due to the nature od DefaultKeyboardFocusManager. Even if it works, it will give frame flashes to the user as the various frames start fighing for the top position. Just another example of how SDI cannot really work.
Milos I don't want to argue about SDI can't really work - the difficulties are there. On the other hand there needs to be some mode where the user does not have to permanently re-size frames because not all windows can be accomodated in the user's viewing space. Not easy to implement apparently. This bug is one of very few real problems with SDI that I am aware of. You have made great progress recently with other SDI issues - many thanks. I think this issue directly results from the change where the form editor was integrated into the new editor where before that, it was a separate window.
this is rather related to the disappearance of workspaces and the replacement with component groups. component group gets opened/hidden when a form file gets shown/hidden. having it as separate tab or grouped together wiht the sources makes no difference. My advise is to use the sliding windows (autohide) feauture. The first time the inspector, palette and properties files are opened, autohide them and make them part of the editor frame. On iterating the opened documents, only the bar will appear. This is fully under our control thus can be worked on. There are currently some deficiencies like fixed size of the slided windows, but fixes for that are planned.
SDI is gone as far as I know. However it's possible to extract single views from the main desktop. The issue itself persists, however having the properties+Palette windows separate is now optional reassigning to dsimonek.
x
NetBeans.org Migration: changing resolution from LATER to WONTFIX