I have a DesktopContainer with three controls on it: two canvasses and a scrollbar. None of these shows the container as the parent; looking at the .xojo_window file (this project is saved as text) for this container, the scrollbar shows an InitialParent of “”, and the two canvasses don’t even have an InitialParent property.
This doesn’t seem right and may be related to the project having display artefacts under Linux, with 2024r1+, but not 2023r4.
Attempts to have the container parent these three controls fail. If I move one off the container, and start to drag it back, the red outline shows around the container, and is there while the mouse is down. As soon as I let go the mouse, the red outline vanishes.
There is a left canvas, a right canvas, a gap inbetween (the canvasses and the container have the same background colour). And the scrollbar at the right.
This doesn’t tell me why the controls in my container (see image above) are not parented by the container. Perhaps it doesn’t matter that they are not. But that would also be useful to know.
The image above is mine, the oval in the container shows (yellow marker) parented by my container as expected and explained. The same will occur with yours if done as said.
More like I’m obviously not understanding your remaining doubt, because I read what you wrote, and based on all I wrote, and examples, you should not be with any doubts.
I blame myself, and will ask to someone able to understand your remaining doubt, explain it using other terms because I couldn’t be clear. Sorry.
Do you see any difference between saving with 2024r1 and 2023r4 (or older)?
I mean with the InitialParent information?
It could be that containers contain controls and there is no need to save the parent information as the container .xojo_window has all the information needed, so the info is not needed. Or it could be a new bug.
Create a new project, add a container, add a couple of controls and save as text format.
Open the container.xojo_window text file and see the controls, none will say that the parent is the container.
The container will work correctly (will show the controls in it) but the text file is the problem (this is my guess).
I don’t see anything operating improperly. The controls are on the container, so you’ll find them in Container1.xojo_window, not as child items on Window1.xojo_window.
What exactly is the problem here? As I mentioned in another thread, the plain text format is not as simple as it seems, and I’m not seeing a problem.
InitialParent is when controls are parented on the same view (ie. Button1 inside of GroupBox1). Container instances placed on a window aren’t parenting anything in that way.
I saved also in XML, and that showed no difference with Text in terms of the values (or absence of) the InitialParent property for the conrtols within my container.
This issue has arisen because my app builds and runs as I expect it to identically under macOS, Linux, Win-10 when built with 2023r4. When built with 2024r1+, it continues fine under macOS and Win-10, but under Linux parts of some containers are rendered in the wrong places in the window - sometimes outside what should be their parent container. The debugger reports expected values for Top, Left for these items, meaning I can get no clues from the debugger.
I’m scraping around looking for possible reasons this happens and so I’m looking at things like parent, z-order of items, whether there are any issues with HTMLViewers on a PagePanel, whether it helps to put only Container instances on pagepanel pages, and so on.
So, looking at parent, I find this issue with canvasses in a container. Hence, my questions are:
Can a control fill (i.e., have the same width and height as) the container I’m putting it in? Or must it lie in the container such that there is space around it? (I’m guessing not).
Does it actually matter if these controls have no parent, or that I appear to be unable to have the containers be the parent of the controls within it? I’m guessing not here, too, but it would be nice to know.
Yes. Your control can fill the container entirely. Anything outside of the container design area will be clipped from view when you place an instance of that container on a window. (This is what Ricks post shows)
Control parenting is for when you’re nesting controls within the same Window / Container. Controls within a Container are not being parented in that way. They do however show the correct value at runtime for the Parent property:
Taking a wild stab at your layout issue, I might guess that something changed whether the position values are absolute or relative in some way. Things like this have happened in the past with Graphics.Clip. Your best bet would be to make the simplest project you can that shows the problem on Linux, submit a ticket with a lot of screenshots, and ping William on it.
