I have discovered a behavior in NSView that is unwanted. It does not seem to be a "bug", I'm just doing something that was not envisioned by the designer of layerBacking. and I'm trying to determine the best way to work around it.
in the design, my NSView subclass needs to be able to host ui that is both based completely on CALayer, or NSViews. in english: I need to be able to load IB hierarchies, or CALayer hierarchies, into a single NSView, at will.
for this, I have a system that presumed that I could set the "wantsLayer" bool in the View class to remove layer backing.
true for when I'm using layers
false for when I just want to use a view hierarchy.
I have discovered that I can set it to true only 1 time. the very next time I set wantsLayer to true, there is no layer Backing applied to the the view. In other words, there is no layer instance found at NSViewInstance.layer?
In the past I have experienced that you can seriously mess up a View by setting it's layer, and I had an elaborate approach to handling the View's layer when switching between layer-backing and not layer-backing: I would store the original backing layer, and replace it with a new one, while I was working directly with Layers, and as I was turning Off layerBacking, I would just replace that layer with the original layer.
I've done some refactoring, and in place of that elaborate setup, I've just changed the way I handle layers. I no longer ****** the View's layer, except to add a single layer to it's sublayers, that I can then change as necessary. eventually removing that single sublayer, leaving the view's layer as I found it. This is not currently working.
So I'm here asking the question: what are the best practices for avoiding damage to the NSView classes handlig of layerBacking so that you can turn layerbacking on and off at will?