CocoaInCarbon + runModalForWindow glitch

FROM : Takashi Mochizuki
DATE : Tue Jan 22 07:10:15 2008

Hello, again,

I am sorry to repost here. If anyone have an idea, please tell me.

* I have found this is resolved under Leopard. Just Tiger could show 
this problem.

//

CocoaInCarbon integration mostly work.
But when Cocoa modal dialog over Cabon modal dialog, lower carbon 
dialog can accept window switching.

I guess this is a bug of CocoaInCarbon + runModalForWindow.

//

How do I handle this issue under Tiger?

Would you tell me any idea, if you could?

Takashi Mochizuki

On 2008/01/15, at 10:13, Takashi Mochizuki wrote:

> Hello,
> I have a problem with Cocoa-In-Carbon Integration.
>
> I am building QuickTime Component - Compressor Component, which has 
> a optional settings dialog.
> This winter, I have moved to Cocoa bundled binding based dialog, 
> using Coco-In-Carbon structure. It runs pretty well under Cocoa 
> App, But on Carbon app, I have found minor event handling problem.
>
> //
>
> Traditional QT API set uses stacking DialogManager Interfaces, thus 
> they are Dialog-over-dialog-over-dialog-o...
> When I uses Carbon nib with RunAppModalLoopForWindow(), it runs 
> over current carbon dialog, and handle event
> correctly.
>
> But When I move to Cocoa, [NSWindow runModalForWindw:], there are 
> some issues.
> Some carbon apps does hang when I show Cocoa Dialog, both window 
> does not accept any event.
>
> I have resolved this by setting higher window level in Cocoa 
> bundle, like:
>     [Dialog setLevel:NSMainMenuWindowLevel];
>     [Dialog makeKeyAndOrderFront:self];
>     int ret = [NSApp runModalForWindow:Dialog];
>     [Dialog orderOut:self];
>
> This could make my cocoa window run correctly inside carbon app, 
> but there is still one thing.
>
> Lower layer carbon dialog Does Accept window switching, but does 
> not activate. So that it could cover active cocoa dialog, (Lower 
> cocoa window still accept keybd events, so I can close it by 
> pressing esc key.)
>
> //
>
> Do you anyone have any idea for more smart implementation? I would 
> pretty appreciate to your comments.
>
> Takashi Mochizuki
>