On Mar 29, 2015, at 10:51 PM, Daryle Walker dary...@mac.com wrote:
An idea... move the destination file, if it exists, to the trash.
See NSFileManager's trashItemAtURL:resultingItemURL:error: to do that in a
safe manner. Trash the old file then save the new.
That was one of my
On 2015/03/25, at 9:44, Daryle Walker dary...@mac.com wrote:
A segment from my command-line tool:
NSURL * const finalLocation = [NSURL
fileURLWithPath:response.suggestedFilename isDirectory:NO];
[[NSFileManager defaultManager] moveItemAtURL:location
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
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).
Sent
On 30 Mar 2015, at 08:19, Steve Mills sjmi...@mac.com 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
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 mabdul...@karelia.com
wrote:
On 30 Mar
On Mar 30, 2015, at 08:11:03, Marek Hrušovský xhrus...@gmail.com 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
On Mar 30, 2015, at 04:09:13, Mike Abdullah mabdul...@karelia.com 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
On 30 Mar 2015, at 17:34, Steve Mills sjmi...@mac.com wrote:
On Mar 30, 2015, at 11:14:17, Uli Kusterer witness.of.teacht...@gmx.net
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
On Mar 30, 2015, at 11:37:46, Mike Abdullah mabdul...@karelia.com 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%
On 30 Mar 2015, at 17:24, Steve Mills sjmi...@mac.com wrote:
On Mar 30, 2015, at 04:09:13, Mike Abdullah mabdul...@karelia.com 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
On Mar 30, 2015, at 11:14:17, Uli Kusterer witness.of.teacht...@gmx.net 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
On Mar 30, 2015, at 3:00 AM, dangerwillrobinsondan...@gmail.com wrote:
On 2015/03/25, at 9:44, Daryle Walker dary...@mac.com wrote:
A segment from my command-line tool:
NSURL * const finalLocation = [NSURL
fileURLWithPath:response.suggestedFilename isDirectory:NO];
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
On Mar 30, 2015, at 7:44 PM, Daryle Walker dary...@mac.com
mailto:dary...@mac.com 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:
On Mar 30, 2015, at 5:17 PM, Daryle Walker dary...@mac.com wrote:
On Mar 30, 2015, at 7:59 PM, Kevin Perry kpe...@apple.com
mailto:kpe...@apple.com wrote:
-replaceItemAtURL:… relies on the atomicity of the POSIX rename() function
in order to safely do its operation. Since rename()
On Mar 30, 2015, at 7:59 PM, Kevin Perry kpe...@apple.com 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
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
On 30 Mar 2015, at 11:09, Mike Abdullah mabdul...@karelia.com wrote:
On 30 Mar 2015, at 08:19, Steve Mills sjmi...@mac.com 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
19 matches
Mail list logo
