Value in Xojo App changes when window-close is called, but I don't understand, why

1

Hello,

I have a fairly large Xojo app that has always worked fine until recently. I believe the last version I edited was with 2025r1 (possibly 2025r2). Now (using 2025r2.1 – though I’m not sure if the version is the cause) something suddenly stopped working.

A value that never caused any issues before now completely hides a View.

I’ve spent almost three days debugging, just trying to understand what’s happening, but I can’t find any real clue.

I then tried to reproduce the issue in a new, minimal project – but there the bug does not occur.

So I started stripping down my original project, removing code and features piece by piece until the issue disappeared.

The result: my test project and the stripped-down version of my original project look almost identical. However, in one the bug occurs, and in the other it doesn’t.

here is what actually happens vs. what should happen:

I have a Button that simply calls Window.Close on another window.

Inside that window there are two containers (I’m not sure if the containers are relevant for the bug).

The inner container has a computed property. In one project, the property’s setter suddenly gets called with value = 0. I have no idea what triggers this behavior. I also can’t see where the value 0 even comes from.

In another (very similar) project, this does not happen at all. I tried to reproduce the behavior from scratch in a minimal test project, but there it works fine and I cannot reproduce the issue.

So in short:

  • One project → the computed property setter is unexpectedly called with 0 when closing the window.

  • The test project (almost identical) → works fine, no unexpected setter call.

I may be overlooking something very obvious here, but I just can’t see it.

I’ve attached both projects for comparison.

Maybe someone can spot what I am missing?

Thanks!

original

test

2

Implicit instance strikes again

In your main window when you press the button there is NO instance of WindowBuchen in existence yet
So the First thing that happens, because of the Implicit instance settings, is that an instance is created
The creation causes the computed property top be set - with a 0 value
Now that the Window is created the call to Close can be completed successfully

If you put a break point in the Button event & the setter for your computed property you can actually see this happening

when you stop at the call to Close - before it has executed you can see there is only one Window
if you step in you can watch WindowBuchen get created - and the call to your property setter happen

https://www.great-white-software.com/misc/Screen%20Recording%202025-09-28%20at%2011.22.10%20AM.mov

In my personal projects I turn IMPLICIT INSTANCE OFF
every time

Then I have a method that can find me an existing instance of a specific window
if it finds one I can deal with it
If it doesn’t one is NOT created and the code that might close the window or whatever is simply not run

EDIT : I have blogged & posted about this before

2 Likes
3

Hi Norman,

Thank you for these information. Ok, perhaps this is a part of the problem - I#m to tired to really think about it - why doe that work for years and occur now with the new Xojo Version?
Why doesn’t reproduce the second project this behaviour? It does exactly the same, but there is no call to the setter with “0”.

And, normally I set the default value of the private value behind the computed property. Why should the Instance call the setter with “0”, so the default value is overwritten?!?

Marius

4

It should ALWAYS have been an issue IF that window was not open beforehand
if it was then there wouldnt have been an issue

when a window is created ALL properties have values set by default

most you never notice because they arent computed ones

but when they are you get this behaviour - every property is set

I didn’t look into the second one - just your first example

Let me do that & I’ll get back to you with an edit to this post

EDIT : FWIW the computed property on the container does the exact same in the test app

https://www.great-white-software.com/misc/Screen%20Recording%202025-09-28%20at%2012.21.16%20PM.mov

1 Like
5

I think we may be talking about different things (since the links to the videos are broken, I couldn’t check if this is the case). But I’ve done this thousands of times and it has worked for years. Also, this test project doesn’t show the issue on my system.

I’m familiar with implicit instances and I’ve been using them by default since I started working with Xojo. But I don’t think that’s the problem here.

Does the breakpoint in the test project fire at any point for you? On my system it doesn’t, and that’s exactly the way it has always worked for me over the years.

6

Ok, I finally managed to view the videos by editing the URL. This is really crazy!

First of all: I have used computed properties a million times in my “Xojo life”. My pattern has always been to set the default value on the private backing property, like this:

Private Property mtest As double = 2

Public Property test As double
Get
  Return mtest
End Get

Set
  mtest = value
End Set

End Property

As a result, if I haven’t manually overwritten the value, then after opening, the value should be “2”. But now, somehow, a “0” appears magically from nowhere.

Here is my version of your video using my test project:

If I’m not completely mistaken, the exact same project behaves differently on my system! And this is exactly the way it has been working for many years. I’ve always done it like this.

Why? Why is this different now? Why did this work on my system for decades?

And most importantly: how is it even possible to set a default value for a computed property if the private property is immediately overwritten by the computed property setter being called with arbitrary values?

Do I really have do do something like:

Static FristRun as Boolean = true

if not FirstRun then
...
end if

FirstRun = False
7

Ok, if found two different things:

  • This problem occours after you save the project and reopen it. It does NOT, before you save it the first time.

- The Problem does not occour, when you do it directly on the window-instance. it occours only on the container that is intanciated on the window

8

Fixed the links

And yes I hit the break points in the tests

9

I have no idea why this might be new on your end
It should ALWAYS have done this

And yes, for a default for a computed property you often do need to skip one of the first initializations

I tend to use the OPEN event and at the end of it simply put

hasOpened = True

Then in the computed property setter I have, as the very first thing,

if not hasOpened 
   return
end if

EDIT : saved or unsaved really shouldnt have any effect on the behaviour

If it does then that really seems like a serious bug

10

Window Implicit Instances have caused so many subtle bugs in my 25+ years of Xojo experience that I almost always turn them off. There are times when they are handy but mostly they just cause weird stuff like this to happen. IMO, it’s just easier to turn them off and deal with the instances.

2 Likes
11

You saw, that this only happens to computed Properties on containers and NOT e.g. on Windows.
You saw, that this only happens to projects that have been saved and reopened, it does NOT happen to new projects before they are saved.

You mean, this is an wanted behaviour? I’m not sure if I’m dreaming right now, but in my world this is an extremely nasty bug.

12

The bug is that it behaves differently when unsaved vs saved

THAT should be reported - although I’m sure you’ll get asked for a sample project which is funny as hell since saving changes the behaviour :stuck_out_tongue:

I’m unsurprised you’re seeing this

That you’ve not run into it before is, to me, surprising as heck
Its why I have a default project template that disables implicit instances entirely and I have code to find the instances at runtime when I have created them

The upshot is now you know whats causing it and you can deal with it

1 Like
13

I’ve been using implicit instances for many, many years and I actually don’t think they’re bad at all.

Ultimately, this may be a side effect of implicit instances, but the fact that a computed property in a container within a window is affected — and only after saving — while a computed property directly on the window is never affected, shows in my view that this behavior is not intended. It also makes little sense for computed properties to behave differently in different objects. The behavior should be the same in a window as it is in a container.

The most important thing is, this is a bug and not my fault. hate it when I realize after some time: Damn, I made a mistake there.

As the Xojo Issues Tracker often feels like reporting bugs straight to /dev/null, I stopped creating bug reports there — nobody at Xojo seems to want them.

Until I stopped posting in the forum, I shared my findings there. Now I send these reports via email. They can do whatever they want with them: fix the bug, open an issue and then ignore it, or just ignore the email directly.

Either way, my license will expire in November, and I’m not even sure I’ll get 2025r3. It would have to be a really major feature release to convince me to renew. Otherwise, I might wait one or two years until I’ve saved up and can pay what I believe the product is actually worth — assuming Xojo still exists by then. I actually like Xojo, and at the moment there’s no other IDE I could really live with besides it. But as long as nobody at Xojo seems to care about me as a developer, I’ve lost the motivation to keep throwing money at it.

14

I’ve found more bugs in Xojo than in the forests around my home, but implicit instances have always been robust and reliable. In over 20 years, I’ve never had any problems with them.

15

As the former engineer that wrote the code that gets compiled I can tell you setting every property WAS intended
If they weren’t set then the generated code simply would not compile

So I’m surprised you havent run into this before now

I can say even the IDE, which I worked on for 10+ years, experienced this in some places and we took such steps to avoid issues

Whether that code still exists in the way I last worked on it I cant say - its been years since I worked on it

Either way, my license will expire in November, and I’m not even sure I’ll get 2025r3.

I have seen where they are expecting that 2025r3 will be the last one for the year
They have some huge issues to tackle especially with macOS & iOS requiring certainSDK’s to be used

Trust me you’re far from alone feeling this way
They’ve made it very clear that chasing new customers is much more in their wheel house than trying to retain existing one
Which truly saddens me

16

Which is dumb. You’d think it would cost more to get a new customer than to keep an existing customers. Shoot, look at how many people practically beg Xojo to fix bugs so that they don’t have to move on. And how many developers, including myself, just paid the renewal every year ‘just because’. And a new customer will typically be the cheapest license possible whereas most of us here had Pro licenses.

But not my company to drive into the ground. As we’ve said many times in the past 20+ years, WTF do we know?

2 Likes
17

Everything I’ve ever seen about marketing has said it costs way less to retain customers than to chase new ones

But .. wtf do I know :man_shrugging: I’m “just a coder” or so I’ve been told more than once

A good number of the folks here I suspect

2 Likes
18

Related issue here: https://tracker.xojo.com/xojoinc/xojo/-/issues/78197

1 Like