It happens that for unknow reasons, all -1 controls are too near the top (above a Canvas).
So, I have to move down all Controls (minus 1): I select all, press the shift key to unselect the Canvas and I pressed Shift-Down Arrow to move then to the bottom…
All I get are Beeps…
The only thing I can do is to move the Controls with the Mouse to the bottom,
Deselect all / select the top/left one to know where the block is (x,y),
Select All (minus the Canvas) and move
Until I found the correct value… (below the Canvas, left aligned with the Canvas).
PS: yes, I’ve made an error some weeks ago when I created the window and populated it. But a “Lock / Unlock Selected Controls Together” feature is needed.
Apparently it does not works when the Controls are different (TextFields, TextAreas and Buttons).
Yes, I saw the Lock icon (for once I saw something… ) and tried it.
And to confirm that, we do not need to lock say Buttons, just selecting Buttons / using Shift-Arrow allow moves.
Your screen shot gaves me the idea to check that.
BTW: I do not disclosed:
Xojo 2025r1.1
Sequoia 15.5
MBP13" M1
The green highlight color means the focus is on the Navigator, so you cannot move controls with the arrow keys. On a Mac, clicking the Layout editor background with the Command key switches the focus back to the editor, so you can select the controls in the Navigator (Shift-click makes it easy to select a range of objects, and Cmd-click allows to exclude the ones you don’t need to move), Cmd-click the Layout editor background, and then move all the selected controls with the arrow keys.
To lock or unlock controls you have to select them first. It’s not just a toggle that fixes all controls or allows them to move. Locked controls will show a padlock on the control in the window editor are you seeing that padlock? I’ve never had problems locking every control at once.
Ah, ok. You can “group” controls by adding a canvas to the form and then placing your controls within that canvas. You can then move the controls by just moving the canvas. You can also show and hide all the controls with one line of code by showing / hiding the canvas. It works like a groupbox control without any visual user interface.
That’s embedding. A “physical thing” resulting in implications at runtime and structures. Most “design” editors, if not all, allow grouping/ungrouping of components, a thing that affects only the layout at design time, and sometimes the z-order. Really a good feature a had to learn how to live without it in Xojo.
It does not affect how you access the controls, they remain as controls on the window, as they used to be, accessible via “WindowRef.ControlName” exactly as before.
It isn’t the same as having a Container control, which does make access control changes. It is exactly like using an invisible GroupBox control, as I pointed out.
It will certainly put limitations on z-order and tab order.
It adds an unnecessary new control in the memory and wastes resources, and all the dev wanted was moving a bunch of contents grouped around in the layout during the design time. A “grouping” exists only at design time, it’s just a drag and position thing not compiled.
The only difference between a GroupBox and a Canvas is that one has a visible interface and the other, by default, doesn’t. I’ve never ever suggested that it was what you wanted. Only that it was a way of grouping controls, that had runtime benefits (hide / show all with one line, etc).
I pointed out right in my first post about it that it was the same as using a GroupBox, with all that entails. I even put quotes around the word group to indicate that it wasn’t exactly what was requested. Quite why you felt the need to say it as well is beyond me.
The problem with using another control of any sort to group controls at design-time is entirely that it doesn’t cease to exist at runtime, it’s not a question of GroupBox versus Canvas. Not only does it add another control and use (however infinitesimal) resources, but it may have unintended side effects, especially if using an image or multi-color background behind it on Windows. While it may be acceptable for Emile’s project, there will be others where it certainly isn’t and the user may not understand why they’re seeing what they are.
That’s the point that Rick is trying to make, I believe.
From what I can tell, the GroupBox was your introduction to the discussion and Rick is saying that, at runtime, it creates the same issues as a Canvas when the additional control is unnecessary for what the user actually wants: the ability to group controls together at design-time only to make moving multiple controls simpler.
Such virtual object groupings are possible in many/most visual editors. Think of linked layers in Photoshop.
) and tried it.
