but for sure it is a Implicit Instance because you can access the window (or a button inside) by class name.
its more this window propertie get ignored by xojo.
Not if implicit instance is turned off. Add a new project, turn off implicit instance. The project works exactly like it did before. Nothing has changed, except that you cannot access a window by a class name.
You can access the default window by class name with implicit instance turn on, since the implicit instance does not create a new window if one already exists.
Here is a wayback machine page from Bob Keeney, about how Implicit Instance is evil:
Consider the following code (from Bob):
Window1.close // Close the window
If Window1 <> nil then
// Window is open. WTF! I just closed it!
End
heh. I was just going to mention this.
8 years later and it’s still the default. I doubt Xojo will change this behavior.
1 Like
I, too, doubt we’ll see a change in the behavior. It was the CEO himself who pushed to move the switch to the harder-to-find location on the Advanced tab.
At best, you’ll get a recommendation to use the control templates to set up defaults the way you like.
Anyone in favour please give the bug report a thumbs up (on the bug case, not on the forum). Thanks
I’m completely against a “DesktopWindow’s Implicit Instance should be turned off by default”
But I’m completely in favor of a preference allowing the dev set a “Window auto-instantiation default: ON/OFF” so every new Window created will assume the value of its “implicit instance” from this setting.
So, any new user will have it ON, and as today, every new window will have its implicit instance ON. But once the dev change this preference to OFF, every new window will have it OFF as you desired.
So this behavior will be dynamic, affecting only new windows, and this DEFAULT can be changed at any time.
The regular new user would suffer if your desire could be implemented.
And my suggestion must be considered an advanced option.
2 Likes
That is an opinion that I’ve no problem with. Nothing in my request asks to take away options from users. Only that the ‘standard’ setting be off. We’ve had at least two example in the last week alone showing how this setting is causing users confusion and problems. The first with magically appearing windows and a later one discussing scope.
I’ve also not asked for any existing project to change.
Having a setting is all well and good, however, the users are suffering now, they just don’t know it.
Feel free to give the feature request a thumbs down.
This will make newcomers see the following:
A window to be designed will pop up in front of him, he will add a label, a button, and will run to experiment this unknown new IDE. The result? It won’t work, disappointment.
If people today have some kind of problem with the current behavior, and committed some beginner mistakes, they can fix it easily using different approaches.
But having a default value selectable, solves all scenarios, and demands an entire page in the docs specially about how to handle Windows with the such advanced option “OFF”, and explaining the side effects of it “ON”.
2 Likes
What won’t work? Are you saying that the Window won’t show. That is incorrect. It is a complete misunderstanding about what implicit instance does. Create a new project. Click on the Window it provides turn implicit instance off on the cog tab. Run the project. It will be exactly the same as it was with implicit instance turned on.
Implicit instance <> Default window.
No additional code would be required to make a window show if implicit instance wa turned off. Try it and prove it to your self.
To prevent the window from opening at startup of the application would be madness. It is not something I am suggesting.
I’ve tried and saw the inconsistency, so Xojo opted to let an implicit instantiation of the pointed Default Window, instead of simply marking the Default Window to NONE as no implicit creatable one should be listed.
So the problem will be postponed to the second Window.
What second window is that? Are you talking about opening a second window. That would require code, typically it would look like this:
var oWindow as New Window2
oWindow.Show
That does not change with implicit instance off. The only thing you couldn’t do is:
Window2.Show
Which I’m completely happy to not support.
Default window is not an implicit instance. There is code in the app startup that instantiates a window of that class and shows it. That that happens has nothing to do with implicit instance, as can clearly be seen by turning it off for Window1 (or any other default window).
And what will happen to users that add a new Window (say Window2), now the Instance is Off and they usually do
Window2.Show
now will get:
My guess, this will affect more users than the problems they find with having the Instance On.
I use ~/Documents/Xojo/Overrides/DesktopWindow.defaults and inside that text file I have (among other things):
ImplicitInstance=False
3 Likes
That error message needs to be fixed.
That beginners will expect being just
Window2.Show
Not here. I see zero App Events with code in a new project, and the instantiation occurring implicitly behind the scenes.
It is built into the framework. You can’t see any code with Window1.show either.
That code is grossly wrong it is not even how VB6 worked. I don’t understand why anyone would expect it to work.
That’s called implicit instantiation, in opposition to explicit.
In what language?
It is how they all are used to, as:
VB6, as I said earlier. If that is wrong then I apologise, but I don’t see benefit in compounding an error.
Wow, easy as cake. All we need is exposing this option to the preferences interface.
1 Like