Extremely annoying problem/bug with panel movement

[Olivercomputing]

In Design view, every time I select any sort of panel that already contains children - even if I select using the Component tree on the left to ensure proper selection - I cannot grab the panel with the mouse to move it. It invariably picks one of the children and moves *that*.

Please fix this ASAP.

Perhaps I should add: I consider the *correct* behavior to be selection of the panel AND any of its children, so that movement moves the panel+children correctly.

[Eric Clayberg]

There is nothing here that needs to be "fixed". It is working correctly as designed. If you click on a child and drag, it should move the child. If you click in the parent outside the bounds of any of its children (e.g., in its white space) and drag, it should move the parent and all of the children. Being able to click and drag children within a parent (to move or reorder them) or move them between parents is a very important feature.

The only time there is issue is the case when the children completely fill the parent so that there is no parent white space to select. In that case, you can select the parent in the tree and then drag it in the design view by its border. A nice shortcut is also available in the design view - if you have a child selected, hitting the Esc key will change the selection focus to its parent. Once the parent is selected, you can drag it via its borders without extracting one of its children.

[Olivercomputing]

The only time there is issue is the case when the children completely fill the parent so that there is no parent white space to select. In that case, you can select the parent in the tree and then drag it in the design view by its border.

Yes, I have layouts (using SmartGWT layouts, e.g. using HLayout and VLayout) where the children completely fill the parent, which is surely not an unusual case. And indeed I tried selecting the parent layout and then going to design view - and there is *no way* to "grab" the border. It de-selects the parent and selects the nearest child instead. So I still fail to see why it does *not* need fixing.

Also, why I try <Esc> as you suggest, it does not switch to the design view, it simply de-selects the layout (I am using Galileo SR2 in OS X).

[Eric Clayberg]

You did not mention SmartGWT (currently in Beta test) or OSX originally, so we tried HLayout and VLayout in SmartGWT in both Windows and OSX and it worked exactly as I described earlier.

If a child in a container is currently selected, the Esc key will change the selection to the parent (in the case of HLayout/VLayout, you should see the number of handles change) and the parent may then be dragged by its border.

If you are seeing a different behavior, we will need to see a test case that reproduces this (on the chance that you are encountering some edge case that we had not anticipated).

[Olivercomputing]

Sorry about not mentioning the SmartGWT. I see now what you mean about the ESC. After further experimentation, I can move the parent container, but I have to select the left side of the box - not the top, which is how I was attempting to grab it before. Thanks for the help.

[Olivercomputing]

A thought that occurs to me - I think it would avoid the selection problems altogether if the editor recognized, say, the control or option key being pressed when clicking over a currently selected area, which would indicate that that area should be kept as-is, without attempting to detect a child selection. That way one could just click inside rather than trying to click on a very narrow border.

[Eric Clayberg]

Another thing you can do is using the Marquee select function to select the entire container and all of its children.

Dragging it will then drag everything at once and preserve the hierarchy.