[wxMac] non-compositing windows and other, was RE: broken after upgrade to 2.8

[Chad Wagner]

On Apr 28, 2007, at 12:00 AM, Stefan Csomor wrote:

> Hi Chad
>
> sorry for replying so late, but I only saw from your patches what was
> happening (thanks ;-) - if you post something dealing with mac please
> add wxMac to the subject line or add me directly as a cc, there  
> will be
> many times where I just cannot read every post
>
>> Problem 1:  some (most?) apps that I use to test my plugin are giving
>> me a non-compositing window, but it seems that support for non-
>> compositing windows has been entirely removed from wxWidgets as of
>> 2.8.  Is there a fundamental reason for that, or is it just because
>> it was assumed that no one would ever use a non-compositing window
>> (and indeed, why would I, if I were creating the window myself?) and
>> the "unnecessary" code was removed?  If it's not hurting anything
>> else, I can submit patches to put it back in...
>
> yes, it was done to reduce code, we have to come back to a reasonable
> number of source lines, it just is getting too much too handle for  
> me as
> a non-paid 'hobby' ... I honestly didn't think of your specific
> situation of being 'embedded'. I'll scan through your patch and report

alternatively, do you know of a way to take the non-compositing  
window provided by my host app and somehow turn it into a compositing  
window?  if that's possible, that would also solve it.

>> Problem 2:  in the Dispose method for wxMacControl, ::DisposeControl
>> was replaced by ::CFRelease.  The problem there is that one app (and
>> there may be others out there) seems to dispose the root control
>> before calling my close method, and the subsequent CFRelease on an
>> already-released reference gives me a runtime error (after the failed
>> IsValidControlHandle assertion immediately before it), whereas
>> DisposeControl did not.  I would consider this a problem with the
>> host app, but I don't want it to break my code (the user will blame
>> my plugin, not the host).  I don't understand the reason to use
>> CFRelease rather than DisposeControl, and the simplest solution I can
>> see to my problem is to switch it back, or conditionally call
>> CFRelease depending on the result of IsValidControlHandle rather than
>> asserting it.  Does anyone see a potential problem with that?
>
> no technically not, I wanted to make sure that we don't have leaks nor
> double deletes (which might happen now that I have native controls in
> native toolbars), are you setting the sm_isEmbedded member on wxApp ?
> I'd still like to have the full assert for non-embedded situations

okay, great -- the patch (which you already applied, but in case  
others are following this) leaves in the assert, so it will still  
catch leaks and/or double deletes, only now it won't crash ;-p.  and  
yes, I do set the sm_isEmbedded flag, but wasn't sure it actually did  
anything other than the application event handling.