Using services to email file in document based app
Hi, I would like my document based app to be able to send its files as email
attachments. I notice that the Finder has the services option to send a file as
an attachment, and kind of thought that something like that might have been
built in to the document architecture, but apparently not. It does appear to be
a standard service that is available and listed in the system preferences.
I assumed that if I wanted to try this out, I should be able to do something
like this in my NSDocument subclass:
+ (void)initialize {
[NSApp registerServicesMenuSendTypes:[NSArray
arrayWithObjects:NSFilenamesPboardType, NSFileContentsPboardType,
NSURLPboardType, NSFilesPromisePboardType, nil] returnTypes:nil];
}
- (id)validRequestorForSendType:(NSString *)sendType returnType:(NSString
*)returnType {
return nil;
}
- (BOOL)writeSelectionToPasteboard:(NSPasteboard *)pboard types:(NSArray
*)types {
return NO;
}
(assuming that the "New Email With Attachment" service would take one of the
pasteboard types I had specified). I then put breakpoints in the other two
methods, but they were never called.
I realize that there are other ways that something like this could be
accomplished, but seeing as the service is there, I wanted to try to get it
working that way.
Can anyone enlighten me on how this is supposed to be done?
Thanks
Gideon
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Using services to email file in document based app
On May 11, 2012, at 2:09 AM, Gideon King wrote:
> I assumed that if I wanted to try this out, I should be able to do something
> like this in my NSDocument subclass:
>
> + (void)initialize {
>[NSApp registerServicesMenuSendTypes:[NSArray
> arrayWithObjects:NSFilenamesPboardType, NSFileContentsPboardType,
> NSURLPboardType, NSFilesPromisePboardType, nil] returnTypes:nil];
> }
>
> - (id)validRequestorForSendType:(NSString *)sendType returnType:(NSString
> *)returnType {
>return nil;
> }
>
> - (BOOL)writeSelectionToPasteboard:(NSPasteboard *)pboard types:(NSArray
> *)types {
>return NO;
> }
>
> (assuming that the "New Email With Attachment" service would take one of the
> pasteboard types I had specified).
That service is defined in Mail's Info.plist and it takes NSFilenamesPboardType.
> I then put breakpoints in the other two methods, but they were never called.
The Services docs say that the latter two methods must be on an NSResponder
object, like a view or window. I recognize that the document is in the
responder chain for action messages, but that may not suffice for this case.
The docs also say:
"The validRequestorForSendType:returnType: message is sent along an abridged
responder chain, comprising only the responder chain for the key window and the
application object."
Regards,
Ken
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: First Responder
On May 11, 2012, at 4:25 AM, Gregory Weston wrote: > Absent from this narrative: Any indication that you have reason to believe > your view has actually *become* the first responder. The Window contains many views, each with a particular function to the application. Now, this may be y ignorance, but as I have understood ... NSViews are part of the responder chain and that the responder chain is traversed to find an action corresponding to the control or menu item connection. That views must implement accepts first responder to be pat of this process. Now, if what is being said is that a view cannot participate in this process until the user clicks the view, well ok. But what good is the responder chain if all views that acceptFirstResponder are not part of it ? -koko ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: First Responder
On 11 May 2012, at 8:56 AM, koko wrote: > Now, if what is being said is that a view cannot participate in this process > until the user clicks the view, well ok. But what good is the responder chain > if all views that acceptFirstResponder are not part of it ? Your understanding that only the focused view (among views) can be first responder is correct. This is reflected in "responder" being singular and not plural. Imagine a window with several NSTextFields. Imagine Edit > Select All being selected. This sends a selectAll: message to the first responder (and up the responder chain until a handler is found, or the chain is exhausted). Making every NSTextField the first responder would make the effect of the select-all indeterminate, which is undesirable. — F ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: First Responder
On May 11, 2012, at 8:28 AM, Fritz Anderson wrote: > Your understanding that only the focused view (among views) can be first > responder is correct. This is reflected in "responder" being singular and not > plural. koko grok ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: architectures that prevent freezing
On May 9, 2012, at 7:14 AM, Ph.T wrote: > . in a pre-emptive OS there should be no freezing; > given the new concurrency model > that includes the use of the graphics processor GPU > to do the system's non-graphics processing, Well, the GPU can _occasionally_ be used to do some non-graphics work, typically tasks that are highly parallelizable. I’d reckon this happens most often in games, less in general purpose software. > my current guess is that the freezes happen when > something goes wrong in the GPU, > and the CPU is just waiting forever . > . the CPU needs to have some way of getting control back, > and sending an exception message to > any of the processes that were affected by the hung-up GPU . > . could any of Apple's developers > correct this theory or comment on it ? OS freezes tend to happen when kernel-level code gets into an infinite loop or deadlock. Sure there “should be no freezing” but there should be no bugs either, and that’s never true. (It’s exacerbated by the fact that some 3rd party device drivers need to run in kernel space.) _Some_ system freezes are due to the GPU completely locking up, usually due to a bug in the GPU vendor’s driver. My understanding is that when this happens it’s not really possible for the GPU to recover without a system reset. The CPU is probably still OK, but that doesn’t do any good if it can’t access the display. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Using services to email file in document based app
Thanks Ken, moving it to my window controller got my validRequestorForSendType
called, but the services menu now shows up with just one item: "Notebook
Clipping Setup".
So as it stands, this is my code:
+ (void)initialize {
[NSApp registerServicesMenuSendTypes:[NSArray
arrayWithObject:NSFilenamesPboardType] returnTypes:nil];
}
- (id)validRequestorForSendType:(NSString *)sendType returnType:(NSString
*)returnType {
if ([sendType isEqualToString:NSFilenamesPboardType]) {
NSDocument *d = [self document];
if ([d fileURL] && ![[self window] isDocumentEdited]) {
return self;
}
}
return nil;
}
- (BOOL)writeSelectionToPasteboard:(NSPasteboard *)pboard types:(NSArray
*)types {
if ([types containsObject:NSFilenamesPboardType]) {
NSDocument *d = [self document];
if ([d fileURL] && ![[self window] isDocumentEdited]) {
[pboard setString:[[d fileURL] path] forType:NSFilenamesPboardType];
return YES;
}
}
return NO;
}
With this type registeredI see that the validRequestorForSendType is called
asking for the following types:
com.apple.flat-rtfd
dyn.agu8y6y4grf0gn5xbrzw1gydcr7u1e3cytf2gn
NeXT Rich Text Format v1.0 pasteboard type
NeXT RTFD pasteboard type
NSFilenamesPboardType
NSStringPboardType
public.rtf
public.utf8-plain-text
If I have a dirty document, or one that has just been created, the services
menu is empty as expected. However, when I have a saved document selected, the
only item that shows up is the notebook clipping setup.
Seeing as the service I want to be available is specified in the mail
info.plist using the NSFilenamesPboardType, I'm not sure where else the problem
could lie.
Anyone have any other suggestions?
Thanks
Gideon
On 11/05/2012, at 7:17 PM, Ken Thomases wrote:
>
> That service is defined in Mail's Info.plist and it takes
> NSFilenamesPboardType.
>
>> I then put breakpoints in the other two methods, but they were never called.
>
> The Services docs say that the latter two methods must be on an NSResponder
> object, like a view or window. I recognize that the document is in the
> responder chain for action messages, but that may not suffice for this case.
> The docs also say:
>
> "The validRequestorForSendType:returnType: message is sent along an abridged
> responder chain, comprising only the responder chain for the key window and
> the application object."
>
> Regards,
> Ken
>
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: architectures that prevent freezing
Le 11 mai 2012 à 18:05, Jens Alfke a écrit : > > On May 9, 2012, at 7:14 AM, Ph.T wrote: > >> . in a pre-emptive OS there should be no freezing; >> given the new concurrency model >> that includes the use of the graphics processor GPU >> to do the system's non-graphics processing, > > Well, the GPU can _occasionally_ be used to do some non-graphics work, > typically tasks that are highly parallelizable. I’d reckon this happens most > often in games, less in general purpose software. > >> my current guess is that the freezes happen when >> something goes wrong in the GPU, >> and the CPU is just waiting forever . >> . the CPU needs to have some way of getting control back, >> and sending an exception message to >> any of the processes that were affected by the hung-up GPU . >> . could any of Apple's developers >> correct this theory or comment on it ? > > OS freezes tend to happen when kernel-level code gets into an infinite loop > or deadlock. Sure there “should be no freezing” but there should be no bugs > either, and that’s never true. (It’s exacerbated by the fact that some 3rd > party device drivers need to run in kernel space.) > > _Some_ system freezes are due to the GPU completely locking up, usually due > to a bug in the GPU vendor’s driver. My understanding is that when this > happens it’s not really possible for the GPU to recover without a system > reset. The CPU is probably still OK, but that doesn’t do any good if it can’t > access the display. > > —Jens While playing with GPU programming, I had a lot of such freeze, and they never locked the CPU. I was always able to connect to my machine though SSH. Killing the processes that are affected is not enough. You may have to reinitialize the GPU driver. I think this is something Windows is able to do, but not Mac OS X AFAIK. More info about how it works on Windows can be found here: http://msdn.microsoft.com/en-us/windows/hardware/gg487368 -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Accessibility issues with NSPopover
On May 10, 2012, at 2:06 AM, Motti Shneor wrote: > does anybody know how to regain focus on an NSPopover after it lost user > focus? (after another window becomes key and main) I could not do it. The > only way I found was to close/delete the NSPopover and recreate it. Seems bad > solution to me. Just a guess here, but what happens if you call -[NSWindow makeFirstResponder:] on the window containing the view to which the popover is attached, passing one of the NSResponders from your popover as the argument? Although NSPopover has its own hidden window, it seems to hide some fairly intimate connections to its host window. Cheers, Curt - Curt Clifton, PhD Software Engineer The Omni Group www.curtclifton.net ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: architectures that prevent freezing
On May 11, 2012, at 9:23 AM, Jean-Daniel Dupas wrote: > While playing with GPU programming, I had a lot of such freeze, and they > never locked the CPU. I was always able to connect to my machine though SSH. So a regular user process can permanently lock up the display, requiring a reboot, just by executing some bad GPU code?! That’s kind of a bad privilege violation and could be considered a DoS exploit. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: crashes loading saved file
Yes, I agree about 25k frames being pretty big. It's possible though, because
the structure being unarchived is pretty complex... I decided to put an
NSLog(@"Unarchiving %p", self) at the line where the crash finally occurs in
initWithCoder of my CbCMNode class. Pasting the output into TextWrangler and
searching for any given object returns only a single match, so I'm guessing
there's no actual looping going on (but maybe there's a better way to check?).
Interestingly, I just ran the Allocations instrument and it opened the file
just fine. Poking a little more I noticed that profiling was running the
release build, which is on -O2 optimization, and seems to be able to load... Of
course, this will probably break as well, if I do more training.
Unfortunately, ARC is going to be awkward with this project, as I'm getting
loads of complaints from the ARC migration macro (not so many in my own code,
but a few from DrawKit, which is used heavily in my app). But, either way, I
think I have to figure out how to get the memory down. What seems strange to me
is that, once the app is open, it's only taking 50 MB in real memory -- less
than Mail, the Finder, Safari... So it's not a huge amount of memory. I think
it's just the fact that the stack gets filled **during** the unarchiving
process. But surely there must be a way around this. No?
J.
On 2012-05-09, at 7:11 PM, Roland King wrote:
> 25,962 frames on the stack seems to me rather a lot. Yes unarchiving is a
> very recursive process but that seems pretty deep.
>
> I missed the start of this thread so I don't know what mechanism you are
> using to archive and unarchive things, but is it possible you've tripped it
> up and it's going around a loop in the object graph and creating the same
> things over and over again (I know the standard archiver/unarchiver classes
> are coded to avoid that but if you have some code of your own, or have found
> a bug in them .. ). I think the best advice there was to look at the
> allocations screen on instruments, sort it by number of objects, it should be
> very clear very quickly if you expect to have made a few hundred of something
> whilst unarchiving and you have 20,000 of them.
>
> You could take a look at the stack trace as well, see if it looks like it's
> repeating itself, if it does and goes through any of your code then that
> gives you a place to look.
>
> On May 10, 2012, at 8:40 AM, James Maxwell wrote:
>
>> Thanks All,
>>
>> I'm just using retain-release, so I'll look into converting a version to
>> ARC. Unfortunately, I can't go 64-bit as I'm using DrawKit heavily, which
>> doesn't seem to support 64-bit builds. I'll also look into @autoreleasepool
>> in certain places. I do have a tendency to use the factory methods from
>> NSNumber quite often, so there may be cases where I'm creating lots of
>> autoreleased NSNumber objects.
>> However, I have to admit that I'm not sure how to fix the unarchiving
>> process, since the code runs fine while all the learning is happening and
>> the graph is being built. It seems to be the unarchiving process in
>> particular that's a problem. Is there some other way of periodically
>> draining the pool during the unarchiving process?
>>
>> J.
>>
>>
>> On 2012-05-09, at 12:55 PM, Fritz Anderson wrote:
>>
>>> On 9 May 2012, at 1:58 PM, James Maxwell wrote:
>>>
This morning, I tried enabling Guard Malloc (on its own, without zombies),
and was surprised to see the app crash during training, with the following
error:
GuardMalloc[ManuScore-2438]: Failed to VM allocate 1864016 bytes
GuardMalloc[ManuScore-2438]: Explicitly trapping into debugger!!!
Is it simply running out of VM while trying to build the graph? If so, why
doesn't this happen with Guard Malloc off? Also, with zombies and guard
malloc off, why is it only when reading the file that the app crashes, not
during training (i.e., while the graph is being built)?
One thing I have noticed, that seems pretty weird, is that the complete
backtrace when it crashes during unarchiving is 25962 frames long! Could
it simply be that it's running out of memory while trying to unarchive
(i.e., on the stack)? If so, how can I get around that? Some sort of
caching, perhaps?
The file is only 9.6 MB, so it's not a massive file...
>>>
>>> 1. What kind of memory-management scheme are you using? Garbage collection,
>>> ARC, or retain-release?
>>>
>>> 2. Assuming (praying) that you're on a version-control system, consider
>>> creating a branch and converting the project to ARC. It will make better
>>> memory-management choices than you will. See if that helps.
>>>
>>> 3. Are you accumulating lots of temporary (autoreleased) objects? Can you
>>> investigate embedding code inside loops in @autoreleasepool{...} blocks?
>>> @autoreleasepool is not an ARC feature. It's usable in any OS tar
Re: architectures that prevent freezing
Le 11 mai 2012 à 19:55, Jens Alfke a écrit : > > On May 11, 2012, at 9:23 AM, Jean-Daniel Dupas wrote: > >> While playing with GPU programming, I had a lot of such freeze, and they >> never locked the CPU. I was always able to connect to my machine though SSH. > > So a regular user process can permanently lock up the display, requiring a > reboot, just by executing some bad GPU code?! That’s kind of a bad privilege > violation and could be considered a DoS exploit. > > —Jens It was on 10.6 and never test if the system was better at handling lack of VRAM on 10.7 (caused by like texture leak for example). That said, if you want a DoS exploit, just send a shutdown Apple Event to the system, and it will stop the machine without asking anything. osascript -e 'tell app "System Events" to shut down' -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: architectures that prevent freezing
On May 11, 2012, at 12:55 PM, Jens Alfke wrote: > So a regular user process can permanently lock up the display, requiring a > reboot, just by executing some bad GPU code?! That’s kind of a bad privilege > violation and could be considered a DoS exploit. On the old 2008 non-unibody MacBook Pro that I used to have with the NVidia 8600M GT in it, you could do that just by executing some *good* GPU code. Charles ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Layer hosting custom NSView and setAlphaValue
Hello, I have a layer hosting custom view which I can't convince to listen to the alpha value I set on its superview. Other views sitting on the same superview correctly fade with the alpha value of the superview changing. My view doesn't. It simply hides when the superview's alpha is less than 1. Not sure what the problem is, the documentation for setAlphaValue doesn't tell me a lot, neither does the view programming guide. Any ideas? Regards Markus -- __ Markus Spoettl ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSViewAnimation reversed when using NSAnimationEaseOut
Hello,
using NSViewAnimation to animate a window frame, when I set the
animationCurve to NSAnimationEaseOut, the animation is reversed. I
triple-checked and logged the frames and they are set up correctly. The
animation dictionary looks like this:
{
NSViewAnimationEndFrameKey = "NSRect: {{1219, 900}, {376, 283}}";
NSViewAnimationStartFrameKey = "NSRect: {{1213, 900}, {408, 307}}";
NSViewAnimationTargetKey = "";
}
yet the window expands, instead of shrinking. If I set NSAnimationEaseIn as
animationCurve it works "correctly", just with the wrong animation curve.
Even more puzzling is the fact that this has been around for more than 5 years:
http://www.cocoabuilder.com/archive/cocoa/172342-nsviewanimation-bug-nsanimationeaseout.html
Please tell me that's a configuration issue (code below).
Regards
Markus
NSArray *shrinkAnimation = [NSArray arrayWithObjects:
[NSDictionary dictionaryWithObjectsAndKeys:
self, NSViewAnimationTargetKey,
[NSValue valueWithRect:expandedFrame], NSViewAnimationStartFrameKey,
[NSValue valueWithRect:targetFrame], NSViewAnimationEndFrameKey,
nil]];
NSViewAnimation *shrink = [[NSViewAnimation alloc]
initWithViewAnimations:shrinkAnimation];
NSLog(@"%@", shrinkAnimation);
[shrink setDuration:durationShrink];
[shrink setAnimationCurve:NSAnimationEaseOut];
[shrink startAnimation];
--
__
Markus Spoettl
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: architectures that prevent freezing
>> While playing with GPU programming, I had a lot of such freeze, and they >> never locked the CPU. I was always able to connect to my machine though SSH. Sometimes you can, sometimes you can't. It depends on exactly how things fail. > So a regular user process can permanently lock up the display, requiring a > reboot, just by executing some bad GPU code?! That’s kind of a bad privilege > violation and could be considered a DoS exploit. Yes, it is. A particularly serious one. It's been a pet peeve of mine for years that this is knowingly ignored by those who should know better. Last I checked, there was a watchdog mechanism on the GPU that would fire after some time (7 seconds on nVidia GPUs). That signals the driver (on the CPU) that it's doing a watchdog reset. Unfortunately, the drivers don't really handle that. They could - and *should* - reinitialise and recover, but it's just not implemented (or at least wasn't, a year or two ago). [[ There's probably also timeouts implemented in the driver and various other layers, though I don't know the details. ]] If you've ever done any CUDA work you'll be all too familiar with this problem. Much of nVidia's own example code will trigger this failure mode, and most require a reboot to recover from. In general GPUs are in a comparative stone-age when it comes to security and stability. They're getting better - retracing the steps of CPUs thirty years ago while thinking they're being very clever, in a cutely naive way - but it'll probably be many years before these problems are properly resolved. AMD & Intel are significantly ahead of nVidia in this regard, I hear. But personally, after having every single nVidia-packing machine I've ever owned die (sometimes repeatedly) due to GPU-related hardware faults, I'd never buy an nVidia based machine to begin with. But I digress... back to trying to recover data from my 8800GS iMac... again... ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: First Responder
On 11/05/2012, at 11:56 PM, koko wrote: > But what good is the responder chain if all views that acceptFirstResponder > are not part of it ? Because the purpose of the responder chain is to provide a context for the keyboard and other shared inputs, like the menu bar. While the user can click in any view at any time, and the mouse location selects which view gets the message, the keyboard needs another way to select which object the message is sent to. --Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: First Responder
Thanks for the courtesy of an edifying reply ... koko now grok more better. On May 11, 2012, at 4:25 PM, Graham Cox wrote: > > On 11/05/2012, at 11:56 PM, koko wrote: > >> But what good is the responder chain if all views that acceptFirstResponder >> are not part of it ? > > > Because the purpose of the responder chain is to provide a context for the > keyboard and other shared inputs, like the menu bar. While the user can click > in any view at any time, and the mouse location selects which view gets the > message, the keyboard needs another way to select which object the message is > sent to. > > --Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Funky file URLs from drag & drop
Why am I getting URLs from a file-drag operation that look like this?
/Users/rmann/Library/Developer/Xcode/DerivedData/DataOverlay-bcjfnacanylbcychqjbfqjytdptq/Build/Products/Debug/file:/localhost/Users/rmann/Desktop/SpaceX_CCDEV2.jpg
They should just be:
/Users/rmann/Desktop/SpaceX_CCDEV2.jpg
Here's my code:
- (BOOL)
performDragOperation: (id) inSender
{
NSMutableArray* files = [NSMutableArray arrayWithCapacity:
inSender.numberOfValidItemsForDrop];
[inSender enumerateDraggingItemsWithOptions: 0
forView: self
classes: [NSArray arrayWithObject:
[NSPasteboardItem class]]
searchOptions: nil
usingBlock:
^(NSDraggingItem* inDraggingItem,
NSInteger inIdx,
BOOL* outStop)
{
NSPasteboardItem* item =
inDraggingItem.item;
NSString* path = [item stringForType:
@"public.file-url"];
NSURL* url = [NSURL fileURLWithPath:
path];
[files addObject: url];
}];
if ([self.delegate respondsToSelector:
@selector(timelineView:didReceiveFileURLs:)])
{
[self.delegate timelineView: self didReceiveFileURLs: [files
copy]];
}
return true;
}
TIA,
Rick
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Funky file URLs from drag & drop
On May 11, 2012, at 16:58 , Rick Mann wrote: > NSString* path = [item stringForType: > @"public.file-url"]; > NSURL* url = [NSURL fileURLWithPath: > path]; You absolutely can't do this. A URL is not a path, not even when accessed as a string. (The first method is returning 'file:/localhost/Users/rmann/Desktop/SpaceX_CCDEV2.jpg', which is treated as a relative path name by the second, and so being prefixed with the absolute path to the current directory.) ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Funky file URLs from drag & drop
On May 11, 2012, at 17:10 , Quincey Morris wrote: > On May 11, 2012, at 16:58 , Rick Mann wrote: > >> NSString* path = [item stringForType: >> @"public.file-url"]; >> NSURL* url = [NSURL fileURLWithPath: >> path]; > > You absolutely can't do this. A URL is not a path, not even when accessed as > a string. Oh, of course. Thanks! -- Rick ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Need help filtering mouse events in an overlay child window
I'd like to act on -mouseDown when it occurs within the bounds of an
NSImageView, which is a subview of a transparent overlay child window. Some of
you may be wondering why I'm trying to do this so I'll try to explain that up
front. There are bugs in Snow Leopard regarding the use of Core Animation with
layer-backed views and NSOutlineView. In order to avoid these bugs, which I'm
told Apple will not be fixing for 10.6, I'm using a transparent overlay to do
the required animation and implement something like QuickLook or a preview
function.
I tried the following code but it resulted in really bad latency and coordinate
issues (I think) in the parent window's event handling.
#pragma mark - NSEvent Handling Methods
- (void)mouseDown:(NSEvent *)event
{
[self.parentWindow sendEvent:event];
#if 0
[super mouseDown:event];
[self.parentWindow removeChildWindow:self];
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
[self close];
}];
#endif
}
- (void)mouseDragged:(NSEvent *)event
{
[self.parentWindow sendEvent:event];
}
- (void)mouseEntered:(NSEvent *)event
{
[self.parentWindow sendEvent:event];
}
- (void)mouseExited:(NSEvent *)event
{
[self.parentWindow sendEvent:event];
}
- (void)mouseMoved:(NSEvent *)event
{
[self.parentWindow sendEvent:event];
}
- (void)mouseUp:(NSEvent *)event
{
[self.parentWindow sendEvent:event];
}
I'm thinking that the way I'm forwarding events to the parent is wrong. So I'm
looking for advice on implementing a proper mouse filter that can forward
events and generate the same result as if the event was originally sent to the
parent window.
-Michael
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Need help filtering mouse events in an overlay child window
Hi Michael
I have had to do this same thing, and have encountered the same problem.
In my case the main thing I wanted to accomplish was to get the scroll view in
the main window to reflect the scroll position of my overlay window. It was not
working very well, but then in my main window, I turned off scrollsDynamically
then did a scrollPoint, then turned the scrollsDynamically back on again. I'm
not sure if that is relevant to your situation.
That made it significantly better, but it's still not the same as scrolling in
the main window when I don't have the overlay window there, so if you find out
any more info, I'd be keen to hear.
For sending events to the main window from the overlay, I have been creating a
new event from the existing event like this:
NSEvent *newEvent = [NSEvent
mouseEventWithType:[theEvent type]
location:mapWindowPoint
modifierFlags:[theEvent modifierFlags]
timestamp:[theEvent timestamp]
windowNumber:[parentWindow windowNumber]
context:[NSGraphicsContext
graphicsContextWithWindow:parentWindow]
eventNumber:[theEvent eventNumber]+1
clickCount:[theEvent clickCount]
pressure:[theEvent pressure]];
[NSApp postEvent:newEvent
atStart:NO];
Where mapWindowPoint is the event location converted to the location in the
parent window's coordinates, and incrementing the event number is just a guess
at what I might be supposed to do (seems to work).
I'm also curious to know whether there is any advantage or disadvantage to
using the NSOperationQueue to close your window instead of using
performSelector:withObject:afterDelay:
Regards
Gideon
On 12/05/2012, at 11:35 AM, Michael Crawford wrote:
> I'd like to act on -mouseDown when it occurs within the bounds of an
> NSImageView, which is a subview of a transparent overlay child window. Some
> of you may be wondering why I'm trying to do this so I'll try to explain that
> up front. There are bugs in Snow Leopard regarding the use of Core Animation
> with layer-backed views and NSOutlineView. In order to avoid these bugs,
> which I'm told Apple will not be fixing for 10.6, I'm using a transparent
> overlay to do the required animation and implement something like QuickLook
> or a preview function.
>
> I tried the following code but it resulted in really bad latency and
> coordinate issues (I think) in the parent window's event handling.
>
> #pragma mark - NSEvent Handling Methods
>
> - (void)mouseDown:(NSEvent *)event
> {
>[self.parentWindow sendEvent:event];
> #if 0
>[super mouseDown:event];
>[self.parentWindow removeChildWindow:self];
>[[NSOperationQueue mainQueue] addOperationWithBlock:^{
>[self close];
>}];
> #endif
> }
>
>
> I'm thinking that the way I'm forwarding events to the parent is wrong. So
> I'm looking for advice on implementing a proper mouse filter that can forward
> events and generate the same result as if the event was originally sent to
> the parent window.
>
> -Michael
> ___
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/gideon%40novamind.com
>
> This email sent to gid...@novamind.com
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
