On Sep 28, 2009, at 2:41 PM, Christopher Deckers wrote: I suspect they are. SWT_AWT has a lot in common with the Browser
implementation, and I don't transfer focus to the embedded shell's
content when the shell gets 'focus'.
Is it something you are planning to work on? Should we open a bug to track this?
If you have a test case, that would be great. I think I can come up with one if you don't have a small one.
I should have a fix for this specific problem checked in by the time I leave today. There are a few places where I'm not
handling the case where 'window == null'. The view isn't being hidden/
shown, either.
Any ideas of other potential problems this could cause?
This wasn't as widespread as I thought. Right now I'm not seeing any additional places where we would need to worry about this particular problem. I'm fixing the embedded view not hiding as part of the dispose fix.
There is one trap I'm seeing, however. Both the SWT and AWT will attempt to restore any menu bar associated with the corresponding Shell or Frame when the window becomes active, and conversely, clear the menu bar when it deactivates. There's no guarantee which handler for windowDidBecomeKey will fire first, so the last one will win.
I do seem to recall that the AWT won't remove menus that it didn't create. It does that by using SPI ([NSMenu _setName], I think) to tag the NSMenus, so if an embedded Shell creates a menu bar that should work. But if the AWT Frame creates a menu the SWT will clobber it on activation. We'll need to come up with a similar change for menus, but preferably one that doesn't use _setName.
I'll look into menubar issues next.
-- Scott
----------Scott Kovatch Flex Engineering
I am Scott Kovatch, and I approve this message.
|