No way to remove up to the last DesktopContainer?


I’m trying to remove all DesktopContainers to a given window (before filling the window with new containers). It should be oblivious, but I can’t make it to work.

The containers are in a control array, so one is already placed in the window, to begin with.
This code:
Var c As CNTAudioVolume=CNTAV1(0) 'CNTAudioVolume is the class, CNTAV1 is the name

if c=nil then Exit

… loops forever. It seems like c isn’t nil but its Close method doesn’t remove it from the window (the Close method correctly removes containers whose index is greater than 0).

I can’t find another way to remove an existing DesktopContainer from a window; also, Issues doesn’t find a case describing this problem.

One way would be to change the loop above, replacing (0) by (1) to remove all but the first container, and then hide the remaining one, but that’d be a workaround.

I find strange a DesktopContainer(0) can’t be removed from a window :man_shrugging:.

Your code is always calling the same container over and over again, thus having an infinite loop.

If the Close method was working as it should, Container(0) would always be the “next” container, up to the point where there’s no container anymore, at which point the loop would exit.

That’s what I’m saying. The infinite loop occurs because the Close method doesn’t remove the object as it should.

Yes, ISTM too that this ought to work.

What happens if you just execute close and then go on without looping? Or put a DoEvents in the loop? Maybe the loop is so tight close can’t execute.

DoEvents is almost never the right solution in a GUI app. It has a high risk of causing extremely difficult-to-diagnose bugs.


Instead of trying to repeatedly remove container(0), why not just work your way through the list (0, 1, 2…)?

Yes, I’ve only heard this 40,000 times in my 20 years of RealXojo use and forum participation. I was suggesting it as an experiment only (“What happens if…”), to try and track down the source of the issue, but I guess I didn’t make that clear enough in my post.

I’m confused by your premise. When I try to create a control array of DesktopContainers, I see this:

What version of Xojo are you using?

The irony of your suggestion is that you’re probably on the right track as to what the issue is: the tight loop in the code is preventing the GUI from updating. But that’s no reason to reach for the bug-maker that is DoEvents. Simply redesign the closing code to take this into account.

Ha. Despite Xojo and the IDE having told us for many years that container arrays are unsupported, you can actually create and use them just fine - simply enter their indices manually. I don’t know why they don’t just support them officially.

Or maybe Arnaud has made his own array and filled it with ContainerControls and is not using a ControlArray at all.

@Arnaud_N Perhaps did you create an Array, of DesktopContainers? (An Array of Containers is not the same thing as a Control Array)

If so, then here’s your problem - when you call c.close, the DesktopContainer will be closed, but the reference to it will still exist in your array. Xojo won’t destroy an object (setting it to Nil) until the last reference to the object is gone.

If I’m right, then this code should work:

while CNTAudioVolume.ubound >= 0
  CNTAudioVolume(0).close  // this closes the DesktopContainer, but does not destroy it
  CNTAudioVolume(0).remove // this removes the reference from the array, which allows the destructor to fire
1 Like

It is not ironic that I’m on the right track.

1 Like

That’s worth a bug report if true - are you willing to submit one? Either it should work, or it shouldn’t, but half-working is bad for everyone.

Oh, hell no. I would rather it just keep working. If you file a bug report they’ll probably “fix” it by removing the functionality.


@Julia_Truchsess - What version are you using? I’m trying the latest beta, and I don’t see any way to create a control Array, either using DesktopContainers or regular old ContainerControls. They may have already removed your beloved hack!??!

Edit to add: I tried it as far back as 2019R1.1 and it doesn’t work there, either. I get the yellow error message when I try to change the name of the ContainerControl just like shown above.

I submitted a couple of bug reports / feature requests regarding the documentation:


  1. Drag your ContainerControl from the library to a window.
  2. Using the Inspector, make it a member of a new Control Set.
  3. Drag another instance of your ContainerControl into the window.
  4. Make it a member of the same set.
  5. Enjoy having shared events

I should’ve kept my mouth shut :frowning:

You are correct, doing it that way works fine, with both API1 and API2 objects. Doing it the way I was trying (changing the instance name to another instance) fails with the yellow error. That’s very weird.

It’s not fair to misquote like that. What I said was:

I submitted a couple of bug reports / feature requests regarding the documentation:

if you read them, you will see that you are mistaken in your assumption.