Window.Close not always working


Xojo 2019 R31

I have a window with a close button that calls self.close and it works correctly. I also want to close this window programatically from within a container control embedded in that window. I have tried both Windowname.close and Windowname.Closebutton.push. In both cases, the window flashes off, then a new instance almost immediately appears. This window has ImplicitInstance set. At the present time, I am not doing anything in the CancelClose event.

How can I get the window to stay closed when I ask it to close?

Thank you very much!

Jim Wagner
Oregon Research Electronics

WindowName.close is creating a new instance of the window type, then closing it.
This is because implicitinstance is set.

If you want to close ‘this’ window, you would normally use 'self.close’
If that command comes From within a containercontrol, that may close the container which in many ways can be considered ‘a window glued to the big window’
I’d need to check.

Try self.close first

If that closes the container, try Window(self.parent).close

self.close closes the container.

I get an “illegal cast exception” from Window(self.parent).close !


have a look into TrueWindow
The docs says that works up the control hierarchy and returns the ‘final’ parent, no matter how deeply nested.


Argggh! me.TrueWindow.close behaves the same as the others, close then re-open. Is there something I can do in the CancelClose or Close events?

Things have changed since the last time I dealt with this several years ago and I don’t know my way around!

Hmmm, I COULD turn off ImplicitInstance and create that window as a property of the splash window that stays open, behind it.


Then somewhere in your code you refer to the window type name, rather than the instance.

  • If you have implicit instance turned on
  • And your window is called frmStuff
  • Any reference to frmStuff.(something) will open an instance of that window if it does not exist.

So normally you do this if there will only ever be one of that window.

The gotcha comes if somewhere you ALSO do this:

Var MySuperWindow as frmStuff

because now you have an open window of type frmStuff, but it isnt CALLED frmStuff.

and any line of code that does frmStuff.txtInput.text = “” will cause a second copy of the window to appear.


check your code for lines like this:
Var MySuperWindow as frmStuff

and either take them out so you always talk about frmStuff
find all the places where frmStuff is used, and (probably) replace them with ‘self’

Thanks, I’ll give that a try. This operation is being called from several functions deep and there may well be a reference to that parent window after that attempt to close is made.

Really appreciate your help.


Raise the event from the container to the window so that the window.close is really only called from one location.

1 Like

i was thinking of something like that. Will try it if I cannot find the source of the new instance.

Beatrix’ solution finally did it. The attempted close was in one of a 30-entry select case structure that was followed by a call to refresh a canvas in the parent window. All attempts to change that away from an explicit window name caused other problems that I don’t entirely understand (but probably OUGHT to make the effort to find out). Being the impatient sort, I fell back to the solution Beatrix suggested and that worked like a charm. Thank you both for your time and effort.


1 Like

You kinda were then… :slight_smile:

followed by a call to refresh a canvas in the parent window

Pleased you got it working in the end.

Just in case it wasn’t clear, Implicit Instance is the reason the Window was able to reappear after you closed it. If you’re familiar with the Xojo framework you should turn Implicit Instance off. As a crutch, it’s worse than training wheels on a bike.

Yes, I understand that ImplicitInstance is a crutch. Not yet re-refamiliar enough with the framework to be confident to not use it. In the end, I was really not trying to close the window in a way that even fit the program structure that I had designed. Once that was fixed, it worked correctly in spite of ImplicitInstance.

Thanks for everyone’s help.