I’m sorry, it’s just been too long and I’ve been working with Xojo/Real since 2001. I’ve lost track.
There long has been issues with setting Z-Order’s of objects on a Window, both in design-time and run-time.
In the latest version of Xojo, is there any (reliable) way of making sure a control is on top of the others - mostly run-time dynamic, but also design-time?
This is not really an answer to your question…but, for Window at least, it is not recommended to overlay controls over each other. I’ve not noticed any issues with Z order in the IDE but I don’t really overlay controls so I rarely pay attention to the Z order. You might be able to open your old project in the latest version and fix the deprecations and give it a try.
have you an example why you have one control overlapping an other?
a) As usual you have to test z-order yourself.
b) What do you expect to have changed or not changed?
c) Nested pagepanels with containers work fine.
What do you want to do with it. If you want to change it at runtime, it was still a PITA last time I checked.
Under Mac, I do not know how to set z-order at run time.
Under Windows, it is easier to do BringWindowToTop.
with https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-bringwindowtotop
@Dale_Arends posted the declare here: Bring application to Front - #6 by Dale_Arends
On the Mac it is a simply declare, unless you do it from the mousedown event of the view you want bought forwards, in which case you have to send everything else backwards!
You said above it was a PITA ?
It is if you wanna adjust the z-order on the view that the customer is directly interacting with, Xojo doesn’t like views/controls being moved around behind it’s back.
I have two controls (a sheet-window button and a date/time selector button) that at runtime I want to occupy the same spot on the layout. For ease during development I site one 40 pixels east of the other on the layout, and then at Opening time I move it 40 px west. Only one should be visible at once, so I use .Visible to manage that and the approach appears to work.
You mean Xojo does not like when you change z-order at run time ?
It is mainly where I have a Canvas in the background, giving some color and fashion to the dialog, and the controls are on top of it. There are instances where a PushButton is invisible, then I set Visible=True, and the Canvas is on top of it so it doesn’t even show. But at design time I can see the control. (And I’m not even going to talk about the times where the control.Visible=True and doesn’t appear but you can still click in the area and it works.)
Disappointing, I thought Xojo/Real would have fully dealt with this by now. It’s been years, if not decades. The responder who said “best not to overlay controls” seems unfortunately correct. I can abide by that advice mostly, but it’s hard when I want a window/dialog to look better than just the utilitarian gray/other and I want a Canvas as a backdrop.
why not use the paint event from your dialog window?
make a method with g As Graphics input and call it at paint event.
the other controls on top could be transparent.
In the IDE, you should send the canvas to the back. Then at run-time the ordering will be correct. I have a number of canvasses with several controls on the canvas. That is the way to make that set of controls be scrollable together.
Back when Joe R was working for Xojo, he helped me with a great many things (as did Norman). The rule of the thumb is that the Xojo runtime likes to maintain the view hierarchy atop the macOS, but the Xojo framework is missing a lot of functionally (there are feedbacks for some of it), meaning if you want to use 'em, you have to use declares and go behind the frameworks back, which can lead to problems if you’re trying to do something a little more complex.
When you use declares to alter the view hierarchy, you’re moving the control behind Xojo’s back and thus it can lead to all kinds of problems as the Xojo framework doesn’t know and will continue to use values from before.
It why Listboxes don’t work correctly on Popovers (there’s feedback for Xojo to provide popovers and feedback for Xojo to help those of us who want to use popovers).
But my main issue with how to do it on the Mac is, if you want to bring a view/control forward when clicked by the user, you must move all other relative views backwards, otherwise it breaks the mousedown event.
I understand. In Rubberviews, I may move and dimension stuff with declares, but afterward, I set those with Xojo.
For zorder, it is simply not possible to inform the framework.
I posted a Windows declare, but personally, I never used it. So it probably is as fiendish.
Caution is advised…
setting/changing zorder was very easy in VB6, I wonder why It cant be done with Xojo.
It is all a question of design. Apparently, Xojo decided long ago that zorder should be design only.
Amazingly enough, it is possible to change zorder at run time for Web.
Not sure if this is relevant, but I had a similar situation recently with a canvas on top of another canvas, with the top one not being visible at runtime. Here is the trick/hack/workaround that solved it for me: If you drag a canvas onto another canvas in the IDE, you will see the bottom canvas highlight in red, indicating that it’s become the parent or something of the one being dragged. You don’t want this. If I first place the top canvas outside the bottom one instead, so that the bottom one doesn’t show a red highlight, then position the top one using the arrow keys (hold shift for 10x movement) or by entering Top and Left in the Inspector, the bottom one doesn’t highlight and the top one remains visible at runtime. HTH.
Is this current behaviour of the IDE a bug or a feature?