|
Re: UIDocumentInteractionController with non-standard file types
Steve Christensen
Have you tried it on a real device to see if there is any difference in behavior?
|
|
|
|
UIDocumentInteractionController with non-standard file types
Steve Mills
My iOS app has 2 custom UTIs declared in the Imported UTIs section, and 3 Document Types (those 2, plus pdf). When I try to share a file (doesn't matter if the URL's UTI is one of the custom types or pdf), it presentOpenInMenuFromBarButtonItem:animated: fails. If I use presentOptionsMenuFromBarButtonItem:buttonItem:animated:, it works. This is all in the simulator, so there might not be any apps that Open In will work with. The files are in my app's Documents dir. I have the delegate set to my view controller, and I implemented ALL UIDocumentInteractionControllerDelegate the methods so I could log which ones get called. None get called when I use the OpenIn version. Here are the messages in the simulator's log when I use the OptionsMenu version. Could it be an entitlements problem? Jul 11 16:49:52 MN5669AM007052 Box of Fun[69053]: UIDocumentInteractionControllerDelegate implements legacy action methods. Please remove them. Jul 11 16:49:52 MN5669AM007052 Box of Fun[69053]: can perform print: Jul 11 16:49:52 MN5669AM007052 Box of Fun[69053]: can perform copy: Jul 11 16:49:52 MN5669AM007052 Box of Fun[69053]: can perform saveToCameraRoll: Jul 11 16:49:53 MN5669AM007052 Box of Fun[69053]: will present options Jul 11 16:49:55 MN5669AM007052 pkd[33271]: SecTaskLoadEntitlements failed error=22 cs_flags=200, task->pid_self=-1 Jul 11 16:49:55 MN5669AM007052 pkd[33271]: SecTaskCopyDebugDescription: Box of Fun[69053] Jul 11 16:49:55 MN5669AM007052 Box of Fun[69053]: SecTaskLoadEntitlements failed error=22 cs_flags=200, task->pid_self=69053 Jul 11 16:49:55 MN5669AM007052 Box of Fun[69053]: SecTaskCopyDebugDescription: Box of Fun[69053] Jul 11 16:49:59 MN5669AM007052 Box of Fun[69053]: presented open in Jul 11 16:50:06 MN5669AM007052 assertiond[33257]: assertion failed: 14F2411 13C75: assertiond + 13207 [792516D1-991E-36EE-8454-16F8220758D6]: 0x1 Sent from iCloud's ridiculous UI, so, sorry about the formatting
|
|
|
|
Printing NSTextView puts text in middle of page - Solved
tridiak
Sorry for noise. Found the solution 5mins after I sent the email.
Mark
|
|
|
|
Re: NSInteger and NSUInteger
Xcode list 2013:
Date: Sun, 17 Nov 2013 15:38:22 -0500 From: Andy Lee <aglee@...> To: "Gerriet M. Denkmann" <gerriet@...> Cc: Xcode Users <xcode-users@...> Subject: Re: printing NSUInteger in iOS Message-ID: <E2CA2BAA-E03C-4850-8F42-7D3611A21C75@...> Content-Type: text/plain; charset=us-ascii I've been grudgingly casting, but there is this, which I haven't yet memorized: <https://twitter.com/gparker/status/377910611453046784> %zd, %tu, %tx (signed, unsigned, hex) currently format NSInteger and NSUInteger with no warnings. --Andy
|
|
|
|
Re: NSInteger and NSUInteger
Original post of this solution came from no other than Greg Parker!
|
|
|
|
Printing NSTextView puts text in middle of page
tridiak
Printing a NSTextView centres the text (if it is less than one page in size) vertically in the page, as opposed to the top.
What do you need to do to fix this? let tv = NSTextView() tv.textStorage?.append(ats) var npo = NSPrintOperation.init(view: tv); tv.frame.size.width = (sampleViewScroll.documentView?.frame.size.width)!; tv.frame.size.height = 20000; // or some large number npo.run(); The attributed text (ats) is valid (displayed in a visible NSTextView). Do I need to calculate the size of the text and set the margins? Or is there a justification setting I am missing? TIA Mark
|
|
|
|
Re: NSInteger and NSUInteger
Steve Christensen
On Jul 10, 2017, at 6:13 AM, Steve Mills <sjmills@...> wrote:
General information on format specifiers is here: I use %td for NSInteger and %tu for NSUInteger. The 't' is a length modifier specifying that a following d, o, u, x, or X conversion specifier applies to a ptrdiff_t or the corresponding unsigned integer type argument. That allows you to use the same format specifier for both 32- and 64-bit platforms, get the correct results, and avoid compiler warnings.
|
|
|
|
Re: NSInteger and NSUInteger
Gerriet M. Denkmann
On 10 Jul 2017, at 20:36, Dave <dave@looktowindward.com> wrote:Probably this was posted on Apple’s CocoaDev mailing list by someone who surely knows about these things. Gerriet.
|
|
|
|
Re: NSInteger and NSUInteger
Dave
Hi,
toggle quoted messageShow quoted text
Thanks a lot for this - where did you find it? Cheers Dave
On 10 Jul 2017, at 11:54, Gerriet M. Denkmann <g@mdenkmann.de> wrote:On 10 Jul 2017, at 16:37, Dave <dave@looktowindward.com> wrote:Formats for NS(U)Integer:
|
|
|
|
Re: NSInteger and NSUInteger
Steve Mills
On Jul 10, 2017, at 04:54:24, Gerriet M. Denkmann <g@mdenkmann.de> wrote:
Where did you find this info? I've seen mention of them, but never an official type doc that lists them. -- Steve Mills Drummer, Mac geek
|
|
|
|
Re: NSInteger and NSUInteger
Gerriet M. Denkmann
On 10 Jul 2017, at 16:37, Dave <dave@looktowindward.com> wrote:Formats for NS(U)Integer: %t… (%td, %to, %tu %tx, %tX) for unsigned results NSUInteger %z… (%zd, %zo, %zu %zx, %zX) for signed results NSInteger Gerriet.
|
|
|
|
NSInteger and NSUInteger
Dave
Hi,
I’m trying to use NSInteger and/or NSUInteger in a InitWithFormat statement, I’m using %ld as the specifier but this is producing warnings? Has this changed recently, because code that used to compile without warnings now cause warnings. What is the correct specifier to use for these types? Thanks a lot All the Best Dave
|
|
|
|
Re: BundleDisplayName
Quincey Morris
On Jul 9, 2017, at 21:15 , Gerriet M. Denkmann <g@...> wrote:
My guess is that it asymmetric for historical and/or compatibility reasons. There’s also something about the Finder storing a “.Localized…” named file inside the bundle, but I don’t know if that’s still a current thing. But at least you have a way forward that’s set-and-forget?
|
|
|
|
Re: BundleDisplayName
Gerriet M. Denkmann
On 10 Jul 2017, at 01:13, Quincey Morris <quinceymorris@rivergatesoftware.com> wrote:Here the result of my investigations so far: 1. The file-system-name (shown by ls command) = PRODUCT_NAME. The PRODUCT_NAME is initially set to $(TARGET_NAME). Changing the Target Name to: “New name” changes the Build settings to: PRODUCT_NAME = “New name”. 2. The app-menu and the About Panel show “Bundle name". 3. The Finder shows “Bundle display name" but only if: 3a. Info.plist contains Bundle display name = $(PRODUCT_NAME) 3b. <current language>.lproj exists, contains InfoPlist.strings and this has CFBundleDisplayName The Finder does NOT fall back to Base.lproj for current language = development region (as everybody else does). I fixed my problem by creating a copy of Bundle.lproj/InfoPlist.strings, putting it into an en.lproj folder and adding this in Xcode to the resources of my app. Sure I could also (as you mentioned) change the PRODUCT_NAME (which has the additional advantage of file-system-name = Finder-name). But I don’t like the asymmetry of it: Change the Finder name for development region: change PRODUCT_NAME in Build Settings Change the Finder name for any other language: change CFBundleDisplayName in xx.lproj/InfoPlist.strings On the other hand, if the Finder name is the same for all languages, then using the PRODUCT_NAME is clearly better. Thanks for your help! One more thing: Main.strings contains: /* Class = "NSMenuItem"; title = "AppName"; ObjectID = "1Xt-HY-uBw"; */ "1Xt-HY-uBw.title" = "AppName"; /* Class = "NSMenuItem"; title = "Quit AppName"; ObjectID = "4sb-4s-VLi"; */ “4sb-4s-VLi.title” = “Quit AppName"; I tried to change this to: "1Xt-HY-uBw.title" = "$(PRODUCT_NAME)"; “4sb-4s-VLi.title” = "Quit $(PRODUCT_NAME)"; But of course the last line does not work. Could this work? There are quite a few place where the AppName is hardcoded: About, Quit, Help (maybe more). Kind regards, Gerriet.
|
|
|
|
Re: How to write better Swift
Quincey Morris
On Jul 9, 2017, at 14:53 , Fritz Anderson <anderson.fritz@...> wrote:
The problem is that Swift doesn’t have any backing stores separate from properties. As you say (if effect), backing stores are implementation details. In Swift, if a property implementation wants to control what goes into its backing store, it needs a 2nd property. That’s the complaint here, and it’s purely bureaucratic: the 2nd declaration gets more prominence than it deserves; your eye can’t skip it so easily when reading the source of the enclosing type. There’s no real *functional* difference. (Also, since I originally posted, I realized that it also gives the 2nd property more *scope* that it should have. Hiding the backing store belonging to a single property from the rest of the implementation seems like a really good idea. How many of us, in Obj-C code, have got ourselves into trouble by using instance variables and property accessors inconsistently in a class implementation?)
The side effects I was thinking of were KVO notifications. I’ve been playing with some use-cases in the last couple of weeks, and it’s really, really hard to get this right sometimes without explicit control of a backing store. Indeed there’s a larger discussion (that I’ve been having in my head) about the possible need for *two* setters, one from the “UI side” and one from the “model” side. The UI setter eventually calls the model setter, but only the model setter generates KVO notifications. Why a setter from the UI? The setter is involved on the UI side when the UI element is mutable and uses bindings. OTOH UI methods that don’t use bindings use action methods instead, and (again in the discussion in my head) I’ve been considering whether some action methods are somehow part of properties, as in “get”, “set” and “act” behaviors. That sort of integrates the “act” behavior with the 2nd setter, unifying bindings and actions. Of course, I haven’t worked it out in any detail, so the whole thing might be infeasible or just plain muddled.
Except that Swift has stored properties *and* computed properties, and computed properties have no implicit backing store. By definition, a computed setter can be *nothing but* side effects. As above, if there’s any backing store required, though, that drives you to a 2nd property, which is ugly and a little dangerous for the reasons stated. Again, we’re talking implementation here, not client API design. The difference between stored and computed properties is opaque to clients of the type, and I agree with you that the semantics *for the client* should be simple, kind of passive, and indistinguishable in the two cases. FWIW, this all came up for me in the context of wrapping UserDefaults in a customized Swift class that makes user defaults values available as apparently pure Swift properties. This gets hard because UserDefaults doesn’t have properties, it has key/values, which means the ultimate backing store is one of your “broader” cases, and the flow of KVO notifications is not under the wrapper’s direct control, *plus* there are updates arriving from internal sources (including other processes such as ‘defaults write …’ in Terminal!) as well as UI such as a preferences window. So far, I haven’t found a good solution that doesn’t involve the wrapper type having a 2nd private property (as a private backing store) for each property it makes public.
|
|
|
|
Re: How to write better Swift
Fritz Anderson
On Jul 8, 2017, at 9:05 PM, Quincey Morris <quinceymorris@...> wrote: That doesn’t solve Gerriet’s problem. You can’t *prevent* setting the backing store without writing an actual setter. Similarly, if you want to constrain a value (e.g. keep an Int value >= 1), you can do it in didSet, but only at the cost of two writes to the backing store (which may have side effects). In that case I think we've gotten deeper than whether a set handler solves Gerriet's problem. I'm beginning to think there is no other good way to express exactly what he wants to do because Swift must provide for a broader case. If you want to persist something, something has to persist it. In the hardest cases the something is probably not a variable. If you want to do something about it — the set of "something"s may be infinite — something has to do it. Entangling the two (or 1 + n) somethings may often be the best choice, so I wish there were a gentler word than "smell." --- ## Backing store vs property Your distinction between backing store and property is on-point: • "Backing store" stores state. That's all it does. It's in the name. How it does that is opaque to client code. It might be implemented through SQL or REST; it might be a good old bit-pattern instance variable. How it's done is not API. Ideally, the only requirement is that it behave-as-if. • Properties fall elsewhere in the Venn diagram. They may wrap a backing store, they may share in a dependency graph, they may have side effects… You can imagine a property having _only_ side effects, a useful thought because it's clearly an abuse of the syntax. (This horse died during the ObjC `@property` wars.) This is not a problem unique to Swift, except insofar as how the language requires you to reason about it. There's no eliminating the need to reason about it: You cannot _prevent_ the setting of some backing store without executing code. "Backing" describes a passive receptacle, if the word has any meaning at all. Controlling what goes into the receptacle isn't passive; it is the action of whatever owns it. You cite the complications in setting state if setting it has side effects. "side effect" → "not passive." You're not writing to a variable, you're executing a setter. You have to put that in the API contract just as you would for things that start with `func`. If it's important that some action _not_ have a certain side effect, that's a different execution path. Swift can't automagically predict problems that arise from sharing a backing store across the implementation of an API. --- ## In Swift TL;DR: Properties should be reserved for things that smell like access to values with no side effects. In practice there's a lot of gray. At the extreme I'd say: Property notation should express (+/-) pure functions with no parameters on get, one on set. They change or reflect state; it's safe to repeat invocations; they look like accesses to field variables in C-family `struct`s. Anything with a side effect whether relating to a property or not should be a `func`. That's the extreme. That's where I'd start. That's not convenient. It's error-prone. I'd like to ask a random-number generator `rng.byte` for the next byte in the sequence. My sanity depends on `will`|`didSet` handlers — but they have problems of their own: Does the contract freeze the dependencies, or risk surprises? (It usually does both.) Cycles? Order dependencies? Side effect invariants that can't immediately be assured, like configuring views that might not exist yet? That's not a rap on Swift. The problems are irreducible. A designer can only mitigate them. Language designers have no perfect choices. --- ## Swift properties are not variables My view of Swift's balance is that properties wrap default getters, setters, and setting handlers that you can replace,* but the language encourages you to forget.** `var nPeople: Int` looks like a C-style allocation of a bit-representable value within a `struct,` but it's syntactic sugar for the whole accessor package. Swift allows you to think a `var` is just a variable, but "`var`" is a red herring. One may disagree with where Swift strikes the balance (if it's what I say it is). A language with a different balance (maybe one that attaches some kind of [executable] validator to variable declarations) might be ingenious, but it would not be Swift. \* (The default getter/setter may optimize to POD access in-line; I argue no principle requires it.) ** (Much of what we mean when we tell each other Swift is an easy language suitable for small children is that it's such a relief after being stuck with C for twenty years. Pretty quickly you get into questions that verge on the rabbinical.) --- ## They keep telling me to append a summary The need for a backing variable isn't peculiar to Swift or to so-called "variables." You can express it however suits you, but the problem (if you see it as one) is irreducible. — F
|
|
|
|
Re: BundleDisplayName
Quincey Morris
On Jul 9, 2017, at 07:45 , Gerriet M. Denkmann <g@...> wrote:
I’m not sure I understand completely, but I think you’re missing one point. As with the base localization, which (as you say) means that Xcode treats it as the “localization” for the development language, and you omit the actual localization for that language (English in your example), the Finder AFAIK uses the “unlocalized” bundle file name as the “base” file name. (Because it’s a bundle, it’s actually a directory name, but the principle is the same.) If you the developer are on an English system, you can change the “base” file name any time you want, after the app bundle is created, by renaming it in the Finder. I do this all the time for my apps, and the final “base” name is nowhere in my Xcode project settings. Again AFAIK, this has *no* downstream consequences for localized non-English systems — as you’ve seen, the original name is irrelevant when the Finder actually applies localization to the name. If you want to create the app with the desired English name during archiving, rather than renaming it later, then you must change build settings. AFAIK the one that controls the bundle’s file name is “Product Name”. The default value of this setting is “$(TARGET_NAME)”. If you don’t want the target name, you can put anything you want in there, minus the extension. So, I assume that if you put the desired English name of your app in the Product Name setting, you’ll get the results you want in all localizations.
|
|
|
|
Re: BundleDisplayName
Gerriet M. Denkmann
On 8 Jul 2017, at 20:06, Gerriet M. Denkmann <g@mdenkmann.de> wrote:Finder (at least in macOS 12.5) seems to work like this: When an app.bundle is copied into some folder (and only then), it reads TheApp.app/Contents/Resources/<system language>.lproj/InfoPlist.strings and uses the value of CFBundleDisplayName to display the app’s name. It never reads Base.lproj, even if the system language = Localization native development region = CFBundleDevelopmentRegion The problem is that Xcode (obviously unaware of this Finder peculiarity) does NOT allow English as an additional localisation (because the development region already is English; so English speaking computers should just use Base.lproj). What can be done? Gerriet.
|
|
|
|
Re: How to write better Swift
Quincey Morris
On Jul 8, 2017, at 17:15 , Jens Alfke <jens@...> wrote:
(Also to others suggesting will/didSet) That doesn’t solve Gerriet’s problem. You can’t *prevent* setting the backing store without writing an actual setter. Similarly, if you want to constrain a value (e.g. keep an Int value >= 1), you can do it in didSet, but only at the cost of two writes to the backing store (which may have side effects).
|
|
|
|
Re: How to write better Swift
Fritz Anderson
I'm missing something, possibly because the example code is abbreviated. Is this not equivalent? var status: StatusEnum = .uninitialized { // Sorry, "magic number" literals // make my teeth itch didSet { guard status != oldValue else { return } switch status { // etc. } } } — F
On Jul 8, 2017, at 12:12 PM, Quincey Morris <quinceymorris@...> wrote:
|
|
|