I assume you can lock a control to something other than it’s containing window?
i.e. if a listbox is inside a groupbox, can you lock it’s edges to the groupbox for resizing?
Seems to me that the key to this is looking at the red box around controls that have children inside them, but I can’t figure out other than trial and error how to “set” a control’s parent, i.e. which one gets the “red box” around it…
Looks like the red border appears as you drag a control over another item. However, I cannot get my listbox to become “contained” within the groupbox, only the main window.
How do I “choose” the parent of a control?
I assume you can lock a control to something other than it’s containing window?
i.e. if a listbox is inside a groupbox, can you lock it’s edges to the groupbox for resizing?
Mostly no
the only exception is a container control so you can lock controls to its edges and then when you put an instance on a layout they will resize etc based on how you then lock the container to its containing window
while you can set the parent - that has almost no effect as far as locking goes
dragging them around - really
in the IDE thats it
Argh.
Argh as in “I cant lock a control to another control ARGH!” ? or “I cant just select a parent control ARGH!” ?
Putting controls on controls only works reasonably in macOS because of how it composites things
Windows not so much
As I can’t select the parent control.
I got the listbox to finally allow the groupbox to be it’s parent. It’s all in the dragging. There SHOULD be a Parent property for controls.
There is one - but you have to set it this way
Allowing it generically as a property in the inspector (or in other ways) did allow for folks to make even worse messes (really)
And it was removed from being visible many many years ago (I think before I even started there)
IF a control can be a “container” then it will highlight when it contains the other control you’re dragging
Sometimes the trick is to make the one you’re dragging smaller so it will fit in the on you want to be the parent and then stretch it out to whatever dimensions inside the parent
But god help you if you parent it then simply change its dimensions to exceed those of the parent
You can get really screwy behaviour that might be hard to understand
And I think I was wrong about the locking
I so rarely relay solely on locking to do the right thing
if you put one control inside another and lock the inner one to edges then if the one containing it is unlocked from the window edges then neither grows (the inner one is locked to the containers edges which dont move as the window changes size)
Its reasonably sensible
edit : and if this is mentioned in the docs I’ll be darned if I know where
Well, here’s the thing. The property is there in the code, so how can dragging a control and setting it be any different than setting it manually?
lets just say that if you think you need to change a controls parent at runtime you’re probably doing some thing really wrong
I cannot think of a single instance where that has been necessary in any application I have ever written
not once in about 20 years
I HAVE had to set parent = nil on occasion
what makes you think you need or want to alter a controls parent from how its initially set in the IDE when you drag & drop things ?
You misunderstand me. I’m only talking about design-time. Like setting tab-order, there should be a manual way to set parent-child relationships. Not relying on perfect drag-drop ability. Forcing people to use ONLY drag-drop seems very strange in a programming environment.
Xojo’s focus on new user and people relatively new to coding probably plays into this
Anything that might be more complicated or confusing is avoided