If a subclassed control holds a reference to an object and the window holding the control is closed, does the subclassed control lose its reference to the object. I assume this is the case and I don’t need to manually remove the references in the close event to prevent memory leakage.
I would believe that the instance being destroyed, it would indeed lose the reference. Unless the reference precisely prevents its destruction.
That certainly happens if you keep a reference to that control somewhere. The window is destroyed, but not the instance of the control. Seems illogical, yet I just verified it.
Why does that seem illogical? A control is just an object, like everything else. If you keep a reference, you can access its properties, much the same way you can get the properties of a window after it has closed (provided you keep a reference to it).
controls get destroyed in Close event of Window.
Sometimes I run into situation where I have somewhere a reference to control or window and the actual window is destroyed already. So better use Weak References for those.
I too thought that since a window closing destroys all instances. But I just tested today having a property reference a control instance on a window, then close that window, and afterward, I was still able to get the properties of that control, which means it still existed.
Indeed WeakRef would prevent it from staying around.
[quote=252528:@Michel Bujardet]I too thought that since a window closing destroys all instances. But I just tested today having a property reference a control instance on a window, then close that window, and afterward, I was still able to get the properties of that control, which means it still existed.
Indeed WeakRef would prevent it from staying around.[/quote]
Did your window have ImplicitInstance=true? If so, then you simply created a new instance of the window when you get the property of it. Accessing ANY of it’s properties or methods will create a new instance of that window if it’s not already open.
Windows are the only ‘special’ object like this. This is an insidious and evil property that leads to subtle and hard to find bugs because people don’t think of Windows as being an object. I tend to set ImplicitInstance=false to avoid this.
Of course not. I created the new instance of the window explicitly precisely to avoid implicit instanciation.
You are right, it is indeed possible to create a non visible instance of a control as a property or variable. What is interesting here is that normally the window closing destroys all instances of controls it contains, so one would imagine it to be the case, but keeping a reference to it prevents it from being destroyed.
That was following Stephen’s question.
You are safe if you just hide a window, read its content and then really close it.
You cannot say for sure how long a closed window will live as long as you dont reference it somewhere else. Sometimes you may still access its properties, sometimes it may already be gone. It depends on the system and when the next ARC release cycle runs.*
- All just based on observation, please take it as a theory which may be bashed by Norman or Joe
I see that as perfectly fine behavior. Like any object, a window goes out of scope when there is no reference to it anymore (its ARC is 0). As long as the window is opened, it is part of the screen view hierarchy, in other words a subview of it, so the screen references it. When you close it, it gets kicked out of the screen hierarchy. When theres another reference to it, its ARC is still higher than 0. So it does not fade away and you could still show it again or address its contents safely.
But it doesn’t destroy them. It releases its references to them and they are destroyed if there are no other references.
When the count goes to zero, destruction is immediate. There is no “release cycle”.
Basically absolutely right. But I had situations where I was addressing a closed object accidentally and could do so while when I did this in debug steps I got a NilException. Maybe this had to do with some memory leak or whatever (and I cannot describe the exact situation, I remember in one case it was a declared object I forgot to retain that was probably lasting until the autorelease pool it was connected to fired). In any case, you surely shouldnt
Stephen, I verified that if you keep a reference to an object (I used a Timer) that was placed on another window, when that window closes, the object remains.
So either use a weakRef that will automatically become nil as the object is destroyed, or make sure to nil the reference before you close the window.
If you can address it, the count isn’t zero. 
Closed <> Destructed. You can use this to your advantage. Or you can trip over it and get blown up.
But we’ve gone far afield of the original question. Yes, under normal circumstances, everything is cleaned up for you. It’s only when you start holding multiple references to the same object that you have any variability.
Tim is exactly right.
An important distinction is that Closing a window does NOT necessarily destroy it. It will live as long as anything has a reference to that window. So just because the window visually closes does NOT necessarily mean that the window object was destroyed.
I think an object placed on another window will have its own reference that keeps it alive. I was more thinking of an object like an instance of a custom class.
So closing a window, even if there are other references to it, will call the destructor for any child controls and decrease the reference to the child controls, right? The window doesn’t need to have its references to it = 0 to clean up child controls.
Nothing replaces actually testing an hypothesis. It is not that difficult.
[quote=253229:@Stephen Dodd]So closing a window, even if there are other references to it, will call the destructor for any child controls and decrease the reference to the child controls, right?
[/quote]
Almost. Window Close will call Close on its child controls and release its references to them. IF there are no other references to the controls (normally, there are not), they will be destructed and release any references to objects that they might hold. IF there are no other references to those objects, they too will be destructed.
Correct.
You just have to validate that you are testing what you think you are testing
Indeed. That is valid for any test.