I don't know what the difference would be in trying to attach to a
native NSWindow vs one that wraps a Carbon window. When I've done
this in the past, I always knew that I was attaching to a native
NSWindow. Sorry I can't be more helpful.
steve
On Oct 22, 2009, at 6:44 AM, Motti Shneor wrote:
Thanks again.
Regarding the Carbon Window problem, the FrontWindow() call was
just an illustration. The WindowRef I'm supplying is of a visible
(usually active and front) Document window. The problems are not
even consistent, and will randomly occur. The desired behavior,
though, will very rarely occur. (I'd say one in a hundred times).
In short --- Are there any specific implications to opening a cocoa
sheet over a carbon (document) window? Is there any specific setup
I need to know about? What are the limitations of Cocoa NSWindow
wrappers around Carbon windows?
The problem is, my Plugin is written using cocoa, but runs within a
Carbon application. I need to attach my NSOpen/NSSave panels onto a
given application window, which is, of course, a Carbon window. I
get this bogus behavior and even worse, both running with my Host
application, and with simplistic test programs like the one below.
Any hints?
Last (and most important) - Supposedly I use your nice category
like this:
WindowRef frontWin = ::FrontWindow(); // get Carbon application
front window. Actually, any carbon window.
NSWindow *cocoaFromCarbonWin = [[NSWindow alloc]
initWithWindowRef:frontWin];
NSSavePanel *navPanel = [NSSavePanel savePanel];
[navPanel runModalForDirectory:nil file:nil types:nil
relativeToWindow: cocoaFromCarbonWin];
Then I'm seeing a host of strange and bogus behaviors.
1. The most severe is that the sheet opens BEHIND the application
window, BUT is still the key window. So, the application is dead
--- I can't click on the sheet (it's not front, and not active,
does not respond to clicks). However, the main application window
is blocked for events too! (I have blocked it via
runModalForWindow!). so, I'm dead. User must force-quit the
application.
2. The sheet opens in the wrong place -- just somewhere on the
screen - not always the same place, but "favorably" when a centered
dialog would appear. If then I try to drag the parent carbon window
by its title, the sheet would "jump into place" and be dragged
right. Events seem to be OK.
3. The sheet is invisible --- Although I get no errors from the
application. However, the debugger console would (sometimes!)
contain lines like this:
[Session started at 2009-10-21 11:01:52 +0200.]
GNU gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18
20:40:51 UTC 2009)
Wed Oct 21 12:11:53 Moti-Schneors-Mac-Pro.local NavTester[4398]
<Error>: kCGErrorIllegalArgument: _CGSFindSharedWindow: WID 1835
Wed Oct 21 12:11:53 Moti-Schneors-Mac-Pro.local NavTester[4398]
<Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint()
to catch errors as they are logged.
Wed Oct 21 12:11:53 Moti-Schneors-Mac-Pro.local NavTester[4398]
<Error>: kCGErrorIllegalArgument: CGSOrderWindowListWithGroups:
invalid window ID (1835)
Wed Oct 21 12:11:53 Moti-Schneors-Mac-Pro.local NavTester[4398]
<Error>: kCGErrorIllegalArgument: CGSOrderWindowList: NULL list
pointer or empty list
Wed Oct 21 12:11:53 Moti-Schneors-Mac-Pro.local NavTester[4398]
<Error>: kCGErrorIllegalArgument: _CGSFindSharedWindow: WID 1836
Wed Oct 21 12:11:53 Moti-Schneors-Mac-Pro.local NavTester[4398]
<Error>: kCGErrorIllegalArgument: CGSOrderWindowListWithGroups:
invalid window ID (1836)
Wed Oct 21 12:11:53 Moti-Schneors-Mac-Pro.local NavTester[4398]
<Error>: kCGErrorIllegalArgument: CGSOrderWindowList: NULL list
pointer or empty list
Any ideas? something I forgot to do? What in general is the state
of opening cocoa-sheets over Carbon-windows? When do I need to
release this NSWindow? I don't wish to close the Carbon window, as
it is coming from my host application!
You may not want to call FrontWindow() since its docs say, "Most
applications should use call ActiveNonFloatingWindow or
FrontNonFloatingWindow instead of FrontWindow because
ActiveNonFloatingWindow and FrontNonFloatingWindow return the active
and frontmost document window, respectively, skipping over other
types of windows that may be in front of the active document, such as
the menubar window, floating windows, help tags and toolbars."
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
