NSWindow not release memory

Question

aviorrok OP

Created Aug ’23

Replies 2

Boosts 0

Participants 2

Hi, How can I release my NSWindow manually? when the user tap on red close button?

@objc func windowWillClose() {
       // Handle the window closing event here
       // You can perform any necessary cleanup or ask the user for confirmation
       
       // Return true to allow the window to close
        _window?.contentViewController = nil
        _window?.delegate = nil
        _window = nil
        NotificationCenter.default.removeObserver(self, name: NSWindow.willCloseNotification, object: nil)
    
   }
    
    //Settings cell tap
    @objc func settingsItemClicked () {
        //_window:NSWindow?
        NotificationCenter.default.addObserver(self, selector: #selector(windowWillClose), name: NSWindow.willCloseNotification, object:_window)

        if _window?.isVisible == false {
            
            // Load the view controller from the storyboard
            let storyboard = NSStoryboard(name: "Main", bundle: nil)
            guard let ViewController = storyboard.instantiateController(withIdentifier: "SettingsViewController") as? SettingsViewController else {
                        fatalError("Unable to instantiate SettingsViewController from storyboard.")
                    }
           // _window.delegate = self
            // Set the view controller as the content view controller of the window
            _window?.contentViewController = ViewController
            _window?.isReleasedWhenClosed = false
            _window?.hidesOnDeactivate = true
                              
            // Set the window's title
            _window?.title = "DynamicLake"
            
            // Show the window
            _window?.makeKeyAndOrderFront(self)
            
            
        }else{
            print("The settings view is already open")
        }
    }

Boost

Answer 1

DTS Engineer OP

Apple

Aug ’23

The answer here depends on information you haven't shown. Is this code in a NSWindowController? If not, is it in a different object that conforms to NSWindowDelegate? Why do you set isReleasedWhenClosed to false when you actually seem to want the window to be released when closed? Why are you not setting the window delegate to a non-nil value? Why does you windowWillClose function talk about a return value that it doesn't have, and which sounds more like windowShouldClose?

In general, you should go with the default behavior, and use a NSWindowController subclass to manage the window. Additionally, when the window closes, you need to deal with any retain cycles that you've introduced, either to the window or the window controller, from a view controller or other similar object.

Usually, the most obvious retain cycle comes from the window delegate (hopefully, that should be a NSWindowController subclass), so setting the delegate to nil is a good idea. It's not usually necessary to set the view controller to nil, although it doesn't do any harm.

You also need to think about any other possible strong references to the window that may be stored elsewhere. For example, you're apparently storing a reference in a global _window, so you're correctly setting that to nil, but are there any more?

Are you really having a problem with memory management and leaks? If there's a memory leak and it's not a window reference that you can find, the next step would be to use the Allocations instrument in Instruments to investigate what's actually staying in memory and why.

0

Answer 2

DTS Engineer OP

Apple

Aug ’23

You can use a NSWindowController (or a subclass) with NSPanel, but, yes, the handling is usually a bit different. With a NSPanel, you also have the choice of never releasing the window (and it's associated controllers, delegates, views, etc) but just hiding it ("orderOut" family of APIs) since there's usually only one panel (of each type).

If you're running into either retain cycles or the opposite (crashes because a weak object reference to a deallocated object wasn't nil'ed), then the debugging steps are the same for NSPanel as for NSWindow.

In practical terms, isReleasedWhenClosed is almost never the cause of the problem. It's a self-retain of the window, and setting it true or false just changes an under-release problem into an over-release problem, or vice versa. :)

Admittedly, these problems are difficult to debug, because the timing of deallocations when a window closes is really hard to understand — there are a lot of interrelated objects, and a lot of unexpected references, leading to cascade of `deallocs.

Again, the first line of defense is setting delegate references to nil, because that's fairly easy to do, and harmless even if unnecessary. The second line of defense to to carefully examine all of your code for strong references to windows, views, and even delegate objects themselves, and to break any retain cycles they introduce. The third line of defense is to study to object allocations via Instruments.

0