Look. You all are arguing about behavior that isn’t going to change.
I’ve believed for a very long time there should be no implicit instance because it leads to subtle errors and major confusion from users in some circumstances. I feel that’s always bad. However, Xojo feels that implicit instance is ‘a good thing’ so it’s staying.
My reasoning is this:
If you were to use a DateTime object and you did this: Var d as DateTime
and then attempted to do anything with d you would get an immediate nil object exception. Since the beginning of DateTime you had to initialize it some way such as: Var d As DateTime = DateTime.Now or Var d As DateTime = new DateTime( anotherDate )
Why is window different? Why is it special? It’s still an object. And you can still new a window regardless of implicit instance. So why have this one thing be different than the rest of the ENTIRE framework? It’s only because Xojo wants it so and it’s been like that since I started 20+ years ago. It’s staying in.
In the past I argued about it, and someone said “A Window in Xojo is a different kind of animal…”, I guess that behind the scenes there are more things than we should expect about “this special kind of” object.
I guess this differentiation comes from some decision from the past, and maybe it is unique to Xojo.
But Xojo does not think it‘s a good thing, from their documenation:
To avoid these limitations, you can disable implicit window instances for a window by turning the Implicit Instance property to OFF in the Inspector for the window. As this behavior is preferred, Implicit Instance will default to OFF in a future version of Xojo.
As I’ve said, I’m not trying to remove the option or change the way people that know what they’re doing work. Simply to help people in your lower two cases from shooting themselves in the foot.
The moment that accessing things by name becomes a massive problem is if you have a document editing application that allows more than one window. At that point access via name is going to fall appart as you could have two of almost any window open at once. Class name isn’t going to work at that point.
The really nice thing about Xojo is it is really really easy to extend your application to work with more than one window of the same type at a time, but you really are going to have a very hard time if you use Class names.
You’re fighting an un-winnable battle. Since very early on Xojo has wanted a brand new user to be able to start a project, press Run and have an application with a window appear with no coding required. The only way to do that is with implicit instances.
He didn’t write “add another window” or something to that effect. We don’t know what he really meant. I know about Window2.Show as I posted that screenshot in this thread before.
As a new user, I can download Xojo, create a Desktop project, add buttons and other controls to the window that Xojo is showing, hit Run and it will show the Window with the controls with 0 code added, even if implicit instance for the Window is off. As mentioned before here.
He said:
and you are saying:
How a new user is not used to do something if he is talking about ‘brand new’ user?
Not all new users are coming from VB. I don’t know if some, many or most, used VB before (at this point, I guess the ratio was bigger 5, 10 years ago).
Anyway, I’m asking Greg what he means and not what you think he means. Thanks.
Sorry, but it does work without implicit instance turned on. All that would be required is for the standard app initialisation code to include
// pseudocode
if DefaultWindow <> none then
oWindow = New (DefaultWindow)
oWindow.Show()
end if
// rather than
if DefaultWindow <> none then
(DefaultWindow).Show()
end if
It does not require implicit instance to occur. It works for window that it is turned off for. Why would that change if the default was changed. You certainly know better than me what is hidden in the Framework at the present time, but there is certainly no reason it couldn’t be handled in an explicit way, still with zero code.
As Thomas has pointed out the Documentation states:
To avoid these limitations, you can disable implicit window instances for a window by turning the Implicit Instance property to OFF in the Inspector for the window. As this behavior is preferred, Implicit Instance will default to OFF in a future version of Xojo. Windows — Xojo documentation
Which explicitly states that they wish to change it to OFF (their emphasis not mine) in a future version.
So I think you’ll find that the Window that is set as the default window automagically has its Implicit Instance property set back to true for the compiled app. You can test that by adding a button to the window and writing the code Window1.show. if it were not an implicit instance, you’d get a compile error.
So yes, you could turn off implicit instance and still get Window1 to work, but it would still be confusing for that same new user when Window2 and Window3 didn’t work the same way.
Just to be clear, when I worked there, I argued for this same change several times because in my opinion, it allows for lazy programming practices that require a huge refactor later. But if Xojo wants to be a learning platform forever, I’m afraid that Implicit Instance is here to stay.
Now, what Xojo could do would be to make it a preference for new projects which defaults to True. When the user reaches a point when they want it to be off by default, then it’s off, there’s no more automagic code being run and you’d need to finish the App.Open event with:
Dim w as new Window1
w.show
I could even imagine a Shared Method on each Window class that works like this:
Shared Function Show()
dim w as new Window1
w.show
Return w
End Function
Which (except for the return value) would be the exact same behavior. A possible problem would be that the compiler might not be able to figure out which one to call from within the class if it needed to.
