Something is extremely screwy.
I've rebuilt the lsregister, I've rebooted in safe mode, tried everything that
I can find hints about on the 'net.
In my app, I log the results from +readableTypes and they all look fine.
Experimenting, these seem only to be derived from the document types I
On Oct 15, 2014, at 23:05 , Graham Cox graham@bigpond.com wrote:
I don't know, but it seems to bethat my system is screwed up in some way that
the usual lsregister rebuild isn't clearing. If that's the case then this
screw-up occurred using Xcode 6.0.1's UTI editor plus launching my app,
On 16 Oct 2014, at 5:18 pm, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
I dunno, but I also got into LS database hell once, and it wasn’t fun.
Well, that's actually a help - it means that what I'm experiencing isn't
necessarily unique.
From what I recall, rebuilding the
On 16 Oct 2014, at 7:04 pm, Graham Cox graham@bigpond.com wrote:
It acts exactly the same.
I subclassed NSDocumentController so I can intercept and log some of the
internals, and the file types being passed to
-beginOpenPanel:forTypes:completionHandler: are correct - all of the
Just a shot in the dark, but maybe this is an issue:
Comparing your declaration to the sample from
https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_declare/understand_utis_declare.html
reveals that the sample declares
On 16 Oct 2014, at 10:07 pm, Graham Cox graham@bigpond.com wrote:
maybe somone can spot an issue with the UTI export?
Just a guess -- the docs say:
When specifying conformance for your UTI, your items should ideally conform
to both a physical and functional hierarchy. That is, the
On Oct 16, 2014, at 4:07 AM, Graham Cox graham@bigpond.com wrote:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN
http://www.apple.com/DTDs/PropertyList-1.0.dtd;
plist version=1.0
array
I’m assuming this is a snippet extracted from your actual
On 17 Oct 2014, at 2:25 am, Kyle Sluder k...@ksluder.com wrote:
I’m assuming this is a snippet extracted from your actual Info.plist.
Yes, when you copy a section of the info.plist it inserts a new header around
it.
dict
keyUTTypeConformsTo/key
array
On 17 Oct 2014, at 11:36 am, Graham Cox graham@bigpond.com wrote:
Im grateful for the help, though so far I'm still not certain whether I've
nailed the problem or not.
Nope, because moving the clean build of the app to another machine it cannot
open its own files, even after waiting a
Just to throw another spanner in the works, is there an interaction between the
UTI/filetype/app claim system and code signing?
For my second machine, I've been signing my app using my Developer ID. If I
don't sign it, it works. If it's signed, it doesn't. The UTI documentation
doesn't
Hi all,
My app declares 3 UTIs for import, which are basically the same as the document
types it supports.
It imports two of the types fine, but the other (which is actually the default
native format) it refuses to accept - I get a message to say that my app cannot
open documents of
On Oct 15, 2014, at 8:14 PM, Graham Cox graham@bigpond.com wrote:
Hi all,
My app declares 3 UTIs for import, which are basically the same as the
document types it supports.
It imports two of the types fine, but the other (which is actually the
default native format) it refuses to
On 16 Oct 2014, at 2:19 pm, Kyle Sluder k...@ksluder.com wrote:
Is there another app on your system declaring that file extension for its own
UTI? You can dump the database with lsregister(1).
No, I used lsregister -dump and my app is the only one.
I'm going backwards now - having rebuilt
13 matches
Mail list logo
