Get pointer to 1st window

If I open up a new window when the app first runs, as in:

Var WT As New Window_Tasks

And I open up a second window from Window_Tasks, say as a modal. How do I refer back to the original window from the modal, if I want to change a property in Window_Tasks, for example - such as a label’s text?

You can pass the calling window as a parameter to the modal window.

In the calling window, use

var WT as new Window_Tasks (self)

Add a property callingWindow as window to Window_Tasks and add the constructor method:

Public Sub constructor(caller as Window) callingWindow = caller // Calling the overridden superclass constructor. Super.Constructor End Sub

Now you can reference the calling window through the property.

Note - untested code

Okay, thanks Tanner.

Don’t forget to add a destructor method to nil the callingwindow reference or you’ll leak memory.

You could achieve this by adding event definitions to the modal window that are handled in the calling window or shadow the showmodal method and return a value both of which I think are a better solution.

Also have a look at Examples->Desktop->Windows->ModalWindowExample.

i used it this way so the opened window dialog is neutral.
var win as new ModalWindow
win.Init
win.ShowModal … .Hide there
Label1.Value = win.Result
win.Close

without modal you would use Events.

Edited to use weakref so you can’t leak memory

[quote=469469:@Tanner Lee]You can pass the calling window as a parameter to the modal window.

In the calling window, use

var WT as new Window_Tasks (self)

Add a property callingWindow as WeakRef to Window_Tasks and add the constructor method:

Public Sub constructor(caller as Window) callingWindow = New WeakRef(caller) // Calling the overridden superclass constructor. Super.Constructor End Sub

Now you can reference the calling window through the property.

Note - untested code[/quote]

Now you don’t need to nil, and you won’t have memory leaks.
In the window_Tasks you’d check to see if the weakref not is nil like so:

If callingWindow <> Nil and CallingWindow.value <> Nil Then

// do some code
End If

Wayne, I’ll look at the example. Thanks - and thanks everyone. Very helpful insights.

This raises a question, how would one know calling the constructor would cause a memory leak (other than unhappy experience)?