Declaring new window variable automatically opens it?

Help! I’ve hit a little bit of a brick wall.

I have a document Window called “frm_Table”. Implicit instance is off.

When I run the following code from a method, the window actually pops up.

Dim f as new frm_Table

However… This doesn’t seem correct. The documentation on the Window constructor doesn’t seem to indicate that just creating a window variable will automatically open it.

I want to be able to declare f as a new frm_Table, set window/control properties, and THEN call f.show to actually open it. I guess I could set the default visible property to false and then set it to true after setting my properties, but this seems really sloppy. Is there a better way of doing this, or am I missing something??!

Thanks!

No, you are not missing anything. Creating the new window opens it and triggers its Open event. Knowing that, you just have to code around it. Practically speaking, it usually doesn’t matter since you were going to open it anyway.

New creates an new instance.

Make the window invisible in the IDE, so it does not show. And when you go f.show, it will turn visible on.

That’s not correct. Do

Dim win As Window1   // with ImplicitInstance set to false and App-DefaultWindow in the IDE set to none

… then the window will not show (and Open will not be triggered, only the constructor if you have one).

I use that fact all the time with Windows and ContainerControls. You can attached already created but lightweight “empty” instances in for example tree items for a navigation system (NSOutlineView in my case). Very handy.

Of course you can reserve a variable for the window. But you will still need to instantiate it later with new to make it appear.

I wrote: “… already created…”. What I do at the application startup is:

Navigation.Append New TreeItem(New WindowA) Navigation.Append New TreeItem(New WindowB) Navigation.Append New TreeItem(New WindowC)
The Open event will not be raised on them, but they are already instantiated.

[quote=205447:@Eli Ott]I wrote: “… already created…”. What I do at the application startup is:

Navigation.Append New TreeItem(New WindowA) Navigation.Append New TreeItem(New WindowB) Navigation.Append New TreeItem(New WindowC)
The Open event will not be raised on them, but they are already instantiated.[/quote]

We are talking Mac OS X declares, right ? Not standard Xojo code ?

Standard Xojo code.

I am sorry, but I do not see what you are doing with

Navigation.Append New TreeItem(New WindowA)

It must be evident for you, though…

Each window and each container control is handed over all necessary resources in App.Open. So they all have quite long parameter lists in their constructors. Stuff like a class instances for local settings, databases, the user, the companies (in an accounting app), etc. Every window and container control class is then already properly set up (but not yet visible) in App.Open – and I do not need one global variable nor any public variable in App. I call this my amateurish poor man’s constructor dependency injection…

All this is fine and well, but it does not explain how you avoid showing the window.

What is Navigation ? An array of windows ? An array of TreeItem ? Then, what is TreeItem ? A class ?

I am awed by your magik, but would it not be better to share the way it actually works ?

Thank you in advance.

Your correct Michel. It doesn’t work for Windows. It only works for ContainerControls (in pure Xojo code) as long as they are not embedded in a window.

I forgot that years ago I developed a window subclass, which through declares overrides the immediate opening of a window.

The code in my first post in this thread is sooo wrong (lacking the “New”) that it is embarrassing… I shouldn’t post stuff when I’m not in front of the computer where Xojo is installed.

[quote=205453:@Eli Ott]Your correct Michel. It doesn’t work for Windows. It only works for ContainerControls (in pure Xojo code).

I forgot that years ago I developed a window subclass, which through declares overrides the immediate opening of a window.[/quote]

I understand better, now. Thank you.

Thank you all for your replies! For whatever it’s worth, most of my experience is in VB, which doesn’t behave like this. If I create a new variable for a window/form, it doesn’t show until I tell it to… so this is a little frustrating!

[quote]That’s not correct. Do

Dim win As Window1   // with ImplicitInstance set to false and App-DefaultWindow in the IDE set to none

… then the window will not show (and Open will not be triggered, only the constructor if you have one).[/quote]

This doesn’t work for me. As Michel B pointed out, I still have to use “new” for it to actually work/display. If I don’t declare the variable as “new”, it throws an exception when I try to modify the properties, such as:

Dim win as Window1 w.Title = "hello world" //<-- throws a "nil object" exception!!

…Also, it looks like setting the visible property to false and then using “window.show” when I want the Window to actually appear appears to be my best bet. This seems really sloppy, but oh well.

If I may be allowed to ask one more related question: When I close a window, it seems that I can still access certain information from the window, but not other information.

So, for example, I have a very basic project, shown below, with a boolean property “dialogresult”

The code for Pushbutton1 is:

DialogResult = True Self.Close

And the code for the FileNew menuitem is:

[code] dim w as new Window1
w.ShowModal

msgbox str(w.dialogresult) //This works

if w.dialogresult = true then
msgbox w.TextField1.Text //This does not
end if

Return True
[/code]

What’s funny is that I can access the “dialogresult” property just fine (so I can tell if the user pressed “OK” or not) but trying to access the text from the TextField throws a nil object exception.

Does anyone suggest a workaround? Why do Windows seem to behave so screwy in xojo? Like my issue with creating Windows, I don’t have this problem in VB.

What you are seeing is a feature and not a bug. You closed the window but it’s not nil. Therefore you can access the properties but not the interface. On closing put the text into a property and access the text.

No so strange. You got show and hide at your disposal precisely to display windows to the user as needed.

http://documentation.xojo.com/index.php/Window.Show
http://documentation.xojo.com/index.php/Window.Hide

You got exactly the same commands in VB. https://www.hscripts.com/tutorials/vbnet/show-hide-forms.html

Incidentally, if in your button you go self.Hide instead of self.Close you will be able to get the TextField1.Text with no Nil Object Exception.

Personally, I don’t think of this as a feature nor a bug. More of an inconvenience. That just seems counterintuitive to me. I want to be able to access the interface even after it’s closed. I seems silly to create properties JUST to access information later after the window closes.

Yes, that’s actually what I’ve been doing. However… I’m a little confused. If I use self.Hide, do I still need to call Window1.Close after I’ve finished accessing the text? Is the window still being saved in memory, “hidden”? Or does Xojo automatically clean that up, with the rest of my variables?

I think maybe the confusion is with the way the window is dimmed and stored. A reference is held by the app until the window is actually closed…

dim w as window1 // w is a variable that can hold a reference to a window1 - it starts off as nil
w=new window1 // creates a new window1 and stores a reference in w

dim w as new window1 // w is a variable that is automatically populated with a new instance of window1
(If visible is set to true in the inspector, the window is shown when the instance in initialized. )

w.visible=true // makes the window visible if hidden
w.show // makes the window visible and brings it to front

w=nil // doesn’t close the window, just sets the variable to nil.

w.visible=false // makes the window hidden
w.hide //same as w.visible=false
w.close // closes and destroys the window. w is not nil, but should not be used.

A window will exist until it is closed either by the user or via code.

for example…

dim w as new window1 w=nil //the window is still open w.close //raises an exception since w is nil dim x as integer=windowcount() // x is 1 since the window is open // you can still access the window like this if windows(0) isa window1 then // yes, this is our window1 from before windows(0).close // now the window is closed and windowcount() will return 0 end if

Hope that helps.