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.
keyNSServices/key
array
dict
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
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
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.)
--
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
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
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,
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:
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
On Jun 23, 2012, at 12:09 PM, Matthew Weinstein mwein...@kent.edu 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
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
On Jun 23, 2012, at 1:16 PM, Matthew Weinstein mwein...@kent.edu 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
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,
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
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
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
On Jun 23, 2012, at 1:26 PM, Matthew Weinstein mwein...@kent.edu 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
On Jun 23, 2012, at 2:02 PM, Matthew Weinstein mwein...@kent.edu 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
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:
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 time
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)
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
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 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 methods
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
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 which
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
27 matches
Mail list logo
