Re: Does "- replaceItemAtURL: withItemAtURL: backupItemName: options: resultingItemURL: error:" handle cross-volume moves?

> On Mar 30, 2015, at 8:37 PM, Kevin Perry wrote: > > >> On Mar 30, 2015, at 5:17 PM, Daryle Walker wrote: >> >>> On Mar 30, 2015, at 7:59 PM, Kevin Perry wrote: >>> >>> -replaceItemAtURL:… relies on the atomicity of the POSIX rename() function >>> in order to safely do its operation. Since

Re: Does "- replaceItemAtURL: withItemAtURL: backupItemName: options: resultingItemURL: error:" handle cross-volume moves?

> On Mar 30, 2015, at 5:17 PM, Daryle Walker wrote: > >> On Mar 30, 2015, at 7:59 PM, Kevin Perry > > wrote: >> >> -replaceItemAtURL:… relies on the atomicity of the POSIX rename() function >> in order to safely do its operation. Since rename() doesn’t work across >>

Re: Does "- replaceItemAtURL: withItemAtURL: backupItemName: options: resultingItemURL: error:" handle cross-volume moves?

> On Mar 30, 2015, at 7:59 PM, Kevin Perry wrote: > > -replaceItemAtURL:… relies on the atomicity of the POSIX rename() function in > order to safely do its operation. Since rename() doesn’t work across volumes > (returning EXDEV), the two URLs must be on the same volume. > > If you’re using a

Re: Does "- replaceItemAtURL: withItemAtURL: backupItemName: options: resultingItemURL: error:" handle cross-volume moves?

Hi Daryle, -replaceItemAtURL:… relies on the atomicity of the POSIX rename() function in order to safely do its operation. Since rename() doesn’t work across volumes (returning EXDEV), the two URLs must be on the same volume. If you’re using a temporary directory with replaceItemAtURL:…, you wa

Re: Does "- replaceItemAtURL: withItemAtURL: backupItemName: options: resultingItemURL: error:" handle cross-volume moves?

> On Mar 30, 2015, at 7:44 PM, Daryle Walker > wrote: > > NSFileManager’s “- moveItemAtURL: toURL: error:” method does a copy if the > source and destination file-URLs are on different volumes. Does “- > replaceItemAtURL: withItemAtURL: backupItemName: options: resultin

Does "- replaceItemAtURL: withItemAtURL: backupItemName: options: resultingItemURL: error:" handle cross-volume moves?

NSFileManager’s “- moveItemAtURL: toURL: error:” method does a copy if the source and destination file-URLs are on different volumes. Does “- replaceItemAtURL: withItemAtURL: backupItemName: options: resultingItemURL: error:” do similar? The docs for the latter don’t mention it. I’m worried sinc

Re: Bug with Localized Failure Reason and file moving

> On Mar 30, 2015, at 3:00 AM, dangerwillrobinsondan...@gmail.com wrote: > >> On 2015/03/25, at 9:44, Daryle Walker wrote: >> >> A segment from my command-line tool: >> >>> NSURL * const finalLocation = [NSURL >>> fileURLWithPath:response.suggestedFilename isDirectory:NO]; >>>

Re: NSOpenPanel accessoryView clicks must hit pixels to work

On Mar 30, 2015, at 11:37:46, Mike Abdullah wrote: > > Slightly less ugly idea, how about filling the background of your accessory > view with something like 1% alpha? Would that be enough to direct clicks to > the right place, without being visible to the human eye? 1% didn't work. I had to w

Re: NSOpenPanel accessoryView clicks must hit pixels to work

> On 30 Mar 2015, at 17:34, Steve Mills wrote: > > On Mar 30, 2015, at 11:14:17, Uli Kusterer > wrote: >> >> Makes sense considering that sandboxed apps don't run their own open panel. >> Instead the accessory view appears to be hosted in a borderless window that >> gets attached (at the Wi

Re: NSOpenPanel accessoryView clicks must hit pixels to work

On Mar 30, 2015, at 11:14:17, Uli Kusterer wrote: > > Makes sense considering that sandboxed apps don't run their own open panel. > Instead the accessory view appears to be hosted in a borderless window that > gets attached (at the Window Server level, I'd presume) to the actual open > panel t

Re: NSOpenPanel accessoryView clicks must hit pixels to work

> On 30 Mar 2015, at 17:24, Steve Mills wrote: > > On Mar 30, 2015, at 04:09:13, Mike Abdullah wrote: >> >> I think I’ve been seeing the same thing, and not been able to quite put my >> figure on it. Is your app sandboxed? > > Yes. Great googly moogly, that's it! I made a test project; click

Re: NSOpenPanel accessoryView clicks must hit pixels to work

On Mar 30, 2015, at 04:09:13, Mike Abdullah wrote: > > I think I’ve been seeing the same thing, and not been able to quite put my > figure on it. Is your app sandboxed? Yes. Great googly moogly, that's it! I made a test project; clicking white space in the checkbox label works. I turned on san

Re: NSOpenPanel accessoryView clicks must hit pixels to work

> On 30 Mar 2015, at 11:09, Mike Abdullah wrote: > > >> On 30 Mar 2015, at 08:19, Steve Mills wrote: >> >> OK, this is really weird. I just added an accessoryView to an NSOpenPanel. >> The view contains only a checkbox style NSButton. When testing it, it seemed >> like the clicks on this bu

Re: NSOpenPanel accessoryView clicks must hit pixels to work

On Mar 30, 2015, at 08:11:03, Marek Hrušovský wrote: > > AddAssetAccessoryView -> I think it should be named as a controller. > You kick off view loading and the view is being retained by nsopenpanel. > However, I can't see that you retain the NIB you load. Because the panel takes and then rel

Re: NSOpenPanel accessoryView clicks must hit pixels to work

AddAssetAccessoryView -> I think it should be named as a controller. You kick off view loading and the view is being retained by nsopenpanel. However, I can't see that you retain the NIB you load. Marek. On Mon, Mar 30, 2015 at 8:09 PM, Mike Abdullah wrote: > > > On 30 Mar 2015, at 08:19, Steve

Re: NSOpenPanel accessoryView clicks must hit pixels to work

> On 30 Mar 2015, at 08:19, Steve Mills wrote: > > OK, this is really weird. I just added an accessoryView to an NSOpenPanel. > The view contains only a checkbox style NSButton. When testing it, it seemed > like the clicks on this button's title didn't always take. It appears that > the only

Re: Core Foundation types as properties

> On Mar 28, 2015, at 11:12 PM, dangerwillrobinsondan...@gmail.com wrote: > > Interesting. > So is there a generalized best practice? Generally, to prefer Obj-C objects where possible. There isn’t much that can be done for things without Obj-C equivalents (like CoreGraphics for example). > S

NSOpenPanel accessoryView clicks must hit pixels to work

OK, this is really weird. I just added an accessoryView to an NSOpenPanel. The view contains only a checkbox style NSButton. When testing it, it seemed like the clicks on this button's title didn't always take. It appears that the only clicks that work are clicks that are on the checkbox itself

Re: Bug with Localized Failure Reason and file moving

> On 2015/03/25, at 9:44, Daryle Walker wrote: > > A segment from my command-line tool: > >>NSURL * const finalLocation = [NSURL >> fileURLWithPath:response.suggestedFilename isDirectory:NO]; >> >>[[NSFileManager defaultManager] moveItemAtURL:location >> toU