setCurrentRenderingEngine() setting lost on ~ComponentPeer()

General JUCE discussion
1

There are many circumstances where a JUCE API call will destroy the ComponentPeer and recreate it. Some examples:

  • Changing the drop shadow / alpha setting
  • Changing native title bar status
  • When the LookAndFeel is changed.

To name a few. The problem is that there is no way for the associated TopLevelWindow-derived Component to know when to reapply the setting for ComponentPeer::setCurrentRenderingEngine().

It seems to me that the choice of rendering engine should be made in the Component that has the heavyweight peer attached, rather than in the ComponentPeer, since it doesn’t survive across these calls.

2

Yes… I guess that what should happen is that when the peer has to be deleted/re-created, the code that does so should save and restore the renderer like it does for other properties. I’ll have a look at that…

3

This works! Thanks. Of course, now there’s a new problem…