I’d appreciate some comments here. In a DesktopContainer I have, amongst other items, a rectangle with a canvas on it, the same size as and sitting exactly on the rectangle, and two DesktopButtons on top of that. The idea is to be able to write some text at the left end of this structure, while the two buttons are at the right end. For this to work, requires that the rectangle be at the bottom, next layer up is the canvas, at the top should be the buttons.
For some reason I can’t get this ordering to reliably stick; the symptom is that, on Linux or the Pi, I can see the buttons become active as expected, but clicking on them does nothing. Back in the IDE on my Mac Mini (Mojave, with 2021r3.1), if I select the buttons one by one I see that they are no longer at the top of the stack and by clicking on the Order Forward button I can get them to the top, after which running remotely on the Pi or a Linux VM.
There’s a fragility there somewhere such that if I do something elsewhere in the DesktopContainer, I’m upsetting this ordering, but I don’t know what. I’d almost prefer that everything had a z-order property that could be set explicitly.
And where is the ordering info stored? I looked through the text file for this DesktopContainer and can find nothing about ordering.
Yes, I see that, essentially. But the tab ordering is not the issue, it’s the layering order, as controlled by the set of four buttons to the immediate right of the tab group you circled.
seems this 4 buttons only order in one level of controls list.
my understanding is
container have controls ← rectangle
rectangle have controls ← canvas
canvas have controls ← 2 buttons
i think xojo order only inside of each list.
it does not change the hirachie of all.
you can see the behavior better if you overlap two buttons.
make one order back and click beside of this edit window.
then make the other one order back and click beside of this edit window.
they are still at the canvas.
i think this tab ordering window also display the hirachie.
could you make a screenshot from your “tab ordering window” ?
Doing a test here with just the CC in a window, what might work is to make the canvas shorter by enough so that the buttons sit on the rectangle rather than the canvas.
The CC will get resized in practice, and it looks like the canvas will resize properly if I adjust the locks correctly. That works on the test setup. Of course, I’ve not been able to make the test setup fail on Linux, which is always what happens, so I’ll have to test this in the full app.
OK so making the canvas shorter works OK on my Pi, my Mint VM, and macOS. And it works better when resizing the window as the text on the canvas does not become overlaid by the buttons as the window narrows, so that is a plus too.
I guess the lesson is not to layer too many things.
