Should I report this as a bug?

General
1

With this line of code, alone in a method:

dim w As new WinMain

Analysing the project returns this:
Unused local variables: w is an unused local variable

On one hand, it makes sense, as I don’t do anything with “w”.
But, on the other hand, this line alone makes a new window (and, without implicit instance, there’s no other way than using a variable for that).
So, “w” is both needed and unused at the same time, which I find paradoxical.

Prior making a feedback case, I’d like other opinions whether I should… :thinking:

2

It’s telling you that w is unused. And it is unused. You can turn the warning off. Why would you want to report this as a bug?

3

I can understand why you’d view this as a bug, but I imagine it would require the analysis to resolve the type to some sort of exception for the window class. I don’t know if they have a system currently in place for that, but it’s correct either way you look at it and I doubt it would be addressed to anyone’s satisfaction.

4

You could probably split your new window instantiation lines to get rid of the warning:

var w as WinMain
w = new WinMain
5

This is what one hand says, as per my original question.
The other hand tells w is used, as it serves the purpose of creating the window.

I second this. It’s ambiguous in both way.

Granted, but I still prefer the warning (shown only when analyzing) than the “ugly” two lines version.

Thank you for your advices; I won’t report it.

1 Like
6

If you don’t want the warning, just use

Call New WinMain
3 Likes
7

Yes, this both keeps all in one line and avoids unnecessary variables.
I didn’t think about it, but a constructor is indeed a method (in Xojo at least), so this explains it works.

Thank you.

8

Wouldn’t Call discard a returned reference from the Constructor in such way that the Destructor of that object should be fired right after?

If @Arnaud_N wants to keep such object “alive” (like a window), probably he needs to hold such reference for the time he wants it existing, like in an app property, that will be auto released at the app ending time and that “window” closed.

9

Code such as:

Sub Something
dim w as new MyWindow
End Sub

… shows that the window is still existing, even after the sub (where “w” is no longer accessible). One can access the window’s instance using the Window() function.

That’s because Xojo holds all windows’ reference internally.

10

Weird. Unusual, and I haven’t read it in the manual. Is it there?

11

If you allow ImplicitInstance on a window and, while the window is not yet shown, you call something on it (e.g MyImplicitWindow.Show), that’s the same thing: you don’t have any variable at all, visible in your code, holding that window.

Application.WindowCount and Application.Window() also rely on this.

I couldn’t find a reference to it in the LR or user’s guide. I bet it’s implicit.

12

It’s unusual, so it must be explicited in the LR or can induce someone to error.

13

Full agreement. I remember going to great lengths when I learnt Xojo, building more or less complicated and leaky references to windows when in reality none were needed because windows are self-referencing. Any class doing so (shell?) should say so in the docs, because this is somewhat an exception to normal OOP behaviour.
Any feedback ticket written?

1 Like
14

Or waiting for a self destruction that never will come after a var goes out of scope or such, worse if such windows are in an invisible state.

Not aware of, not from me. :slight_smile:

15

It’s mentioned here:

3 Likes
16

How many window(s) does it display ?

17

Not the pointed problem, what is mentioned is another thing.

And I don’t see any mention about the behavior of locking instances without releasing them here , just about the auto-creation behavior when that shared property is set:
https://documentation.xojo.com/api/deprecated/window.html#window-implicitinstance

Also here, Windows — Xojo documentation

This also just talk about implicit creation, not about the “no destruction” behavior of the class, even those not set as implicit creation. They need more details about the Xojo internal engine that captures those references, and because of that, even with their references been freed, like going out of scope, those objects (windows) will be unexpectedly kept alive and not destructed.

Also, such details must be present in the most important part, the Class itself: Window — Xojo documentation

I think that Paul did a fast reading, missing details of the discussion, and missed the point because of reading Arnaud’s keyword “implicit”. :wink:

1 Like