Hi all. First time here so be kind:-)
I’m finding an issue with several Window().Close lines. This: Window(ProjWindow).Close [used in a number of places] returns: “Expected a value of type class ProjWindow.ProjWindow, but found a static namespace reference to class ProjWindow.ProjWindow.
Window(ProjWindow).Close”
I have no doubt I’m doing something wrong but other usage of Window(WindowName).Close throw no errors. Any ideas?
Excuse the brevity, but I’m on my phone.
Why cast it all? Does ProjWindow.Close not work?
Thanks Kem.
No, it returns: “Static reference to instance method: call this on an instance of class Window.ProjWindow.Close”
Window.Close seems to work when I’m closing the current window but I’m trying to close two windows - ProjWindow being the parent of the current window.
This means you have the implicit instance property turned off. With it on, you can access the window directly through its class name.
Was that intentional?
Not intentional. Experimental.
Thank you so much for taking the time on your phone BTW.
Well, turning on implicit instance stopped the error … but it still doesn’t close the window. The code closes the child window [tries to] close the parent window and opens a new window. So far the child closes and the new window opens behind the parent window.
You may want to show what you are attempting to do a bit more clearly. I am but a novice at this, but I believe the default behavior of the IDE is for windows to have the implicit instance default to true. That means that every time you reference them (from anywhere) they will “magically” show up, which is great but then you have to care about how and when you address them. This seems to be your second case, in which you may be trying to close one window from another one but when you call it then you sort of “instantiate” it again (if that is a valid word). In the first case you had the property off, in which case you have to handle all the life cycle (from creation, to destruction) .
Hey LangueR.
I believe the default behavior of the IDE is for windows to have the implicit instance default to true. That means that every time you reference them (from anywhere) they will “magically” show up, which is great but then you have to care about how and when you address them.
Which is why I was experimenting with implicit instance off for this particular window. Here’s the code in question: Window(ProjWindow).close Dim Story As New StoryWindow Window.Close
It’s at the end of a button action which adds a new row to the database. The button lives in a floating window [AddProjectWindow] which is a child of ProjWindow. Once it’s added the project database, and added a new row, I want it to close both the child and the parent windows and go to StoryWindow.
I’m getting lost with all the various guesswork, trying to solve it. So far it closes the child window and opens the new window but the parent window persists. I’m wondering if creating a method to close the projects window and calling that might work…
I couldn’t resist; Who’s on first?
If you’re creating the window apart from implicit instance, you need to keep a reference to it somewhere so you can get back to it. Implicit instance maintains a reference for you, otherwise, if you need one window to refer to another, you have to manage that reference yourself.
It sounds like ProjWindow is creating a AddProjectWindow. If so, I’d suggest adding a property to AddProjectWindow to hold a reference back to ProjWindow. Something like projwin as Window. Then in your button, you can say
projwin.close
dim Story as New StoryWindow
self.close
Sounds like you have a variable of the same name as the window type.
If you have two types of windows, typeA and typeB
you can maintain 2 app level variables to hold them
dim MyA as TypeA
dim MyB as TypeB
app.MyA = new TypeA
app.MyB = new TypeB
Later, you can close either of them safely using code such as
app.MyA.close
I forgot to say, in the code in ProjWindow that creates AddProjectWindow, you would have
dim w as New AddProjectWindow
w.projwin = self
Thanks for all the suggestions guys. I really appreciate it.
That is what I was thinking it should look like; in my mind maybe more like:
dim Story as New StoryWindow self.close projwin.close
But what was throwing me off was window.close instead of self.close. I would’ve thought window.close would be generic and would not do what was intended so it threw me off. The lack of the “code” tag working is not helping either.
I’d fiddled with the order a bit under the following presumptions.
Flapping about in the dark, I’m afraid.
The order isn’t really going to matter. Go with what makes the most sense to you. Focus won’t affect the way things close down.
Thanks Tim. Noted.
I haven’t solved this as such but I have found a solution based on a different approach to the UI logic that both negates the need to close multiple windows and provides a better UX, I think. Workarounds. Gotta love 'em.
Window(0).Close for example to close the front window.
Windows are a special kind of object beast in Xojo because they are self-retaining: As long as they are open, they keep themselves alive without you having to keep a reference to them in your app.
Using implicit instances may help in single-window or single-task-window apps, but that automatic reference can confuse heavily in multi-document apps.
So @Jeff_Tullin’s advice could become tricky in these cases and includes the risk of keeping a reference to closed windows which could result in memory leaks.
Another valid approach especially in multi-document apps is NOT to keep any reference to your windows and instead cycle through the existing windows of your app:
For q As Integer = App.WindowCount -1 Downto 0
Var w as Window = App.Window(q)
If w IsA projWin then
w.close
Exit for
End If
Next
Note that what you tried (typecasting a Window to a Window instance) could become handy here in case you want to address a certain property or method of that window subclass:
If w IsA projWin then
projwin(w).ExecuteWhateverProjWinMethod
Exit for
End IfThanks Ulrich
I prefer to tidy as I go. If the user doesn’t actually need to access a given window, I’d prefer it was closed and, next time it’s needed, I’ll write a routine to open it. That approach certainly works in the app I’m writing - although I’m sure in many situations it would be inappropriate.
I’m curious about the benefits of referring to a window by an integer, rather than a name. Assuming a disciplined approach to naming conventions (which seems pretty simple to keep on top of with Xojo), it’s unclear to me how a numerical reference differs. As I said, first time here and (implied) just dipping my toe into Xojo so I’m always willing to learn.
You can also ask why the reverse (or by its title as in AppleScript for example).
The number stands for the layer: 0 = front window, etc.
You also as you will discover in the LR that you can refer to a window by its name (Window1, wMain, …), but not by its title.
The important thing is to read the LR and conform to it.
PS: one may ask why the same word defines a color and a fruit (and it was used as a Computer Add-On Company years ago). But, who cares ?