Controls scrolled off a canvas continue to be visible

Xojo 2022r3 under Mojave.

I’m having an issue with one of my DesktopContainers. There is one instance of this container on a PagePanel, and this is liable to be resized by the user. The container has within it a canvas in the top half and some other controls below. When the user resizes the PagePanel, the other controls move up/down and the canvas becomes less tall or taller, to accomodate this.

Now: on the canvas I have another DesktopContainer with controls including + and - buttons which cause new instances of that Container on the canvas to be created and put on the canvas via EmbedWithin. I then adjust their Top/Left to position them. There is also the usual scrollbar so that, as more stuff gets added to the canvas by the user, they can then scroll it in the usual way. Containers that are scrolled off the top or bottom of the canvas should disappear, and reappear when scrolled the other way.

The problem is that under some circumstances, containers scrolled of the bottom of the canvas continue to be visible, until they vanish under the other controls below the canvas.

As far as I can tell from testing this is not happening in another DesktopContainer instance on another page of the PagePanel, neither does it seem to be happening under Linux or Win7/10 - only macOS. I’m checking with the debugger and it looks like the container is definitely off the canvas while still being visible.

Is it ever valid for controls scrolled off a canvas to remain visible? As fas as I’m aware, this looks like a bug, but I welcome comments on the matter.

AFAIK it depends on the relationship between the container and canvas.

If the container is a subview of the canvas (check the parent property) then by default this should be clipped by the view hierarchy. It can be overridden so that the canvas doesn’t clip subviews, unless Xojo is doing that, you’d need a declare to do it yourself.

Back after being away for two days.

There is a rectangle under the canvas and the same size. This is to give a backdrop to everything: the rectangle has a white background. Seems to me I ought to be able simply to paint the canvas white, there must have been a reason why I didn’t do that. I use the locks on everything to enforce the layout size changes.

Anyway, the rectangle is the parent of the canvas which is the parent of the containers. I have also checked that in the “bad” scenario, the canvas really is the size it appears to be (unless the debugger is lying) - when the controls are visible outside the limits of where they should be seen. I had wondered whether the canvas was really the small size it was supposed to be but had somehow remained larger, thus allowing the controls to be seen, but apparently not.

Therer seem to be two scenarios, one of which is OK, the other not.

1 - BAD) If I start with one of the embedded containers, and click its + button to add several more, I can’t then shrink the canvas up without the controls spilling over and being visible where thery shouldn’t be.

2 -OK) If I shrink the canvas up first, and then click the + button to add more controls, they all behave as desired in terms of visibility.

I guess I’m gonna have to start hacking at the DesktopContainer, try removing the rectangle, make a test case if possible.

@TimStreater I certainly made a bug report about option 1 (https://tracker.xojo.com/xojoinc/xojo/-/issues/68466). Mine doesn’t have containers, just controls. The principal is similar.

But your issue in in the IDE, isn’t it? Mine is at runtime. AIUI, you’d like that if you make the canvas smaller, thus causing a control to be stranded outside the canvas, it should cease to be parented by the canvas.

For me the reverse is true. If I scroll controls off the canvas, I expect them to cease to be visible, progessively, as they move off it. But they’d need to remain as parented by the canvas, else I can’t scroll them back on again.

I may have fixed my issue, by removing the rectangle I referred to.

Ah, I see. Fair enough.

I would have thought it should de-parent the control if it becomes outside. It does if you drag the control but not if you shrink the parent.

Interesting about the rectangle I don’t think that has anything to do with parentage, but it could alter the drawing code as the “transparency” isn’t real anymore, detecting the background and colouring it could cause issues that keep it drawing while scrolled outside…

I suppose that’s the debateable point :thinking:

What would be really valuable would be if the name of the parent control could be seen in the Inspector (or None). Otherwise I have to run the app and then plough through the structure to see which control is actually the parent of another. In the IDE One can see that something is parenting a control, but not necessarily what.

When I’d posted my OP, I’d spent a whole day trying to chase it down and, really, was too tired to be working on it. Two days away helped …

It would be good to see it. I suppose a Parent popup menu would be appropriate. It would be good to be able to have a control located on top of another but not have one as a parent of another. Obviously, there should only be one visible at a time.

Actually, I spoke too soon. I’d just finished a round of testing after removing the rectangle and checking it all still worked on macOS/Win/Lin (I use VMs for the latter two). I’d also done a certain amount of adjusting the Composite setting on as many Containers as possible - I seem to have a large number of artefacts when resizing things under Windows. And suddenly there was my problem back again. I had to revert to a previous version and apply the smallest number of changes I could to make it all work properly.

After that, I started poking through the .Xojo_window file for my DesktopContainer, and seeing how it differs between the good/bad versions. I adjusted the parenting and layering of the other controls below the troublesome canvas, and that seems to reliably fix my original issue. It’s not at all obvious why.

1 Like