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.
If a container's children cover its area completely it becomes impossible to carry out basic operations like dragging it across the form. Through experimentation I discovered that holding down ALT while clicking on the child component causes the parent to get selected but this was very from intuitive. Even then, the operation was very clumsy. We need a more intuitive way to select and interact with parent components. For example, if I select a parent component in the Inspector tab then clicking on it in the form editor should it retain its selection (allowing me to drag it and do other things). Right now when I try this the child component gets selected instead.
I agree that the current implementation is quite clumsy in this case. On the other hand, I am not sure how to improve it. Your suggestion would simplify the use-case that you describe but it would make other use-cases harder. For example, it would be difficult to select a component when its parent is selected. If you have an idea how to keep both these use-cases simple then I would be happy to implement it.
I was thinking of something like this: - Simple selection: user clicks on component with no overlap, Netbeans selects it - Complex selection: user clicks on a component with an overlap \-> If the currently selected component overlaps the area that was clicked, retain the selection and carry out any subsequent operation such as dragging \-> If the currently selected component does not overlap with the area that was clicked, select a peer (same-level) component first, its ancestors next. In other words, given: A contains B and C, B is selected, user clicks on C. Netbeans would select C before A because it's a same-level component with a common container. Does that make more sense or should I keep looking for a clearer solution? With the above approach the user only ever needs to use the "component inspector" when he wishes to explicitly alter his selection "level" (which should be rare). This assumes that it is more often for a user to operate on a selected or same-level component than it is to operate on an ancestor.
(waiting for a reply)
Here's another possible approach: When editing components in the GUIBuilder, add an artificial whitespace/border between the container and its children. This whitespace exists purely to facilitate parent vs child selection.
*** Bug 197672 has been marked as a duplicate of this bug. ***
Here's a way I think this could be handled: The GUI builder would detect when a container that is fully or almost covered by subcomponents is selected and offer an additional handle, e.g. paint a small square in the middle, which would allow to grab the container and move it without changing selection. The mouse cursor would change on the handle to the four-arrows move cursor.
I like Thomas' approach as well. Keep in mind what will happen if you have multiple containers (3-4 levels). Will it be usable then? At the very least it should be usable for a single level and users can shift their view to edit elements inside a nested container.