Re: Opening a NSSavePanel as a Sheet, and blocking like in [panel runModal]
Re: Opening a NSSavePanel as a Sheet, and blocking like in [panel runModal]
- Subject: Re: Opening a NSSavePanel as a Sheet, and blocking like in [panel runModal]
- From: Motti Shneor <email@hidden>
- Date: Thu, 22 Oct 2009 16:45:47 +0200
Hi Glenn, Thanks for your note --- However, I experience these
problems also when I'm completely document modal.
As a decent programmer, I immediately assumed the problem was in my
code, and wrote a quick test that did NOT block. I used the non-
blocking recommended beginSheetForDirectory: with the didEnd
selector, as defined in the API's, both on NSOpenPanel and
NSSavePanel. Same problems occur when attaching to a Carbon window.
By the way --- using [NSApp runModalForWindow:win] is not considered
"messing with the frameworks" and even is demonstrated in Apple Sample
code, and in the documentation, within the very scope of NSSavePanel
sheets. This is all legal technically. I understand that you don't
like sheets to block events on the whole application, but when I don't
write the application --- I'm sometimes forced to do so. Also, that's
what the host application requires from me.
I'm quite sure it has nothing to do with the modality issue. More like
an internal inconsistency between the Carbon and Cocoa window systems,
when I try to "bind" them together.
Moreover --- I went on, and re-wrote the whole thing (my navigation
objects) using Navigation Services - Carbon API's. Even there I
experience the same problem. You'd ask how's that? Don't we have
Carbon-To-Carbon relationship? well NO.
As of MacOS 10.5, Navigation Services are based on Cocoa -- even when
using Carbon API's. which means, my Carbon Nav Services calls are
internally creating Cocoa panels and sheets, which interact with the
application windows. Again, I see mal-functioning sheets (opening
Behind their parent windows, hanging my host program, "eating up" user
events, etc.
Any hint will be greatly appreciated.
On 22/10/2009, at 16:10, glenn andreas wrote:
On Oct 22, 2009, at 8: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.
There's one fundamental problem - sheets are designed to be document
modal, not application modal, which requires support from the
underlying application in order to work correctly.
So a sheet is not support to block the app like runModal does, but to
work in conjunction with document architecture.
You're basically fighting the frameworks, and the frameworks always
win...
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
Mad, Bad, and Dangerous to Know
Motti Shneor
Software Engineer
Waves Audio Ltd
Tel: +972 3 608 4155
www.waves.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden