DesktopWindow's Implicit Instance should be turned off by default

DesktopWindow’s Implicit Instance should be turned off by default.
Feedback Case Number: 75697
https://tracker.xojo.com/xojoinc/xojo/-/issues/75697

Please sign on if you agree.

2 Likes

I’m inclined to disagree.

1 Like

I’ve not problem with that. However, I can think of very few reasons for it to be used and certainly not for every window. I’m not asking for the capability to be taken away, just for it to be off as a default. I’m happy to hear reasons to keep it on?

You can do that for yourself.

1 Like

properties should have more explanations. extra question symbol beside?
link to docu or more hints.

Yes, but that doesn’t help new users. Twice this week I’ve helped people caught by this trap. Me changing my machine will not help that.

In an ideal world that would be the case. It would also be a massive investment in time to add links to each and every property in the IDE inspector panel. I’m not sure that is worth the effort, or should I say there are more important things to fix.

So what is the implication for new projects if that is off by default?

People will not be able to write code like this:

// Window2 is the class name of a window.
If Window2.Visible Then
   // Do some things.
End if
// This would cause Window2 to be instantiated and shown, if Implicit instance is turned on.

If you had a global tool palet that you wanted visible at all time you could turn on Implicit Instance and have access to it quickly without the need for a global reference to it.

Sure, but what will I need to do instead? Here I have a new project, and I’ve added a few controls etc. What happens when I run it?

Presumably in the IDE I see the Window as always. Or does the IDE come up entirely blank and I have to add the window?

1 Like

i don’t think so.
it need a hover over the base propertie label, and a key to identity as example class name/ propertie.
for the xojo admins it could be easy drag and drop url link from help into propertie.
most of all properties are self explaining.

Nothing would change. New projects would still contain a window.

The main window is still instantiated for you by Xojo even if you turn off implicit instance. Part of the Application definition is the Default window.

The only thing that would change is that references like:

If Window2.visible then

would report an error.

for better understanding the “main” window in default project should be created in app open event by default.
currently its hidden in the app appearance default window propertie.

It doesn’t need to. The red highlight shows which window will be created at application startup. It is easy for new users for it to stay that way.

you know this, new users not, that was my point.
the default window is Implicit Instance as tim already mentioned.
if apps need to have a login, the trouble starts … with many questions how to do.

That’s not the focus of this request. It has nothing to do with Implicit Instance. You can do it your way by selecting “None” as the Default window.

i mean if this would be off by default, then default project should not use Implicit Instance too.
intead a default project with the use of app open event.

Has this been discussed before? I seem to recall something, years ago, as to what the benefit of the existing setting of implicit instance is. Anyone remember what that was?

The default window is not created because of Implicit Instance. Turn off implicit instance and the Default window behaviour still the same. The two things are not related in any way.

Implicit instance simply means that references to the class name cause an instance of the window to be created and (optionally) shown if one does not already exist.

Default window defines which window the Application startup code will instantiate and show for you. This happens even if Implicit instance is turned off. This is not happening because of Implicit instance.

Implicit Instance <> Default window

  • Porting VB6 code to Xojo was made easier by this setting.
  • Global floating windows are simpler to access via the class name.

Both of these things are a rare use case.