Black wi(n)dow

Targets macOS
21

Excellent:

Window.CancelClose
  Declare Sub release Lib "Foundation" Selector "release" (receiver As Ptr)
  release(Ptr(Handle))

I can confirm this workaround fixes the problem, tested in RB2017R3, 32 and 64 bit Cocoa apps.

If you are in the habit of subclassing all Xojo classes, then this is a simple 2-line fix for your project. (Instead of using a Window class directly, I define cWindow as a subclass of Window, and then all my project Windows are set to cWindow).

22

does this “release” declare be implemented in window.cancelclose or in window.close ?

23

Better put in in close. It should only be called once on the window, preferably when it is supposed to vanish.

Now I found why I thought that the fix would not work: I tried in a a tight loop, and this does not give the system time to really do the cleanup.

24

Good point - if your window returns True from CancelClose (preventing .Close from happening) this would not be a good thing. Putting it in .Close may be safer. I just tested it, and it seems to work fine in .Close.

26

[quote=381467:@Michael Diehr]Excellent:

Window.CancelClose
  Declare Sub release Lib "Foundation" Selector "release" (receiver As Ptr)
  release(Ptr(Handle))

I can confirm this workaround fixes the problem, tested in RB2017R3, 32 and 64 bit Cocoa apps.

If you are in the habit of subclassing all Xojo classes, then this is a simple 2-line fix for your project. (Instead of using a Window class directly, I define cWindow as a subclass of Window, and then all my project Windows are set to cWindow).[/quote]

Thank you. It is just what I needed :slight_smile:

27

Yes it seems to work properly! Great !
What will happen when Xojo corrects? Will this code in .Close cause problems?

28

Yes. A Xojo window on macOS is a native NSWindow. Like Xojo, macOS uses ARC to determine if a class instance has to be kept alive. “Release” lowers the reference count by 1. Once it reaches 0, the memory of the instance is released. This way there might not be a native object behind the Xojo object anymore, which could cause a NilObjectException.

Better check for the Xojo version and increase its value in case this bug will not be fixed in the next release.
Like (if 2018r1 will contain the fix)

#If TargetMacOS And XojoVersion <= 2017.03 Declare Sub release Lib "Foundation" selector "release" (id As Integer) release Me.handle #EndIf

29

Okay, some thoughts on this.

  1. Put this code in either a subclass (like Michael) or a module, that way if it needs to be removed it easily done, rather than modifying 20 different windows (or worse forgetting 1 and then customers experience crashes).

  2. I can’t beleive that it’s as simple as Xojo forgetting to release the NSWindow; there has to be a reason as why it’s done this way? Maybe they’re using a NSWindowController or something, there’s some reason as to why the window is not being release; I’d love to know why.

  3. Manually taking control of an objects reference that you personally didn’t init or retain is a recipe for a future disaster, this is the voice of experience here.

30

I read the doc … it is not corrected in 2018r1, apparently?

31

Right. The status of 43484 is verified but not fixed and verified. So increase the version limit:

#If TargetMacOS And XojoVersion <= 2018.01 Declare Sub release Lib "Foundation" selector "release" (id As Integer) release Me.handle #EndIf

32

ok, thx