Gentlemen, thank you for those succinct responses. I'll go through my code base
and make the necessary changes.
Best wishes,
Martin
On 24, Jun, 2012, at 07:55 AM, Conrad Shultz wrote:
> As Roland indicated, yes, this is a general statement.
>
> It would be advisable to read the Error Handling
As Roland indicated, yes, this is a general statement.
It would be advisable to read the Error Handling Programming Guide, which
includes, among other things:
"Important Success or failure is indicated by the return value of the method.
Although Cocoa methods that indirectly return error object
On Jun 24, 2012, at 1:35 PM, Martin Hewitson wrote:
> Just a quick follow up on this.
>
> It's been stated that it's unsafe to check the error returned from
> -writeToURL:atomically:encoding:error: and rather one should check the return
> value. Is this a general statement for other methods wh
Just a quick follow up on this.
It's been stated that it's unsafe to check the error returned from
-writeToURL:atomically:encoding:error: and rather one should check the return
value. Is this a general statement for other methods which fill an error object
on error? For example, what about NSFi
On Jun 24, 2012, at 12:25 PM, Graham Cox wrote:
>
> On 24/06/2012, at 1:55 PM, Jerry Krinock wrote:
>
>> Why didn't Apple do the same thing for ARC?
>
>
> Because ARC is a compiler technology that inserts -retain, -release
> automatically and silently into your code as it is compiled. The me
On 24/06/2012, at 1:55 PM, Jerry Krinock wrote:
> Why didn't Apple do the same thing for ARC?
Because ARC is a compiler technology that inserts -retain, -release
automatically and silently into your code as it is compiled. The methods have
to be there in order for memory management to work at
On 2012 Jun 23, at 18:41, Dave DeLong wrote:
> Yep, you can do this…
Very good, Dave. I'm doing it.
But now I wonder why Apple did not do this, as they did with Garbage
Collection. Methods -retain, -release, and -autorelease are no-ops when GC is
on.
Why didn't Apple do the same thing for
Yep, you can do this. The #if you're looking for is:
#if __has_feature(objc_arc)
...
#endif
You can just scatter that everywhere in code, or you could do something like
this:
#if __has_feature(objc_arc)
#define DD_RETAIN(_o) (_o)
#define DD_RELEASE(_o)
#define DD_AUTORELEASE(_o) (_o)
#els
I'm curious as to why, when using non-ARC code, the recommendation is to "opt
out" the file with -fobjc-arc.
How about doing something like this…
#ifndef HEY_ARC_IS_IN_USE
[foo retain] ;
#endif
This way the file is fixed "once and for all", and I don't have to be setting
-fobjc-arc every t
Just for those who need to customize their outline view disclosure arrow:
Here's the answer from SO, that worked perfectly for me.
http://stackoverflow.com/questions/11127764/how-to-customize-disclosure-cell-in-view-based-nsoutlineview
Best Regards,
Nava Carmon,
Moshiach Times Ltd.,
e-mail:
On Jun 23, 2012, at 2:02 PM, Matthew Weinstein wrote:
> I think I see a second problem coming down the pike. the users can add pdfs
> to the wrapper file through a typical open file or through drag and drop. I
> get that the NSOpen... allows me to expand entitlements. But does drag and
> drop?
On Jun 23, 2012, at 1:26 PM, Matthew Weinstein wrote:
> Unfortunately that undoes the automation idea. The time saving here is that
> by just re-saving the pdf, the app when the document is opened recombines it
> based upon the rules that the user set up. Basically you're forcing the user
> t
I think I see a second problem coming down the pike. the users can add pdfs to
the wrapper file through a typical open file or through drag and drop. I get
that the NSOpen... allows me to expand entitlements. But does drag and drop? Is
there a way to get a bookmark and ask for ongoing privileges
Yup! They are contributed by the user, but they stay in the user space; they
are read-only. I create a pdfdocument with them and then borrow pages to
resequence them (based on a table the user keeps) and spit out a new pdf. The
automatic part is that the user can tell the program what to do with
So if I understand your pattern, you are managing a single "product PDF" which
is constructed by your app based upon metadata which describes the specific
component PDFs etc that the user has chosen. Those component PDFs reside
elsewhere than within your app space, correct?
On 2012-06-23, at
Unfortunately that undoes the automation idea. The time saving here is that by
just re-saving the pdf, the app when the document is opened recombines it based
upon the rules that the user set up. Basically you're forcing the user to
recreate the sequence of files each time anew.
On Jun 23, 20
On Jun 23, 2012, at 1:16 PM, Matthew Weinstein wrote:
> The whole idea of the app is so that users can automate the combining of
> different PDFs; users should be able to swap out different pdfs and then the
> program will recombine them. The program remembers (saves in a wrapper) the
> pdfs t
The whole idea of the app is so that users can automate the combining of
different PDFs; users should be able to swap out different pdfs and then the
program will recombine them. The program remembers (saves in a wrapper) the
pdfs that have been combined. Sort of defeats the purpose if the users
On Jun 23, 2012, at 12:09 PM, Matthew Weinstein wrote:
> I think the temp.security thing will work, but I'm wondering what happens if
> a user replaces a file in the directory by one with the same name; does the
> os know it's not the original file?
Security scoped bookmarks are attached to th
Thank you all for these wise words. I'll make the appropriate changes.
Cheers,
Martin
On 23, Jun, 2012, at 08:01 PM, Jeff Kelley wrote:
> Martin,
>
> Instead of inspecting the value of error, you should be inspecting the
> return value of writeToURL:atomically:encoding:error:. Only if t
I think the temp.security thing will work, but I'm wondering what happens if a
user replaces a file in the directory by one with the same name; does the os
know it's not the original file?
On Jun 23, 2012, at 9:53 AM, Alex Zavatone wrote:
> From what I have read in the docs, accessing files out
Martin,
Instead of inspecting the value of error, you should be inspecting the
return value of writeToURL:atomically:encoding:error:. Only if that returns NO
should you be inspecting the value of error which, as you’ve seen, may be
non-nil on success. You can see an example here:
https
In general, it is not safe to assume that errors from Cocoa frameworks are
cleared when an operation succeeds (in fact, I believe that they they are
almost never cleared). The only way to determine if "writeToURL" succeeds is to
test the return value (not the error). If the return value is YES,
Dear list,
I have an interesting bug report from a user of an app of mine. The app manages
files and allows the user to edit them. When they save the project each file is
saved to disk (if necessary). They are experiencing what appears to be a false
positive of writeToURL:atomically:encoding:er
>From what I have read in the docs, accessing files outside of the approved
>areas/domains (music, photos, documents(?) ) will ALWAYS require user
>interaction.
Apple is really screwing us in this one.
I hope that Conrad is right with his suggestion.
On Jun 23, 2012, at 12:17 PM, Matthew Weins
If I understand you correctly, this sounds like the use case for
security-scoped bookmarks:
http://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW16
(Sent from my iPhone.)
--
C
Because of the annoyance of sandboxing on iOS, I've been thinking how to write
simple prefs outside the app so that I know the pref is written when I write it
(no, iCloud is not a suitable solution).
Currently, I'm thinking of these options:
Declare an address, a music file or a picture as a da
Dear cocoa-dev,
So I'm wondering how in the maze of sandboxed apps how to get my app to work
properly. What it does is wrap around pdf files so that they can be combined,
separated; etc. It doesn't actually change the original pdfs, just remembers
their locations, reads them in and then writes t
Just wanted to say: Problem solved!
My Info.plist was the problem.
I defined the NSSendFileTypes as NSStringPboardType and
public.plan-text. But I had to define the NSSendTypes. I also removed
the "Required Context".
NSServices
NSMenuItem
29 matches
Mail list logo
