Declaring new window variable automatically opens it?

OK, so let me get this straight. If I put the following code into a Method named “OpenWindow”:

Dim w as new Window1 w.ShowModal

and then put “self.hide” into a pushbutton on Window1, the window is still actually in memory after OpenWindow is finished executing. Even though Xojo cleans up the other variables, it won’t clean up “w” because the window technically hasn’t closed yet. So, I need to add “w.close” to the OpenWindow method, to ensure that “w” is closed and removed …right???

(thanks for allowing me to ask these questions!!)

Actually, I think I just answered my own question by using the WindowCount feature to check. Yes, even after the method has finished executing, the Window is still there, even if hidden, until it is officially closed. So I probably should add “w.close” to the method to ensure that the window isn’t still hanging around.

Thank you all!

[quote=205528:@Matthew Pool]OK, so let me get this straight. If I put the following code into a Method named “OpenWindow”:

Dim w as new Window1 w.ShowModal

and then put “self.hide” into a pushbutton on Window1, the window is still actually in memory after OpenWindow is finished executing. Even though Xojo cleans up the other variables, it won’t clean up “w” because the window technically hasn’t closed yet. So, I need to add “w.close” to the OpenWindow method, to ensure that “w” is closed and removed …right???

(thanks for allowing me to ask these questions!!)[/quote]

You got it. Until Close is used, the window exists.

Now, here is how I would proceed to make sure the dialog does not stay around when not needed, without systematically closing it. Instead of dimming it in code, I would add a property W as Window to Window1, show it and hide it at will. Then when Window1 closes, it is automatically destroyed.

If you have several windows, you can have W() as Window and do W.append(new Window11) to add one, and as many as you need. When Window1 is closed, all these windows will be cleaned up.

I would not be terribly worried about a few additional windows taking memory. In modern apps on usual configurations, that is usually way under the 4GB available.

I don’t think that’s correct. Closing Window1 in this case leaves the created windows behind. It only removes the references window1 held.

Keep in mind that once a window is instanciated (whether by code or via ImplicitInstance), a reference is held by the app. Once the window is closed, the app releases that reference. Windows are special that way (threads are too, they stay alive until the run event completes or the app exits).

Then all windows should be expressly closed in the window Close event. OK. Easy to do with the array of windows.

If you get to the Window.Close event, it means the window was already expressly closed elsewhere.

In cases where I want to design custom dialogs, I will often override the Show, ShowModal and ShowModalWithin methods to make them inaccessible from the outside. I will then create custom ShowModal and ShowModalWithin methods that set up the window then return a value, usually stored in a private property within the window by the OK button. The value returned can be an intrinsic type or a class.

Another time-saver is to set up a Shared Method in the window that will show a new instance of a window, then return the value. Then you can simply do something like dim v as something = MyCustomDialog.GetAnswer( myQuestion), for example.

[quote=205555:@Kem Tekinay]If you get to the Window.Close event, it means the window was already expressly closed elsewhere.

[/quote]
I think Michel was saying that any windows referred to by another window should be closed in the referring window’s close event.

I’ve used the second method Kem is talking about.
Here’s an example to clarify how it works:

(window2 is a sheet window with a property, response as boolean. GetResponse is a shared method of Window2)

[code] Shared Function GetResponse(parentWindow as window) As Boolean
dim value As Boolean
dim w as new window2

w.ShowModalWithin(parentWindow)

value=w.response
w.Close

Return value
End Function
[/code]

One benefit of this technique is that several windows can have the same sheet dialog open at once and each receive individual response values.

Indeed.

[quote]Here’s an example to clarify how it works:

(window2 is a sheet window with a property, response as boolean. GetResponse is a shared method of Window2)

[code] Shared Function GetResponse(parentWindow as window) As Boolean
dim value As Boolean
dim w as new window2

w.ShowModalWithin(parentWindow)

value=w.response
w.Close

Return value
End Function
[/code]
[/quote]

Very interesting, and that takes care of closing the window. However, as far as I understand, the OP wants to get the content of a TextField placed on the modal/sheet.

I guess the method could be modified to return a string instead of a boolean. Or return text through a ByRef in addition to the boolean.

Yes, the shared method can read the textfield before closing the window.

If there were multiple values needing to be filled in, they could be passed byref and set in the sheet before showing it, set back in the byref values before closing the sheet.

Another benefit of using byref is that you can pass “default” values. If the user cancels the dialog, the byref values can be left alone and false returned to let the calling code know not to proceed with changing anthing.

I quickly played with the method.

Just a note : I believe you wanted to write “GetResponse is a shared method of Window1”.

[quote=205568:@Michel Bujardet]Just a note : I believe you wanted to write “GetResponse is a shared method of Window1”.

[/quote]
No, it should be a shared method of the dialog window. That way it is easily reused and modified for other purposes.
:wink:

So if I understand right it should be called as ?

dim response as Boolean = Window2.Getresponse(Self, "mytext")

right. Much like the selectColor dialog