How to Manage Windows that are NOT implicit instances?

[Craig_Boyd]

Hi All,

I searched around in the Example Projects, but I did not see what I was looking for.
Is there a good example of using and managing Desktop Windows that are NOT implicit instances?

Thanks.

[Ivan_Tellez]

@Craig_Boyd

using and managing Desktop Windows that are NOT implicit instances?

Just store a reference to the window and you can use or close them with that variable:

'Store a variable that dont go out of scope 
'(for example in the app object)
w as MyWindow

'Create a new instance and use the window
App.w = New MyWindow
App.w.show

'To close
App.w.close
App.w = Nil

[Craig_Boyd]

Thanks for the reply on a Saturday night Ivan!

I have figured that very little bit out and I know that the App object stores a count of instantiated windows.
I should have asked my question differently.

In a large application, say 40 or 50 potential windows are there any tricks to managing them? Or is it all just a matter of managing the opening and closing in an orderly fashion?

And also checking to see if a particular Window is already open if you don’t want multiple copies of the same one floating around?

Any best practices around managing them?

Thanks!

[Gilles_Plante]

With that many windows, you do not want to display all of them. You can hide a window using .hide, for example:

App.w3 = New myWindow3
...
App.w3.Hide

I suggest closing the windows as soon as they not required anymore, this way freeing some memory.

[Craig_Boyd]

Thanks for the reply Gilles!

If they are hidden and I update a listbox on them will that unhide them or bring them to the forefront?
Or do they simply remain hidden until Show them?

[Jeff_Tullin]

@Craig_Boyd

In a large application, say 40 or 50 potential windows are there any tricks to managing them? Or is it all just a matter of managing the opening and closing in an orderly fashion?

And also checking to see if a particular Window is already open if you don’t want multiple copies of the same one floating around?

40 or 50 sounds like an unworkable UI for the user.
Depending upon what they do, you might also hit memory problems.
Closing …will happen automatically when you close your app, but if they ‘keep unsaved data until closed’, then sooner or later a crash will lose someones work in progress, so save regularly.

One way to keep track of them is to have an array or some properties in a module.
For example, I may have 3 document windows open, one preferences window, one export window…
I have an array in a module:

MyDocWindows() as DocWindow
and I add them to that when I create a new one. At any time I can loop through the array, and test for nil, while possibly setting them all to a new size, background color, or updating their data from a central core.

I only want one preferences window, and I want implicit turned off, so I have a property
MyPreferencesWindow as PrefsWindow

When I need a prefs window, I use

if MyPreferencesWindow = nil then
MyPreferencesWindow = new PrefsWindow
end if
MyPreferencesWindow.show

But remember that the app has an array of Windows references anyway… you can iterate through that but you check the type of each one, and cast it in order to address its properties.

[Jean-Yves_Pochez]

Hi Graig,
you could have some palette floating window with buttons that open each window ?

)

[MarkusR]

@Craig_Boyd

In a large application, say 40 or 50 potential windows are there any tricks to managing them?

some apps have a menu windows where all open windows appear.
i would allow multiple windows so the user can compare data from detail views but maybe limit the count
of open ones with same kind, or close the oldes one with no user input.

[Gilles_Plante]

They remain hidden until showed by code that calls .Show.

[Thom_McGrath]

Consider going spelunking through GitHub - thommcgrath/Beacon: An editor for the beacons in Ark: Survival Evolved if you want real-world code that doesn’t use implicit instances. If I have any at all, I’d be surprised. But generally, like others have said, you just keep references in a variable. Like my MainWindow instance is a property on App, accessible via at method. It ends up working largely the same, but I gain a little more control over when it exists and doesn’t.

[Craig_Boyd]

Hi everyone, thanks for the replies! I was away from my computer all day yesterday so I was unable to respond.
@Jeff_Tullin ~ it is not that big at the moment, but I expect it to grow to that size over the next year or so. Thanks for that snippet of code for the preferences window. That makes a lot of sense.
@Jean-Yves_Pochez ~ Yeah, I remember seeing that and I think I want to do that or maybe a tree view in a floating window like that that would allow folks to navigate which part of the application they need to be in.
@MarkusR ~ You are right about that. There will be some windows, like Jeff’s preferences window that I would want to restrict, but others I would not mind duplicates open for that very reason.
@Gilles_Plante ~ thanks for the clarification!
@Thom_McGrath ~ thanks for the link, I will check that out and thanks for pointing me to a particular part of the code. I just took a quick quick glance the repository and it is of respectable size.