Well, dang, I got that wrong. (I “fixed” a typo in the email, forgetting to check that it actually worked.) You can’t use a KeyPath expression like “\WindowController.document.model” in

K, the problem I’ve been working around with the kvoDocumet bs documentObservation = self.observe(\WindowController.document.model) { error "Type of expression is ambiguous without more context”

It’s more or less correct, although I think you’re still making it a bit harder than it needs to be. Here are some inline comments on your window controller: You don’t actually need this. The

Thank you for your help with this! I’ve given it another try and hope some knowledgeable person could check that I’m still not Doing it Wrong ™ Currently WindowController.document still

Steve, I don’t want to disagree with you, but I’m seeing additional pieces of evidence which suggest (to me, at any rate) that this issue is related to timing, not insufficient constraints. I’ll

Setting only edge constraints (top/bottom/leaing/trailing) on the image view will not guarantee "consistent" size. Unlike UILabel, for example, an image view doesn't necessarily have an intrinsic size

I have explicit constraints. I expected consistent behavior and really don't understand why I don't get it. I've tried two cases: (1) UIImageView directly embedded in a (sub)-controller's view. Fully

I think I ran into similar issues in the dim past. If I recall correctly, the image view would resize to accommodate the image size if the image was set before a layout pass, or maintain some fixed

1. For any image which has an intrinsic size larger than the destination UIImageView object, the sizing behavior is the same. Namely, when the picker is dismissed (calling loadData(), the upper left

Questions: 1. Do you get different sizing behavior for the same image depending on which case/path gets taken? 2. How does the UIImageView size compare with image.size for the misbehaving case?

I have a UIImageView, which I load with the following function: func loadData() { guard let recipe = recipe, let fileN = recipe.photo, !fileN.isEmpty else { imageView.image = nil

I have a little app that writes alias files to its App Support folder on a regular basis. The app is sandboxed, so that ends up in ~/Library/Containers/<apputi>/Data/Library/Application

I did. The error message is: Cannot find service provider for selector nnn:userData:error: or nnn:: for service nnn Which suggest that two selectors are indeed tried. That is: Objective-C uses the

This doesn’t look right, and I don’t know why it works. If you put the name “nnn” in the info.plist, the selector it looks up should be “nnn:userData:error:”. The Swift 4 function

Now this is ok: @objc func nnn(_ pboard: NSPasteboard, _ userData: String) Where nnn = value of “Instance Method name” from Info.plist I am sure this is very well documented somewhere. The

This does work: @objc public func abc() { print(#function) } Well, it did, but hidden somewhere in DerivedData/… Now it works. Sorry for the noise. Gerriet

I have a Swift project called TestSwift: import Cocoa @NSApplicationMain class AppDelegate: NSObject, NSApplicationDelegate { @IBOutlet weak var window: NSWindow! func

This works: - (void)lookUppString:(NSPasteboard *)pboard userData:(NSString *)data error:(NSString * _Nullable *)error { NSLog(@“%s",__FUNCTION__); } But this does not: func lookUppString(_

Well, things get more complicated when you use non-Obj-C types, but it’s not necessarily true that you can’t use Swift types. In the case of the model, it may be sufficient that your “model"

Thank you, You are spot on with explaining the problem and I understand your answer and concerns. Sending up a NotificationCenter rocket in read(from:ofType:) confirms your explanation. Unless I’m