I’ve put a rectangle shape inside a window, and set its visibility to false. Then I put a visible control over it. Run and the visible control vanished. Why? In other platforms where we control exactly the z-order of the items it should be considered a bug. I was trying to make the rectangle to “blink” BEHIND the control.
Seems like the shape assumed a weird role of a container.
they can be containers
Oh man. That’s bad. That’s mean that fixing this can affect legacy code. Rectangle should be a shape. Containers should be containers. Can we disable the container behavior of Xojo shapes?
In the open event of the control you placed there simply set parent = nil
That’s as much control as you have
Folks have used shapes as containers for so long that disabling that in general would likely break a lot of projects
I’ve had to use rectangles as a container several times because it is better behaved in terms of layering controls and flickering on Windows than the Canvas is in certain situations. Usually when the parent Window has a non-standard background color set (which I don’t fully understand why, mostly just trial and error).
Yep. I’ve noticed that before you wrote your answer. All RectControl has a parent property. Seems that when dragging them on the IDE over another container like RectControl, you guys internally set this property (redish contour on parent control). Could be great having a key modifier while dragging (holding Control key while moving over and MouseUp?) that could place unlinked controls, with parent=nil, at design time. Can it be done, Norman?
Or a pop-up menu property on Inspector: Parent -> None or -> Name of the current parent control. So we can unlink them at design time.
Or add a design time property to the rectControl, like [Is Container] = ON. Them at design time, we could set it to OFF, and no one control dragged over it would be linked. So it would behave as shape with IsContainer = False.
Xojo engineers, please, choose your preferred Feature Request or I’ll pick one. Or a combination. 
None of the above
Yep, I knew it. Snagglepuss exit.
It used to be exposed but folks really abused the hck out of it
Like NOT putting a “child control” on top of the “parent” but setting the parenting manually - blech !
There ARE ways to make it so you DONT get controls parented if thats not what you want
Drag the new control onto the layout NOT on top of the rectangle (or whatever)
Make it wider than the control you’re going to place it on
Now position its top left corner where you want
Now resize it
Note you do not get the red “parented in” indicator
Norman, this is a interesting hacking using another flaw. When I was young I used to like finding this sort of things and reporting as bugs, because the correct way of doing it should be another way. 
Creating a direct, smart way, of attaching/detaching objects to parent using the visual tools without hacks (and see the current status : x is the parent of y, or y is detached), in a way it could be documented in the User Guide and everyone be proud of the solution. I’ll do workarounds by now, because you guys are really, really full of more important tasks. But this thing should change in the future. Anyway, thanks for the tip. 
The method I gave you is not a hack - its deliberate that controls are not parented when the control doesn’t completely fall inside the bounds
I’m just taking advantage of that and knowing that resizing does not cause reparenting to accomplish what I want
modifier + drag is already for other things so it’s not like its available to use to indicate “don’t parent”
Exposing “initial parent” in other ways lead to so many issues its why it was removed as a settable property in the old property inspector (that happened many many years ago - at least before 2007 - long before my time)
Submit a feature request & we’ll see
Then I resize it, and it falls inside the bounds and does not get parented as ruled: Hack.
Nope. Let’s wait Xojo 64 bit first. Then I’ll submit.
[quote=105242:@Rick Araujo]Then I resize it, and it falls inside the bounds and does not get parented as ruled: Hack.
[/quote]
It’s actually done deliberately - I actually was JUST looking in the code there for something else
It USED TO reparent when you resized but that was problematic
So it was changed - very deliberately - to NOT do that
It’s not a hack regardless of what you call it - its deliberate behavior