When I have finished implementing a part of an application I usually check that the destructor gets called on each of the participating objects to be sure to not create memory leaks and not having cycling references. When I use built-in classes I check the debugger’s runtime content to see if the objects have been released from memory.
Now with programmatically created menu items I have not yet managed to get them released from memory. Closing a menu item did not work if it owned children. So I created a subclass and overrode Close to close each child:
Do Until Count = 0
Item(Count - 1).Close()
Loop
Super.Close()
Now the menu item is empty. But in the debugger’s runtime object list the menu items are all still there, one can inspect them, they are still fully configured, they are just not attached to their former parents anymore.
There are no references I’m aware of (not within the menu item subclass nor is some other object holding a reference to the menu items). The only thing I could think of preventing the release from memory is the caption for the menu item which is given as argument to the constructor.
So I created a second menu item subclass and set its caption in its standard constructor (the one which takes no arguments). And - surprisingly - this menu item instance is released from memory after calling Close.
Any ideas why a string argument in the constructor is keeping a menu item alive?