Re: Xcode 14 minimum deployment target
On 10/28/22 1:40 PM, Mark Allan via Cocoa-dev wrote: I've held off upgrading for the same reason. I wonder if it's something to do with a semantic difference between "is no longer supported" and "is no longer possible". Maybe what they really mean is "if it appears to work, great, but we can't guarantee it, and if it fails spectacularly, you're on your own"? That would certainly be great to know for sure. And where exactly it would fail spectacularly (if it did), meaning on the development machine or on a user's machine running an unsupported-by-Xcode system. We didn't notice that change and released an update to our app which targets 10.11 as deployment target. Regards Markus -- __________ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoa framework or Object class to uncompress files
On 10/25/22 3:45 AM, Carl Hoefs via Cocoa-dev wrote: My iOS app downloads a gzip'd data file into its sandbox that the app needs to unzip and process. I don't see anything in Cocoa (such as NSFileManager) that addresses uncompressing files. Is there a way? (BTW, I tried some ancient 3rd party code called ZipArchive but it always fails trying to parse the zipped file.) I'm hoping there's a built-in solution or framework that I'm just overlooking. I'm using an NSData extension that uses : https://github.com/schacon/igithub/blob/master/CocoaGit/Util/NSData%2BCompression.m Is very easy to use and works very well. You need to add "-lz" to the "Other Linker Flags" linker option in the target build settings of your project. Regards Markus -- __________ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: WKWebView rejecting keyboard input
On 4/15/21 4:42 PM, Robert Walsh via Cocoa-dev wrote: I have an Objective-C application that creates a WKWebView to collect form input. The form has a label, an input (password) field, and two buttons. When the form is shown inside the web view by the application, the user can click the buttons but cannot enter text into the input field. The system plays a sound to indicate that the key was rejected. I've tried adding a text area element to the form just to see if the problem is with the input field itself, but the user cannot type in the text area either. If I take the same HTML/stylesheet content and open it in Safari, the input field accepts keyboard input. There is another area of the application that shows a different web page in the same WKWebView component. That page, too, contains a form with an input field, and the user can type into that one. I am using a WKWebView subclass so that I can trap mouse down events, but I do not have any overloads for keyboard event handlers. Maybe your WKWebView never becomes first responder (and therefore is never getting key input), perhaps as a result of the mouse-trapping that is going on. You can check if it becomes key by overriding - (BOOL)becomeFirstResponder in your subclass and setting a breakpoint there. Best Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSecureCoding & Nested Collections & macOS 11
On 9/3/20 12:15 PM, Markus Spoettl via Cocoa-dev wrote: On macOS 11 this produces the following exception: -- -[NSKeyedUnarchiver _validateDecodeCollectionAllowedClassesRequirementsWithClasses:]: This method only supports decoding non-nested collections. Please remove the following or use '-decodeObjectOfClasses: forKey:' instead: ( NSDictionary (0x7fff88714520) [/System/Library/Frameworks/CoreFoundation.framework] ) -- It Was All Our Fault (tm), surprisingly :) Turns out we have an NSCoder extension that helps with secure coding and declares - (NSArray *)decodeArrayOfObjectsOfClasses:(NSSet *)classes forKey:(NSString *)key Apple must have seen it because the exact same method is not in NSCoder directly. Apparently the collision wasn't resolved to call the new instance method, but something else (probably -decodeObjectForKey:). Changing the extension's method name(s) to something more unique fixed the problem. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSecureCoding & Nested Collections & macOS 11
On 9/3/20 9:12 PM, Jens Alfke wrote: That sounds like a framework bug, since the warning is telling you to use the method you're already using. I'd file a bug report with Apple. Agreed and I did as did a user a couple of months ago. What is strange is that this wasn't fixed months ago, as any app deserializing such structures would be affected. There must be thousands. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSSecureCoding & Nested Collections & macOS 11
Hi, my app implements secure decoding for all its serialization and it worked fine up until macOS 11. Now the deserialization chokes on nested collections like this NSArray of NSDictionary containing [NSNumber, NSString, NSDate] (both keys and objects) What previously worked no longer does: NSSet *allClasses = [NSSet setWithObjects: [NSArray class], [NSDictionary class], [NSNumber class], [NSString class], [NSDate class], nil]; [decoder decodeObjectOfClasses:allClasses forKey:@"somekey"]; On macOS 11 this produces the following exception: -- -[NSKeyedUnarchiver _validateDecodeCollectionAllowedClassesRequirementsWithClasses:]: This method only supports decoding non-nested collections. Please remove the following or use '-decodeObjectOfClasses: forKey:' instead: ( NSDictionary (0x7fff88714520) [/System/Library/Frameworks/CoreFoundation.framework] ) -- Of course leaving out NSDictionary produces a different exception about the decode encountering an NSDictionary object. Something has changed, obviously. Can someone enlighten me how one is supposed to decode those kinds of objects? It's no option to change the encoding. Thanks for any pointers Regards Markus -- ______ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: iOS open In place, permission denied
On 4/28/20 11:23 AM, Markus Spoettl via Cocoa-dev wrote: - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options Just in case anyone is interested, main part of the solution is to wrap the usage of url inside a [url startAccessingSecurityScopedResource]; [url stopAccessingSecurityScopedResource]; sequence (plus use a NSFileCoordinator to read the file's contents, but that's really secondary). This was surprisingly difficult to figure out, the documentation really sucks. Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
iOS open In place, permission denied
Hi everyone,
I have a strange problem with the
- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url
options:(NSDictionary *)options
app delegate method, that seems to have cropped up a couple of weeks ago when switching to
the iOS 13 SDK (from 12). My app can no longer access files that are sent to it via "Open In".
My app declares the relevant UTIs and sets
UIFileSharingEnabled
LSSupportsOpeningDocumentsInPlace
in the Info.pList. The App delegate receives the message above just fine, but accessing
the given URL yields the following error (when using "Open In" from the Files.app):
Error Domain=NSCocoaErrorDomain Code=257 "The file “foo.bar couldn’t be opened because you
don’t have permission to view it."
UserInfo={NSFilePath=/private/var/mobile/Containers/Shared/AppGroup/372CF62C-2C92-446A-9A7E-0CA3884388A2/File
Provider Storage/foo.bar, NSUnderlyingError=0x281ce7120 {Error Domain=NSPOSIXErrorDomain
Code=1 "Operation not permitted"}}
I've tried copying the file (it is a local file) via NSFileManager -copyItemAtURL::: as
well reading its contents via NSData -dataWithContentsOfURL::: both produce this
permission error.
This worked fine prior to switching to Xcode 11 and the iOS SDK 13, I'm sure I'm just
missing a tiny bit that is now required.
Thanks for any pointers!
Best Regards
Markus
--
__________
Markus Spoettl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Code signing problem in one project...
On 4/26/20 11:25 PM, Steve Mykytyn via Cocoa-dev wrote: I'm automatically managing code signing on all my Xcode projects. Just today, one started refusing to validate / distribute, claiming it was missing a private key. All the other projects continue to build just fine. Tried restarting Xcode, turned automatic signing on and off, deleted derived data, removed anything old in the keychain. No luck. Suggested next steps? Since you didn't mention a reboot, last time I had inexplicable problems with code signing, a reboot cured it. Best Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Questions regarding release
On 9/26/19 11:16 AM, Gabriel Zachmann via Cocoa-dev wrote: NSImage * nsImage = [[NSImage alloc] initWithSize: nsimgrep.size]; [nsImage addRepresentation: nsimgrep]; return NSImage; You probably mean to write return nsImage; Best Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Crashing in NSTabView
In the past, if the crash like that was reliably and not to complicated to recreate and I had no other choice, then overriding -autorelease and putting a breakpoint into that worked on some occasions. Be prepared to get a lot of hits though. The object likely gets over-released by an auto-release sometime before the actual release causes the crash. Best Regards Markus On 5/22/19 7:19 PM, Casey McDermott wrote: Yes, we added a NSArray in the tab view controller with a strong ref to each child view controller. That slows down the crash by one cycle, but doesn't provide any additional clues. Is there a way for NSZombie to show when the object is released? AFAICT it only kicks in on dealloc. We can see that happen already with a breakpoint. The Allocations feature in Instruments looks promising. Is there a way to limit the display to just one class? Otherwise it is WTMI. Sorry for asking stupid questions on these tools, but Apple's docs are not very good. Stack Overflow is often for old Xcode versions where everything is different. We are mostly C++ folks, where this kind of problem is easily solved with a breakpoint in the destructor. Thanks, Casey McDermott Turtle Creek Software On Wednesday, May 22, 2019, 11:43:30 AM EDT, Keary Suska wrote: When you say "separate, strong reference to each tab view controller” do you mean each child view controller that controls a single tab view item, or the tab view controller as a whole? It is keeping string references to the individual child view controllers that should solve your situation. You may also want to check out Instrument’s zombies, which might better pinpoint where the issue is ocurring. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" On May 22, 2019, at 8:26 AM, Casey McDermott wrote: Our Mac app adds tabs to a NSTabView programmatically. After switching tabs a few times, one of the NSTabViewItems would release prematurely, causing a crash. So we switched it to using a NSTabViewController. Tab switching still crashes, but now it releases a NSViewController prematurely. Nothing else in the code references tab items or tab controllers. This is baffling. We can set a breakpoint on dealloc to see when it is deleted, but can't breakpoint on release to see what releases it. We build with latest Xcode but this has been going on with older ones also. We tried adding a separate, strong reference to each tab view controller. It still crashes, but it takes a few more tab switches before the controller is released. Any suggestions for what might be causing this? Casey McDermott Turtle Creek Software ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/cocoa-dev%40esoteritech.com This email sent to cocoa-...@esoteritech.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/ms_lists%40shiftoption.com This email sent to ms_li...@shiftoption.com -- ______ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: code signing fails to verify on 10.10?
On 5/20/19 5:38 AM, David M. Cotter wrote: my app works fine on 10.12 and above but on 10.10.5, i get this: Application Specific Information: dyld: launch, loading dependent libraries Dyld Error Message: Library not loaded: @loader_path/../Frameworks/libboost_thread.dylib Referenced from: /Users/USER/Desktop/kJams 2.app/Contents/MacOS/kJams 2 Reason: no suitable image found. Did find: /Users/davec/Desktop/kJams 2.app/Contents/MacOS/../Frameworks/libboost_thread.dylib: code signature invalid for '/Users/davec/Desktop/kJams 2.app/Contents/MacOS/../Frameworks/libboost_thread.dylib' I would try to see if the white space in the app's name could trigger this behaviour. Best Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Best strategy to update view controllers in navigation stack after users edit data
s are added, removed or replaced. In order for this to work you just need to use a KVO proxy for the real array. So you don't add or remove objects from your instance variable "ingredients" but instead you do it like so: NSMutableArray *kvoIngredients = [self mutableArrayValueForKey:@"ingredients"]; [kvoIngredients addObject:item]; -mutableArrayValueForKey: returns a proxy object that you can use to manipulate the array instance via the property accessor methods above. Don't be intimidated, once you get a hang of it, KVO becomes second nature. KVO an bindings can save you millions of hours of coding. Hope this helps. Best Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Layer-hosting views as superview?
Hi Matt, On 3/21/18 18:40, Matt Jacobson wrote: Hi Markus, There's really no official distinction these days between a layer-hosting view and a regular view. A view may have a layer (provided by directly calling -setLayer:), or AppKit may (or may not, depending on the exact circumstances) give it a layer automatically. Either way, the view is subject to the same rules about what properties of that layer it may mutate (vs. those AppKit "owns")—see <https://developer.apple.com/library/content/releasenotes/AppKit/RN-AppKit/#10_13Layer-backed%20Views <https://developer.apple.com/library/content/releasenotes/AppKit/RN-AppKit/#10_13Layer-backed Views>>. And either way, the view may certainly have subviews. We'll update the incorrect documentation—thanks for pointing that out. That's certainly very helpful, thanks! Question is, can I rely on this working alright as far back as macOS 10.10 (which is my current deployment target), or will this be asking for trouble? What I have - and that works on 10.13: Window | -- Custom Content View | -- Visual Effects view | -- Custom View containing NSButtons, NSTextField, etc. | -- Custom View containing NSButtons, NSTextField, etc. | -- Custom View containing NSButtons, NSTextField, etc. My custom content view is used to clip corners to a nice radius. The view class is set in IB. The window is of a border-less, background-less custom window class. Thanks again! Best Regards Markus -- __________ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Layer-hosting views as superview?
On 3/21/18 14:26, Markus Spoettl wrote: It seems the old rule that layer-hosting views must not have sub-views is no longer valid. I remember in the old days you couldn't have layer-hosting NSViews that have sub-views. I can't find the portion in the documentation that explicitly forbids it (I'm sure it was there). Can that be right? As usual shortly after sending the message I finally find something. In the docs for -wantsLayer it says: ... Similarly, do not add subviews to a layer-hosting view. ... BUT I also found a statement on stackoverflow by Corbin Dunn saying that it is OK https://stackoverflow.com/questions/10719368/are-layer-hosting-nsviews-allowed-to-have-subviews?rq=1 So it seems OK since 10.8 Mountain Lion. Or not. Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Layer-hosting views as superview?
It seems the old rule that layer-hosting views must not have sub-views is no longer valid. I remember in the old days you couldn't have layer-hosting NSViews that have sub-views. I can't find the portion in the documentation that explicitly forbids it (I'm sure it was there). Can that be right? If so, does anyone know in which OS version that was changed? Best Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSComboBox -comboBox:completedString: not called
On 3/13/18 09:42, Markus Spoettl wrote: I have trouble with NSComboBox in that the data source method -comboBox:completedString: is not getting called. The combo box in question uses bindings for "Value" and "Content Values", so I have no other data source methods implemented and -usesDataSource is NO (when that is turned to YES, the combo box looses its content). What I really want is implement case insensitive completion, I don't insist on using the data source if there's another way to do that. So, to answer my own question, I can "get this to work" using a custom NSComboBoxCell subclass, implementing -completedString. Having seen this in action I must confess this is a Bad Idea™. Regards Markus -- __________ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSComboBox -comboBox:completedString: not called
I have trouble with NSComboBox in that the data source method -comboBox:completedString: is not getting called. The combo box in question uses bindings for "Value" and "Content Values", so I have no other data source methods implemented and -usesDataSource is NO (when that is turned to YES, the combo box looses its content). What I really want is implement case insensitive completion, I don't insist on using the data source if there's another way to do that. Regards Markus -- __________ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSecureCoding & NSAttributedString
On 2/19/18 18:56, Quincey Morris wrote: On Feb 19, 2018, at 01:42 , Markus Spoettl <ms_li...@shiftoption.com <mailto:ms_li...@shiftoption.com>> wrote: I'm not sure where the NSAccessibility… keys are defined https://developer.apple.com/documentation/foundation/nsattributedstringkey I found a workaround for the problem for classes that are not NSSecureCoding compliant: First I sub-class the offending class, implementing the NSSecureCoding protocol, […]. Then I set up the class as substitution for the original in the NSKeyedUnarchiver using -setClass:forClassName:. Yikes! So you hack the unarchiving process to substitute a malfunction class for the real one, in order to protect the unarchiving process from being hacked? Is this really safer than not using secure coding at all? (That’s a genuine question. Maybe this *does* plug the hole.) Yikes? Not really! IMHO it's actually elegant and uses only mechanisms that are available publicly and for the exact purpose of replacing classes. I just provide a "better" version of the classes that don't conform to NSSecureCoding which can be use as an stand-in in a safe way. The sub-classes conform to everything the base classes do + secure coding, so the NSAttributedString will be intact. I don't think THAT is the problem with the approach. It's the uncertainty that I catch all cases that will be thrown at me. Given the extensive list of NSAccessibility.. keys many of which use (id) as value, the risk is high that it will blow up. So, while not complete, I think that's an elegant fix, but unusable nonetheless. Regards Markus -- __________ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSecureCoding & NSAttributedString
On 2/18/18 23:26, Quincey Morris wrote: I dunno. I always though of the attributes as something extensible, but I guess they’re not really. (They can’t be, in NSAttributedString is an interchange format between apps.) Looking at the documented list, I would be worried about NSTextAttachment, which isn’t even documented as conforming to NSSecureCoding. Those NSAccessibility… keys don’t look too safe either. I'm not sure where the NSAccessibility… keys are defined, I looked at NSAttributedString.h they are not there. Anyway... The saga isn't over yet, I found a workaround for the problem for classes that are not NSSecureCoding compliant: First I sub-class the offending class, implementing the NSSecureCoding protocol, +supportsSecureCoding and -initWithCoder:. Since it is impossible to safely invoke the non-secure -initWithCoder: version of the class itself, I use a suitable other designated initializer when calling super. Then I set up the class as substitution for the original in the NSKeyedUnarchiver using -setClass:forClassName:. Finally I add it to the list of acceptable classes when decoding the attributed string. Works fine for NSShadow, NSTextAttachment and NSCursor. Of course this looses the attributes real values, but those I don't care about anyway. I haven't encountered a cursor attribute yet, though. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSecureCoding & NSAttributedString
On 2/18/18 23:01, Markus Spoettl wrote: As for additional NSAttributeString "companion" classes, I'm still open for suggestions. Sure enough I found other pulprits: NSTextList and NSShadow. According to the header, NSTextList does not conform to NSSecureCoding, yet this works (don't know why). However the decoder stops playing nice with NSShadow, which also doesn't conform to NSSecureCoding. For testing I copy/pasted complex web pages from the browser into my text field and tried loading that. First from Firefox (which brought in NSTextList) then from Safari which added NSShadow. I'm sure there are other problem cases still hiding but given that it's so easy to produce an NSAttributedString that will blow up on loading I can bury any hope this will work eventually. Ever. Thanks for listening :) Regards Markus -- ______ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSecureCoding & NSAttributedString
On 2/18/18 22:02, Quincey Morris wrote: On Feb 18, 2018, at 10:30 , Markus Spoettl <ms_li...@shiftoption.com <mailto:ms_li...@shiftoption.com>> wrote: The decoder isn't terribly concerned with where the individual classes will occur, just that they might. I was going to reply that it’s stupid that it behaves like this, but I guess it makes some sense after all. The secure coding protection against class substitutions can be global like this, since class identities are global in the archive. Still, you should probably assert “[notes isKindOf: [NSAttributedString class]]” immediately after that decode. Maybe I’m overthinking it, but I’d worry that your workaround enables some other kind of attack. For example, without the check, a maliciously-crafted archive that cause “notes” to be a NSTextTab could potentially crash your app, and that in turn might open up a vulnerability. Yes, I have an NSCoder extension that does exactly that. You also need to consider collections and dictionaries especially. Arrays are easy to enforce but dictionaries are really a weak spot. For starters you can't define which classes are acceptable as keys and which as values. What if you have collection classes as values, what layout is acceptable in sub-entries? None of that is expressible. I can appreciate the technical challenge retro-fitting secure coding into the existing architecture, but what it is right now sure feels like an absolutely bare minimum approach. As for additional NSAttributeString "companion" classes, I'm still open for suggestions. Best Regards Markus -- __________ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSecureCoding & NSAttributedString
On 2/18/18 06:12, Quincey Morris wrote: On Feb 17, 2018, at 20:34 , Glenn L. Austin <gl...@austinsoft.com> wrote: Or encode/decode them using Coding, then encode/decode the resulting encoded attributed string data using SecureCoding. Markus already said that archives exist with normally-encoded attributed strings, so that precludes changing the archive format in the way you say. But that does suggest a partial alternative. In the object that decodes the attributed string, Markus can turn “usesSecureCoding” off for that decode only (in the coder object, which has this property defined). This won’t be secure against attacks via the objects *in* the attributed strings, but it would protect the rest of the archive. As a security precaution Turning off requiresSecureCoding once it is turned on causes an exception, so that's not an option. I have now gotten it to work simply by decoding the attributed string like this: NSSet *allowed = [NSSet setWithObjects:[NSAttributedString class], [NSTextTab class], nil]; notes = [[decoder decodeObjectForClasses:allowed] retain]; The decoder isn't terribly concerned with where the individual classes will occur, just that they might. Of course that doesn't mean that it will work generally speaking, just for my special case. I don't mind adding more allowed classes there, any ideas what else I (or rather my users) might encounter? Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSecureCoding & NSAttributedString
On 2/16/18 23:58, Quincey Morris wrote: On Feb 16, 2018, at 14:13 , Markus Spoettl <ms_li...@shiftoption.com> wrote: how can I go about decoding NSAttributedString I just tried in a playground, and the problem is in NSParagraphStyle, not NSAttributedString. It looks like it falls foul of the known secure coding issue about decoding arrays of unknown type. (NSTextTab is the only class that lives in an array within a paragraph style.) That means NSParagraphStyle doesn’t actually conform to NSSecureCoding, and therefore nor does NSAttributedString, when any non-default tabs are present. It’s not clear that there’s an easy workaround. The only thing I can think of is to archive the text tabs separately, and somehow re-install them on the relevant paragraph styles after decoding, but that’s going to be a huge PITA in general. After digging into this a bit further it seems clear to me that there is no solution. It's is not even possible to ignore attributed strings that contain stuff incomprehensible to the secure decoder because the decoder stops working after it hit an exception for an class violation. If your attributed string is at the very end of the decoding process that might work, but if not, your f'd. There is no delegate call to exchange classes or content, to ignore the problem or other way to recover, it just blows up. Somebody didn't think this through it seems. Alternatively, I'm just unable to see the solution, which I would prefer... Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSecureCoding & NSAttributedString
On 2/16/18 23:58, Quincey Morris wrote: On Feb 16, 2018, at 14:13 , Markus Spoettl <ms_li...@shiftoption.com> wrote: how can I go about decoding NSAttributedString I just tried in a playground, and the problem is in NSParagraphStyle, not NSAttributedString. It looks like it falls foul of the known secure coding issue about decoding arrays of unknown type. (NSTextTab is the only class that lives in an array within a paragraph style.) That means NSParagraphStyle doesn’t actually conform to NSSecureCoding, and therefore nor does NSAttributedString, when any non-default tabs are present. It’s not clear that there’s an easy workaround. The only thing I can think of is to archive the text tabs separately, and somehow re-install them on the relevant paragraph styles after decoding, but that’s going to be a huge PITA in general. Thanks Quincey, that's in fact a huge problem. Even if I find a way to write the thing so it can be read back, I still have old files to read that contain offending NSAttributedStrings. The string is just a tiny part of my huge model, so I need a way to read it back, if need be without formatting. The one thing that it can't do is prevent me from reading files containing it. Best Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSSecureCoding & NSAttributedString
Hi there,
I have an app that stores - among other things - NSAttributedStrings. In the process of
converting the -initWithCoder: methods to NSSecureCoding I'm now hitting something I don't
know how to handle.
What I do is the following and it works (notes is an NSAttributedString * field
in my class):
notes = [[decoder decodeObjectOfClass:[NSAttributedString class]
forKey:@"notes"] retain];
I have one instance where the decoder throws and exception:
value for key 'NS.objects' was of unexpected class 'NSTextTab'. Allowed classes
are '{(
NSAttributedString,
NSParagraphStyle,
NSURL,
NSDictionary,
NSNumber,
NSFont,
NSGlyphInfo,
NSArray,
NSString,
NSColor
)}'
NSSecureCoding has some serious design flaws (collections, especially dictionaries) but as
long as one knows what objects they may contain one can make it work.
But how can I go about decoding NSAttributedString, how can I load such a string that
AppKit stored for me just fine.
Regards
Markus
--
______
Markus Spoettl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
NSView sub-layers clipped in 10.13?
Happy new Year, everyone! I have a custom layer hosting view that has a sub-layer positioned partly outside the view's bounds. Both the view's layer and the sub-layer have -masksToBounds set to NO. This worked "as expected" (that is to say, it worked as I wanted it to work), in that the sub-layer was fully drawn on screen as if the view's frame was much larger. This worked consistently from 10.10 to 10.12, but in 10.13 is no longer seems to. I read the release notes but couldn't find mention of new behavior. I have to admit that I always suspected this might be a sort of glitch. Can anyone confirm that I have to find a different way to create the same effect? Regards Markus -- ______ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Click-through
On 25/03/17 18:54, Daryle Walker wrote: Is there any way to disable click through? On a toolbar control or otherwise. Through an Interface Builder setting or otherwise. Depends on your needs, really but programmatically if you have a custom view class you can overwrite -mouseDown: and -mouseUp: and not call super. That's simple and effective but may not work for you, for example if you have a view that depends on/uses mouse interaction, where you can't just kill all mouse events. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSDocument autosavesInPlace + package file = no revert?
On 25/02/17 21:01, Quincey Morris wrote: On Feb 25, 2017, at 11:16 , Markus Spoettl <ms_li...@shiftoption.com <mailto:ms_li...@shiftoption.com>> wrote: My concern is that my packages can get huge in the 100MB to multiple GB range with hundreds of folders and thousands of individual files inside. Will the NSDocument storing system/AppKit cope with that? My understanding is that the versioning storage is granular, in the sense that large files are broken into parts, and only changed parts are re-written to disc. Using document packages should help this work better, assuming that your saves typically touch a fairly small number of files. So it’s worth testing to see what happens. I suspect it could use the same hard linking mechanisms that the package saving machinery uses itself, were a copy actually doesn't cost a lot and is fast. If that's the case my documents won't be a problem as most of the content stays the same between saves, usually. Anyway, thanks again for your help! Best Regards Markus -- ______ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSDocument autosavesInPlace + package file = no revert?
On 25/02/17 19:57, Quincey Morris wrote: Returning false from this method disables version browsing and revertToSaved(_:), which rely on version preservation when autosaving in place. IOW, you can’t expect reverting to revert in your situation. Thanks Quincey for the - as usual - super fast and spot on response, I completely missed that part. That's a bummer of course but I can understand why. My concern is that my packages can get huge in the 100MB to multiple GB range with hundreds of folders and thousands of individual files inside. Will the NSDocument storing system/AppKit cope with that? Best Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSDocument autosavesInPlace + package file = no revert?
Hi, I have a problem with autosavesInPlaces and my package document and reverting changes. The setup first: All of the following methods in my NSDocument subclass return YES + (BOOL)autosavesInPlace + (BOOL)autosavesDrafts - (BOOL)canAsynchronouslyWriteToURL::: - (BOOL)checkAutosavingSafetyAndReturnError: + (BOOL)preservesVersions returns NO I also have "Ask to keep changes when closing documents" turned on in the system preferences. Lets say I have a document (package) saved on disk, lets call it state A. When I make a change to my document model , a few seconds later the auto-save kicks in, replacing the original. That is expected. This is state B. When I don't manually use "File > Save" and quit the application, I get a "Revert Changes" panel for the document. Expected too. Then I select "Revert Changes" and the app quits. What I expect to find on disk is State A. But what is actually there is state B. Actually I'm not sure my document saving to a package has anything to do with it. I looked at what happens when the application quits and - (BOOL)revertToContentsOfURL:ofType:error: is called. The absoluteURL passed in is the original file URL. So it's not surprising that this call doesn't actually revert any change. It's the latest version that autosave put there, overwriting the original. Do I have to use +preservesVersions=YES make this work (this means, reverting actually does what it says)? I don't want my app to have that feature, but if it's a file-system background-only thing, then I just might. Best Regards Markus -- ______ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: SecStaticCodeCheckValidity fails when app is lauched from Terminal
On 27/09/16 22:57, Chris Hanson wrote:
On Sep 27, 2016, at 1:54 PM, Markus Spoettl <ms_li...@shiftoption.com> wrote:
On 27/09/16 22:39, Chris Hanson wrote:
How are you getting the URL that you pass to represent your application?
Could it be that you’re constructing the URL from a relative path when run
from the command line, rather than the full path? (You can’t depend on being
run from any particular working directory.)
Not sure what you mean by URL, I'm merely executing the app's executable from the command line. Assuming
the My.app bundle is located in "~/Projects/My/Debug", I cd into "~/Projects/My" and
execute "./Debug/My.App/Contents/MacOS/My”.
I mean, how are you constructing the SecStaticCodeRef that you pass to
SecStaticCodeCheckValidity()?
OK, here the full code:
CFStringRef reqStr =
SecStaticCodeRef ref = NULL;
SecRequirementRef req = NULL;
CFURLRef bURL = CFBundleCopyBundleURL(CFBundleGetMainBundle());
OSStatus status = SecStaticCodeCreateWithPath(bURL, kSecCSDefaultFlags, );
if ((ref != NULL) && (status == noErr)) {
status = SecRequirementCreateWithString(reqStr, kSecCSDefaultFlags, );
if ((req != NULL) && (status == noErr)) {
// this fails
status = SecStaticCodeCheckValidity(ref, kSecCSCheckAllArchitectures, req);
Regards
Markus
--
______
Markus Spoettl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: SecStaticCodeCheckValidity fails when app is lauched from Terminal
On 27/09/16 22:39, Chris Hanson wrote: How are you getting the URL that you pass to represent your application? Could it be that you’re constructing the URL from a relative path when run from the command line, rather than the full path? (You can’t depend on being run from any particular working directory.) Not sure what you mean by URL, I'm merely executing the app's executable from the command line. Assuming the My.app bundle is located in "~/Projects/My/Debug", I cd into "~/Projects/My" and execute "./Debug/My.App/Contents/MacOS/My". I'm starting the app from the command line in cases when I want to test a certain localization using the -AppleLanguages '(xx)' command line option, which is quite handy. As I said this used to work fine, but now the code signing signature is being rejected. However, using the "open" command works fine for me. Regards Markus -- __________ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: SecStaticCodeCheckValidity fails when app is lauched from Terminal
It is an OSX Cocoa GUI application. I have always started it from the command line by executing the executable inside the bundle. While this always worked, it no longer seems to. That said, it didn't occur to me that there's a proper way, by using the "open" command. Thanks for the tip, this works nicely for my purposes! Regards Markus On 26/09/16 19:18, Gary L. Wade wrote: In what way did you start your app from the Terminal? Is this WindowServer-based or a command line app? Not sure your purpose in starting from the command line if WindowServer-based, but have you tried launching it with the open command where the argument is the .app bundle vs possibly another way like the actual executable? -- Gary L. Wade http://www.garywade.com/ On Sep 26, 2016, at 2:44 AM, Markus Spoettl <ms_li...@shiftoption.com <mailto:ms_li...@shiftoption.com>> wrote: I'm using SecStaticCodeCheckValidity() to self check the signature of my own app when it is launched. This works fine and always has. All of a sudden, the call to SecStaticCodeCheckValidity() fails if (and only if the application) is started from the Terminal. When I start the very same app from the Dock or from the Finder the check succeeds (iow. the call returns noErr). I don't know exactly when it started failing. I only know it definitely worked before on previous versions of El Capitan but now it no longer does (v 10.11.6). Any ideas? Regards Markus -- __________ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com <mailto:Cocoa-dev@lists.apple.com>) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com <http://lists.apple.com> Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/garywade%40desisoftsystems.com This email sent to garyw...@desisoftsystems.com -- __________ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: SecStaticCodeCheckValidity fails when app is lauched from Terminal
On 26/09/16 15:16, Steve Christensen wrote: What is the error code when it fails? OSStatus is -67054, which is errSecCSBadResource. Only happens when launched from the command line. Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
SecStaticCodeCheckValidity fails when app is lauched from Terminal
I'm using SecStaticCodeCheckValidity() to self check the signature of my own app when it is launched. This works fine and always has. All of a sudden, the call to SecStaticCodeCheckValidity() fails if (and only if the application) is started from the Terminal. When I start the very same app from the Dock or from the Finder the check succeeds (iow. the call returns noErr). I don't know exactly when it started failing. I only know it definitely worked before on previous versions of El Capitan but now it no longer does (v 10.11.6). Any ideas? Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSFileWrapper
On 04/06/16 18:42, Jens Alfke wrote: I wouldn’t recommend NSFileWrapper for large files, because it reads all of a file into memory. I find this comment to be very misleading. Part of the reason why packages are so great (apart from being supported by NSDocument/AppKit as a method to store document data) is because you can partition the data into many many files. If you have data that's too big, split it up into multiple files. And what is large anyway? When you open such a package document, NONE of the individual file's contents are read, you have complete control over what individual file you read and when. Likewise with saving, you never have to store everything from scratch (you can, but you don't have to). If you have unchanged data you just let the API know (by reusing the wrappers you got when the file was opened). I'm a fan. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Removing Observers eats up memory
On 25/01/16 18:47, Ken Thomases wrote: When the array changes, I remove all observers from these objects before re-observing the new objects. If at all possible, you should do this in a more targeted fashion. Add and remove observers only from the objects which were actually added or removed from the array. If you have properly encapsulated modifications of the array in indexed collection mutating accessors, this is trivial. OK, that's certainly an option, but the brute force way it is currently working with surely should work, too, and not cause the symptoms I see. Has anyone any idea how the removing of observers can cause this kind of death spiral? You should use Instruments to trace exactly what's going on during one of the runaway cases. When I break in the debugger I end up in various different library functions concerned with hash tables and the like, such as #0 0x7fff9ddc6d03 in weak_entry_for_referent(weak_table_t*, objc_object*) () #1 0x7fff9ddc84b6 in weak_read_no_lock () #2 0x7fff9ddc8473 in objc_loadWeakRetained () #3 0x7fff9ddc861f in objc_loadWeak () #4 0x7fff9cbc81c5 in hashProbe () #5 0x7fff9cbcbf3a in -[NSConcreteHashTable rehashAround:] () #6 0x7fff9cbc8245 in hashProbe () #7 0x7fff9cbc8014 in -[NSConcreteHashTable addObject:] () #8 0x7fff9cbf3f48 in _NSKeyValueObservationInfoCreateByRemoving () #9 0x7fff9cbf3933 in -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] () #10 0x7fff9cbf3837 in -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] () #11 0x0001002e71f2 in -[TrackEditorViewController unregisterObserverForDataPoint:] at /Users/markus/Projects/rubiTrack/src/TrackEditorViewController.m:639 Not sure which instrument would help me finding out what is going on. I was using the Time Profiler but it didn't really help, partly because it's really difficult to know if I'm hitting the bug or not (it doesn't happen every time). Also recreating the issue under the debugger is much easier. By the way, you should consider implementing the observationInfo property on your observed class. This avoids KVO storing observation info in a side table. Note that the property is a void pointer, not an object pointer, and therefore does no memory management. This is interesting. When I implement this property in the proxy object, the problem goes away (at least I wasn't able to duplicate it so far). Turn off the implementation, it comes back. Not really sure what this tells me, though. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Removing Observers eats up memory
On 25/01/16 20:23, Ken Thomases wrote: This is interesting. When I implement this property in the proxy object, the problem goes away (at least I wasn't able to duplicate it so far). Turn off the implementation, it comes back. Not really sure what this tells me, though. Implementing the property avoids the need to use the global hash table to look up the observation info by the object's address. That, of course, sidesteps the whole issue of any performance issues with the hash table reorganizing itself. It's also just plain faster even without this specific issue with the hash table. The only thing you stand to lose is making your objects slightly larger. Since it sounds like these objects are basically guaranteed to be key-value observed, though, it ends up saving memory. Thanks for the suggestion and explanation, I would never have thought of using this. I wonder if there's a downside to implementing this in all my model objects other than adding an additional pointer to their data size. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Removing Observers eats up memory
On 25/01/16 17:31, Gary L. Wade wrote: You should look more at your design. Having that many objects being unobserved and reobserved (your word although in the context of new objects) reminds me of what I've called a genocidal refresh, an antipattern that can be fixed by only refreshing (or in your case observing) the things actually changed; in your case that may be only the items in the array that were added or removed. This no doubt would be the "right" way of doing it, but it would not address the issue at hand because the observations have to be removed when the view controller goes away (all of them at the same time), and that's where the problem happens. Regards Markus -- ______ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Removing Observers eats up memory
On 25/01/16 18:34, Quincey Morris wrote: On Jan 25, 2016, at 01:10 , Markus Spoettl <ms_li...@shiftoption.com <mailto:ms_li...@shiftoption.com>> wrote: Has anyone any idea how the removing of observers can cause this kind of death spiral? Genocidal refreshes aside, are you absolutely sure that you’re always removing/adding observers on an appropriate thread? There are two dangers here: 1. You may be doing things on a background thread that are supposed to be done on the main thread. 2. You may be doing things on multiple threads. In particular, doing massive quantities of retains and releases (via ARC) on multiple threads simultaneously has terrible performance characteristics, because (I think) there’s a lock involved. I would also assume that massive quantities of multi-threaded allocs and frees would be bad, because there has to be some kind of lock there too. Without contention, these locks are likely zero-cost (more or less). With parallelism, the results can be bad. There’s no particular reason to think that any of these things are happening in your scenario, but they might be worth looking into. Yes, true, worth a shot. Unfortunately not the problem, it all happens on the main thread. The code also doesn't use ARC (though the standard libs might, I don't know). Ken's suggestion implementing observationInfo solves this issue for me. Regards Markus -- ______ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Removing Observers eats up memory
Hi,
I have a view controller with a table view that is bound to an array
containing around 1000-1 model objects. The same view controller registers
itself as observer of all the objects' properties. These objects are actually
proxies for other model objects and are created by my view controller (there is
no outside reference to these objects).
When the array changes, I remove all observers from these objects before
re-observing the new objects.
Sometimes (on El Capitan) this removing of observers causes my app to freeze and
eat memory at an alarming rate. Sometimes this spirals completely out of control
until all memory is exhausted, sometimes it stops after a few gigabytes of
mystery allocations and my app continues.
The bug doesn't surface all the time, only 30-50% of all tries.
I have tried to wrap the observer removing code within an @autorelease {} block,
which helps a little. The problem is now harder to recreate, but it is still there.
This is on El Capitan using Xcode 6.4 built against the 10.10 SDK.
Has anyone any idea how the removing of observers can cause this kind of death
spiral?
Regards
Markus
--
__
Markus Spoettl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: 10.11: NSDatePicker cuts off year digit
On 10/11/15 18:26, Markus Spoettl wrote: This happens on 10.11 only, not on 10.10. Anyone able to confirm this using own code? Maybe something is set up incorrectly? Anyone know of a workaround until this gets fixed (yes, I will file a bug once it's confirmed that it's not my fault). Thanks Norbert for the confirmation. I tried a couple of things to get around the problem, but there seems to be no good solution. The only workaround I could come up with it setting the font that the picker uses to something other than "System" or "Lucida Grande". In both these cases, the font is replaced with the wider system font on 10.11. The downside of course is that "Helvetica Neue", which I now have to use for these controls, looks a little different. My theory is that the system does a measurement to size the date cells it uses internally before it replaces the font... It happens on regular size controls too and also on controls with time. No one ever tested this. Regards Markus -- __________ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
10.11: NSDatePicker cuts off year digit
Hi,
I have an app with an NSDatePicker in small control size, date only format
(day/month/year) and stepper controls. On El Capitan, with certain year numbers,
the control cuts off the last digit, for instance with 1966, 1969 and 1999. The
control displays the first 3 digits only ("196", "199").
Using the stepper (or cursor keys) it is possible to increment over the broken
numbers, so the internal representation seems intact.
Weirdly one cannot enter the numbers using the keyboard either, upon pressing
the last digit, the control beeps.
Clearly somewhere a string size measurement is going wrong. The NSDatePicker
itself is wide enough to accommodate the entire date twice, so control size
isn't the issue.
The app is linked against the 10.10 SDK, built with Xcode 6.4.
This happens on 10.11 only, not on 10.10. Anyone able to confirm this using own
code? Maybe something is set up incorrectly? Anyone know of a workaround until
this gets fixed (yes, I will file a bug once it's confirmed that it's not my fault).
Regards
Markus
--
__________
Markus Spoettl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
10.11 app crashes in [CIImage createCIImageWithSurfaceBytes:::::]
in _BlockUntilNextEventMatchingListInModeWithFilter () #43 0x7fff93fc6f3a in _DPSNextEvent () #44 0x7fff93fc6369 in -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] () #45 0x7fff93fbaecc in -[NSApplication run] () #46 0x7fff93f84162 in NSApplicationMain () #47 0x00010001a652 in main at /Users/markus/Projects/MyApp/src/main.m:38 #48 0x7fff89f2c5ad in start () -- followed by -- CVDisplayLink (14) #0 0x7fff9657ada4 in objc_exception_throw () #1 0x7fff87f92fed in +[NSObject(NSObject) doesNotRecognizeSelector:] () #2 0x7fff87e9a3d1 in ___forwarding___ () #3 0x7fff87e99f58 in __forwarding_prep_0___ () #4 0x7fff83fbeca4 in CA::OGL::SWContext::create_ciimage(CA::OGL::Surface*, int, CGAffineTransform const&) () #5 0x7fff83e908fb in CA::OGL::emit_filter(CA::OGL::Renderer&, CA::OGL::Filter const&, CA::OGL::Layer const&, float, CA::OGL::Surface*, float, CA::Vec2, CA::Shape const*) () #6 0x7fff83e9043f in CA::OGL::FilterNode::apply(float, CA::OGL::Surface**, float*) () #7 0x7fff83e816e4 in CA::OGL::ImagingNode::render(CA::OGL::ImagingNode::RenderClosure*, unsigned int) () #8 0x7fff83e88498 in CA::OGL::ImagingNode::retain_surface(float&, unsigned int) () #9 0x7fff83e815a0 in CA::OGL::ImagingNode::render(CA::OGL::ImagingNode::RenderClosure*, unsigned int) () #10 0x7fff83e8148d in CA::OGL::render_layers(CA::OGL::Renderer&, CA::OGL::Layer*) () #11 0x7fff83e829d5 in CA::OGL::LayerNode::apply(float, CA::OGL::Surface**, float*) () #12 0x7fff83e816e4 in CA::OGL::ImagingNode::render(CA::OGL::ImagingNode::RenderClosure*, unsigned int) () #13 0x7fff83e88498 in CA::OGL::ImagingNode::retain_surface(float&, unsigned int) () #14 0x7fff83e883e3 in CA::OGL::LayerNode::retain_surface(float&, unsigned int) () #15 0x7fff83e815a0 in CA::OGL::ImagingNode::render(CA::OGL::ImagingNode::RenderClosure*, unsigned int) () #16 0x7fff83e8148d in CA::OGL::render_layers(CA::OGL::Renderer&, CA::OGL::Layer*) () #17 0x7fff83e829d5 in CA::OGL::LayerNode::apply(float, CA::OGL::Surface**, float*) () #18 0x7fff83e816e4 in CA::OGL::ImagingNode::render(CA::OGL::ImagingNode::RenderClosure*, unsigned int) () #19 0x7fff83e8148d in CA::OGL::render_layers(CA::OGL::Renderer&, CA::OGL::Layer*) () #20 0x7fff83e829d5 in CA::OGL::LayerNode::apply(float, CA::OGL::Surface**, float*) () #21 0x7fff83e816e4 in CA::OGL::ImagingNode::render(CA::OGL::ImagingNode::RenderClosure*, unsigned int) () #22 0x7fff83e8148d in CA::OGL::render_layers(CA::OGL::Renderer&, CA::OGL::Layer*) () #23 0x7fff83e829d5 in CA::OGL::LayerNode::apply(float, CA::OGL::Surface**, float*) () #24 0x7fff83e816e4 in CA::OGL::ImagingNode::render(CA::OGL::ImagingNode::RenderClosure*, unsigned int) () #25 0x7fff83e8148d in CA::OGL::render_layers(CA::OGL::Renderer&, CA::OGL::Layer*) () #26 0x7fff83e7d53a in CA::OGL::render_root_layers(CA::OGL::Renderer&, x_link_struct const*, CA::OGL::Gstate const&) () #27 0x7fff83e75426 in CA::OGL::Renderer::render(CA::Render::Update const*) () #28 0x7fff83e75109 in CA::OGL::render(CA::OGL::Renderer&, CA::Render::Update*) () #29 0x7fff83e62855 in view_draw(_CAView*, double, CVTimeStamp const*, bool) () #30 0x7fff83e61d1d in view_display_link(double, CVTimeStamp const*, void*) () #31 0x7fff83e61bdf in link_callback () #32 0x7fff8f9763ba in CVDisplayLink::performIO(CVTimeStamp*) () #33 0x7fff8f975f45 in CVDisplayLink::runIOThread() () #34 0x7fff8f9759a9 in startIOThread(void*) () #35 0x000100beb815 in _pthread_body () #36 0x000100beb792 in _pthread_start () #37 0x000100be8fad in thread_start () -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 10.11 app crashes in [CIImage createCIImageWithSurfaceBytes:::::]
Hi, On 05/10/15 15:50, Markus Spoettl wrote: 2015-10-05 15:41:23.084 myApp[2807:50961] +[CIImage createCIImageWithSurfaceBytes:bytesPerRow:x:y:width:height:colorSpace:transform:]: unrecognized selector sent to class 0x7fff742101e0 2015-10-05 15:41:44.560 myApp[2807:50961] CoreAnimation: ignoring exception: +[CIImage createCIImageWithSurfaceBytes:bytesPerRow:x:y:width:height:colorSpace:transform:]: unrecognized selector sent to class 0x7fff742101e0 Updated to VMWare 8.0.1, still the same glitches and crashes. Any pointers would be appreciated. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 10.11 app crashes in [CIImage createCIImageWithSurfaceBytes:::::]
On 05/10/15 15:50, Markus Spoettl wrote: Any idea what is going on? I'm running El Capitan in a VMware Fusion 7 that runs on Yosemite, could this be cause of the crash? Turns out it's VMware, the app works fine on a real machine. Sorry for the noise. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Preventing Document from closing
Hi, in an NSDocument based application, is there a reliable way to prevent a document from closing and the app itself from terminating? I'm having a very difficult time understanding now -canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo: is supposed to work. Contrary to the documentation, the selector that is passed in is this _something:didSomething:soContinue: and not as the documentation indicates document:shouldClose:contextInfo: Every time I try to make sense of this and the header comments, my head starts spinning. Some background: In some circumstances, my app needs to update the model in a background task to get its data into a consistent state after some other model properties change. When this happens, I want to prevent the app from terminating and the document from being closed. I don't want to debate whether this is a good idea/good design or not (I know I could serialize the background task states and restart when the app restarts them but I really really really don't want to do that), I would like to know if there's a reliable way to prevent document closure. Thanks for any suggestions! Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Preventing Document from closing
Hi Quincey, On 04/04/15 10:16, Quincey Morris wrote: [...] [..life saving code snipped..] [...] The first branch of the ‘if’ statement is the code you want, that prevents the document from closing. Note that it doesn’t involve a separate method. Rather, it just invokes the supplied selector but changes one of the parameters to NO. The else branch is the code you would use if you wanted to have to document do something before actually closing the document. In my case, I wanted to invoke a ‘willClose’ method first. The reason this part is so much more complicated is that it hasn’t been determined yet whether the document *will* close — that doesn’t happen until the supplied selector is invoked. So, my own method’s selector replaces the supplied selector in the ‘super’ invocation, and my method invokes the originally supplies selector when it’s done messing around. Hope that makes sense. It *is* a little confusing. :) It does and it's perfect! Thanks so much Quincey! This list would be in much trouble without you - at least I would be! Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Weird crashes on Yosemite
On 13/03/15 16:11, Peter Hudson wrote: Thanks for these suggestion Steve and Markus. The table datasource and delegate code has been running very sweetly for a number of years and has not been changed since it was written some time back. We had a similar crashs when running our app on Yosemite (even with unchanged code compiled against the 10.9 SDK). The table wind-down behavior seems to have changed slightly which can trigger this in code that worked fine forever. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Weird crashes on Yosemite
On 13/03/15 15:46, Peter Hudson wrote: Any comments or suggestions gratefully received ! Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27 1 com.apple.AppKit0x9184a305 -[NSTableView _dataSourceValueForColumn:row:] + 69 2 com.apple.AppKit0x9194e127 -[NSTableView preparedCellAtColumn:row:] + 385 3 com.apple.AppKit0x917efc91 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878 4 com.apple.AppKit0x917ef6de -[NSTableView _windowChangedKeyState] + 323 This looks like a table's delegate or datasource has been disposed off while the table still uses it. Make sure to set table delegates/datasources to nil when the object being used as delegate/datasource is deallocated. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Drawing inside an NSImage?
On 09/03/15 00:12, Patrick J. Collins wrote: [_image lockFocus]; [[NSColor blueColor] set]; NSBezierPath *line = [NSBezierPath bezierPath]; NSPoint pointA = NSMakePoint(0, 0); NSPoint pointB = NSMakePoint(self.bounds.size.width, 0); [line moveToPoint:pointA]; [line lineToPoint:pointB]; [line stroke]; What am I doing wrong here? If that's your real code, you need to call [_image unlockFocus] after you are done painting the content of the image to balance the call to -lockFocus. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Color fun with IBOutlet named appNameLabel
Hi Graham, On 23/02/15 00:18, Graham Cox wrote: Are you certain they're set up identically? I noticed a similar thing recently with some labels coming up black and others responding to a change in highlighting (these were part of a view-based table row) by changing to white. I thought all of my labels were created equal, but on closer examination I found that for some of them were set to use 'Label Color' and others used 'Control Text Color'. Only the latter responds dynamically to highlighting/background changes - at least in a table row. Most controls use the latter setting, but Labels don't. Having spotted it I fixed it and moved on without further investigation. I created the labels using IB's 'label' object which defaults to Label Color, changing this to Control Text Color fixed the issue. I'm pretty certain that's not it. First I copied an existing label (that was colorized correctly) and connected the new label to a new outlet. When that showed the colorization issue, I started to try all kinds of things, including swapping outlets without changing either code or NSTextFields at all. The color change moved along as I connected different labels to the offending outlet name. Finally, I moved to a different window controller in my app and renamed an outlet, and sure enough the color change materialized. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Color fun with IBOutlet named appNameLabel
On 10/02/15 15:34, Markus Spoettl wrote: I have an about window with a label for the app name on it. That label was connected to an outlet named appNamelabel on its window controller. There are a couple of other labels on the same window, connected to other outlets. The labels are all inside an NSVisualEffectsView which is in behind window mode with dark appearance. So all labels are white-ish. Almost. The app name label is black instead of white (despite being set up identically to the other labels on the window). I spent the last couple of hours trying to make sense of it. Then I renamed the outlet to nameLabel, bingo! For some inexplicable reason NSWindowController (or whatever) sets the label color based on the outlet name. Aaahhhrrrgg. This is on Yosemite, Xcode 6.1.1. Purely informational in case someone else encounters this. Seems like addressLabel is another magic IBOutlet name that triggers the color-setting behavior. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Modernising dragging problem
On 01/02/15 23:06, Graham Cox wrote: On 1 Feb 2015, at 5:23 am, Markus Spoettl ms_li...@shiftoption.com wrote: I did the same conversion a while back and have had no such issue. I found it completely straight forward and surprisingly painless. Are you sure you're implementing all the required protocols? + In the view starting dragging NSDraggingDestination (if it wants to receive something, too), also are you calling -registeringForDraggedTypes: in that view + In you object you're calling obj NSPasteboardWriting + In the object you're calling source NSDraggingSource In my implementation obj and source are the same object, but that should not matter. Looking at my code, I think that's all the needs to be done. Hi Markus, Yes, I'm conforming to all the protocols, and I'm registering for the dragged types - actually that pertains to receiving only, but I can drag and receive the same types. Temporarily turning off the registering for dragged types (so that the same view won't immediately start responding to the drag it started) doesn't fix things, so that isn't a cause of what I'm seeing. It's most odd - nothing is logged that might give a clue. The legacy code still works perfectly. I agree, it's odd. Maybe something wrong with the image (unlikely if the code you posted is what you're using and it's working with the old API)? If nothing else helps: Did you try turning it off and on again?™ Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Modernising dragging problem
On 31/01/15 00:15, Graham Cox wrote: I'm updating some older code that uses the now-deprecated [NSView dragImage:at:offset:pasteboard:source:slideback:] to use NSDraggingSession and pals. Note that this older code works just fine, I've never had any issues with it. I'm doing this mostly just to clear out compiler warnings, though my instinct tells me not to fix code that isn't broken. Sadly its replacement is broken. I did the same conversion a while back and have had no such issue. I found it completely straight forward and surprisingly painless. Are you sure you're implementing all the required protocols? + In the view starting dragging NSDraggingDestination (if it wants to receive something, too), also are you calling -registeringForDraggedTypes: in that view + In you object you're calling obj NSPasteboardWriting + In the object you're calling source NSDraggingSource In my implementation obj and source are the same object, but that should not matter. Looking at my code, I think that's all the needs to be done. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Search for emails in Mail’s previous recipients list from MacOSX app
On 15/01/15 22:04, Steffen Andersen wrote: I am currently working on a MacOSX app, where the user will be able to send mails generated based on different user input. To help the user, when writing an email address, it would be great, if it was possible to search in the previous recipients list/db Mail uses. As not all emails will be in the users Contacts. From a bit of search I’ve located the previous recipients list/db ~/Library/Containers/com.apple.corerecents.recentsd/Data/Library/Recents/Recents and it seems to be a sqlite. Is there any issues accesses it from with in an app, if I want to launch the app to AppStore? You can't access such data (data in containers of other apps, or data in the general Library folder) in sandboxed apps. Apps on the Mac App Store need to be sandboxed. There are only a handful of paths you can access with the appropriate entitlements in place (pictures, downloads, music, movies). Other paths require explicit user consent and the only way to get that is having the user point to the path in an open/save sheet/panel. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Mouse tracking under a transparent view still working
On 11/01/15 07:12, Navneet Kumar wrote: So the mouse click etc are not passing through, but the hover button under it still shows hovering effect by drawing the border. You probably need to establish a tracking area on the view that is supposed to absorb the mouse events. The reason is that -mouseMoved: events will not automatically be called just by implementing the event method (unlike the other mouse methods), you need a tracking area for that to work. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Blurry is the New Sharp
On 05/01/15 19:32, Georg Seifert wrote: I guess the best we can do as developers is to vote with our feet by not adopting it in our apps. (I haven't had to deal with an OS X source list in a while; I assume vibrancy has to be opted into? Or at least there's a way to opt out?) No, it is on by default and no way (that I know of, and I would be very happy to be proven wrong) to opt out. If you are referring to opting out of translucency in the tree/outline view, you can get rid of the effect by setting its background color to nil or something else. I find translucency (which I think is what people really talk about in this thread when mentioning vibrancy) can greatly benefit a UI when applied sensibly but the fact that there is no way to tell tree/outline views to use VIEW background instead of WINDOW background, is, frankly, an outrage. If you want translucent VIEW background on an outline view, you actually need to put the outline in inside a NSVisualEffectsView container. Even though the tree/outline does this automatically, you just don't have any control over it. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Weird crash in FSRefCreate while saving NSDocument
On 24/11/14 14:54, Scott Ribe wrote: So I have no idea if this is related or not. But a few things for you to possibly find out: is there a lot of file manipulation being done on that Mac, is performance of everything sluggish before this happens, and will it work after a reboot. My user says he doesn't experience sluggishness, he also tried rebooting the machine and repair the disk permissions. Still crashes reliably every time. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Weird crash in FSRefCreate while saving NSDocument
On 25/11/14 15:28, Scott Ribe wrote: On Nov 25, 2014, at 1:26 AM, Markus Spoettl ms_li...@shiftoption.com wrote: My user says he doesn't experience sluggishness, he also tried rebooting the machine and repair the disk permissions. Still crashes reliably every time. In that case, I'd personally suspect heap corruption. That hits only one user out of many? All the time, whenever he uses it, and no one else. Caused by other apps or ours? Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Weird crash in FSRefCreate while saving NSDocument
Hello, I have a user who keeps crashing our app by saving his NSDocument (file wrapper based). I can't make any sense of it and he's the only one who runs into this, apparently. I'm attaching the call stack of the crash in the hope that someone on the list recognizes it. Any ideas what might be going on? Regards Markus Crashed Thread:5 Dispatch queue: com.apple.root.default-qos Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0048 VM Regions Near 0x48: -- __TEXT 00010d12f000-00010d539000 [ 4136K] r-x/rwx SM=COW /Applications/My.app/Contents/MacOS/My Thread 5 Crashed:: Dispatch queue: com.apple.root.default-qos 0 com.apple.CoreServices.CarbonCore 0x7fff8a120b20 FSRefCreate + 56 1 com.apple.CoreServices.CarbonCore 0x7fff8a11f174 FSPathMakeRefInternal(unsigned char const*, unsigned int, unsigned int, FSRef*, unsigned char*) + 247 2 com.apple.CoreFoundation0x7fff940b3984 _CFGetFSRefFromURL + 228 3 com.apple.CoreFoundation0x7fff940b3885 CFURLGetFSRef + 37 4 com.apple.LaunchServices 0x7fff8b713337 ___LSGetStrongBindingForRef_block_invoke + 61 5 com.apple.LaunchServices0x7fff8b74e922 _LSShimFSRef + 68 6 com.apple.LaunchServices0x7fff8b7132f4 _LSGetStrongBindingForRef + 68 7 com.apple.CoreServicesInternal 0x7fff90f9c054 _URLReplaceObject + 7423 8 com.apple.CoreFoundation0x7fff9417c382 _CFURLReplaceObject + 114 9 com.apple.Foundation 0x7fff90604999 -[NSFileManager replaceItemAtURL:withItemAtURL:backupItemName:options:resultingItemURL:error:] + 248 10 com.apple.Foundation 0x7fff90728466 +[NSFileWrapper(NSInternalForAppKit) _finishWritingToURL:byTakingContentsFromItemAtURL:addingAttributes:usingTemporaryDirectoryAtURL:backupFileName:error:] + 114 11 com.apple.AppKit 0x7fff95fda777 -[NSDocument _finishWritingToURL:byTakingContentsFromItemAtURL:replacingOriginalItemAtURL:addingAttributes:usingTemporaryDirectoryAtURL:backupFileName:error:] + 155 12 com.apple.AppKit 0x7fff95fdc987 __86-[NSDocument _writeSafelyToURL:ofType:forSaveOperation:forceTemporaryDirectory:error:]_block_invoke + 819 13 com.apple.AppKit 0x7fff95fdc361 -[NSDocument _writeSafelyToURL:ofType:forSaveOperation:forceTemporaryDirectory:error:] + 2120 14 com.apple.AppKit 0x7fff95fdcb93 -[NSDocument _writeSafelyToURL:ofType:forSaveOperation:error:] + 28 15 com.apple.AppKit 0x7fff95fdcd01 -[NSDocument writeSafelyToURL:ofType:forSaveOperation:error:] + 357 16 com.apple.AppKit 0x7fff95fe9fc5 __66-[NSDocument saveToURL:ofType:forSaveOperation:completionHandler:]_block_invoke_22307 + 240 17 libdispatch.dylib 0x7fff8e15d323 _dispatch_call_block_and_release + 12 18 libdispatch.dylib 0x7fff8e158c13 _dispatch_client_callout + 8 19 libdispatch.dylib 0x7fff8e15b88f _dispatch_root_queue_drain + 935 20 libdispatch.dylib 0x7fff8e169fe4 _dispatch_worker_thread3 + 91 21 libsystem_pthread.dylib 0x7fff895936cb _pthread_wqthread + 729 22 libsystem_pthread.dylib 0x7fff895914a1 start_wqthread + 13 -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Weird crash in FSRefCreate while saving NSDocument
On 24/11/14 14:54, Scott Ribe wrote: On Nov 24, 2014, at 3:03 AM, Markus Spoettl ms_li...@shiftoption.com wrote: I'm attaching the call stack of the crash in the hope that someone on the list recognizes it. Any ideas what might be going on? Is this 10.10? And the libs are still using FSRef underneath their implementations??? Sorry forgot to mention it, yes, this is on 10.10.1. Hoo boy. I've seen 10.10 get into a state where FSPathMakeRef will report fnfErr when the file is sitting right there, with correct permissions. In fact, you can stat the file without error, then immediately call FSPathMakeRef with the same path, and get an error. (Full path, only a-z 0-9 in any of the names...) I've also seen the case of: 1) get an FSRef, 2) create a new file elsewhere, 3) FSRefMakePath on the FSRef now fails. Unfortunately I haven't been able to figure out anything about the circumstances except that PID 1 was going crazy at the time, and a reboot fixed everything. I simply eliminated all my FSRef code, which I had intended to do RSN anyway, and replaced with plain POSIX stuff. But if 10.10 is using FSRefs in the implementation of Cocoa, I guess other people are going to trip over the bugs... So I have no idea if this is related or not. But a few things for you to possibly find out: is there a lot of file manipulation being done on that Mac, is performance of everything sluggish before this happens, and will it work after a reboot. OK, thanks, it's a start! I'll try to get my user to try this. I'll report back if that changes anything. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Heavy flickering on Retina Macs with Yosemite NSVisualEffectView overlay windows
On 18/09/14 19:43, Kyle Sluder wrote: When an OS gets towards release, I notice a sharp increase in the likelihood of my bug report getting intercepted and returned by bug screeners. This is a function of a management, not engineering, and I gather their job is to swat bugs away from the engineers so they can focus on getting the release out the door. Unfortunately I fear the screeners are in a similar position as customer “service” agents—that is, under constant pressure to resolve bugs quickly, and either explicitly or implicitly encouraged to close bugs for the sake of meeting some kind of performance metric. Part of the role of Evangelists is to sidestep this process: they are technically skilled and politically empowered to put important bugs under the engineering managers’ noses. Likewise for Relationship Managers, if you have one. This sounds like a big enough issue that you might want to flag Jake Behrens, the UI and App Frameworks Evangelist: behr...@apple.com If this doesn’t fall under his purview, he’ll at least be able to forward you to the right person. Thanks, I sent an email as suggested. I appreciate your help with this issue, lets hope they can fix this (or tell us how to fix it). Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Heavy flickering on Retina Macs with Yosemite NSVisualEffectView overlay windows
On 19/09/14 18:39, Jens Alfke wrote: FWIW, I've seen standard UI controls (esp. progress bars) in Apple apps go into this kind of super-flickery state in Yosemite on my Retina MBP. I've been assuming it's a WindowServer or graphics driver bug. (No, I didn't file a Radar. It was sufficiently common and glaring that I assumed it was something everyone saw knew about.) It's DP8 and they have less then 1 month to gold (presumably), I'm not sure that this is a glaring issue everyone is encountering. I would think they don't wait until the very last minute to fix that sort of thing if they knew about it. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Heavy flickering on Retina Macs with Yosemite NSVisualEffectView overlay windows
On 17/09/14 17:32, Kyle Sluder wrote: Your video won’t play on my phone. But honestly, if you’re not doing anything particularly advanced (as in the OpenGL or CGDirectDisplay level), then the symptoms you describe should not appear and you ought to file a bug. You might consider simply attaching your current project (along with screenshots and/or a version of your movie you know to work) before bothering to make a demo app. Be sure to include your system configuration—this is one case where it really matters, and you don’t want to burn time waiting for a bug screener’s “please attach a system configuration” reply. I filed a bug, lets hope they can recreate using the app, video, test data and system configuration I supplied. The last two times I did this in the last couple of weeks, I got a response that indicated they didn't even read the first line of the steps (which says unzip the attached app and start it) by requesting an app to reproduce the issue. I find the whole experience extremely unrewarding, rude and very deterring. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Heavy flickering on Retina Macs with Yosemite NSVisualEffectView overlay windows
Hello, On 16/09/14 16:28, Markus Spoettl wrote: using Yosemite DP8 (first tested and observed with DP7), we get very heavy flickering when animating a popup overlay window over a window whose content consists of views sitting on NSVisualEffectViews (NSVisualEffectBlendingModeWithinWindow) and with a transparent window title bar and toolbar. What happens is that the area behind the popup window that is being animated into view (animating window frame and alpha) briefly blacks out with a opaque completely black fill. Sometimes it resembles the shape of the popup window, sometimes it doesn't, sometimes areas not covered by the popup window flicker. I made a short demo video illustrating the problem: http://www.shiftoption.com/images/flickering.mov Anyone any idea what might cause this? Maybe a overwhelmed graphics unit? A driver bug? It also sometimes happens when the window becomes active or inactive, for example when tabbing through apps. Then larger areas of the window briefly get blacked out. It only happens on the Retina MacBook (Mid 2012), I don't have any other retina display hardware here to try other machines. Any pointers would be highly appreciated! Thanks Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Heavy flickering on Retina Macs with Yosemite NSVisualEffectView overlay windows
Hello, using Yosemite DP8 (first tested and observed with DP7), we get very heavy flickering when animating a popup overlay window over a window whose content consists of views sitting on NSVisualEffectViews (NSVisualEffectBlendingModeWithinWindow) and with a transparent window title bar and toolbar. What happens is that the area behind the popup window that is being animated into view (animating window frame and alpha) briefly blacks out with a opaque completely black fill. Sometimes it resembles the shape of the popup window, sometimes it doesn't, sometimes areas not covered by the popup window flicker. This is on a MacBook Pro 15 Retina Mid 2012. On a non-retina MacBook 17 from early 2011 no flickering is observable. To my knowledge the Retina MacBook doesn't have a discrete graphics hardware, the non-retina one does. Before I go an distill a reproducible test project - which could take a lot of time if it turns out to be reproducible at all - I was wondering if someone else noticed that too. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
10.10 NSSlider continuous mode sends gazillions of action messages
Hi, for some reason NSSlider set up to send continuous action messages sends a much higher number action messages (10 times as many) than it previously did. This affects not only apps linked against 10.10 but also ones that link against 10.9. Is this intentional? The AppKit release notes don't mention a change in NSSlider. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
CATransaction ignores animationDuration executes completionBlock immediately
Hi,
I have view that animates layers using CATransaction with nested animations
in their respective completion blocks. For some reason the outermost transaction
consistently ignores the animation duration and calls the completion block
immediately after the transaction is committed.
What I'm trying to do is to animate my layer from
initialTransform - expandedTransform - normalTransform
What actually happens is that the layer goes directly to
expandedTransform - normalTransform
completely omitting the animation from initialTransform - expandedTransform
The actual code looks like this:
// setup transaction, no animation
[CATransaction begin];
[CATransaction setDisableActions:YES];
[CATransaction setCompletionBlock:^{
// reveal transaction step 1
[CATransaction begin];
[CATransaction setCompletionBlock:^{
// reveal transaction step 2
[CATransaction begin];
[CATransaction setCompletionBlock:^{
// do cleanup work here
}];
[CATransaction setAnimationTimingFunction:
[CAMediaTimingFunction
functionWithName:kCAMediaTimingFunctionEaseInEaseOut]];
[CATransaction setAnimationDuration:1.0];
[layer setTransform:normalTransform];
[CATransaction commit];
}];
[CATransaction setAnimationTimingFunction:
[CAMediaTimingFunction
functionWithName:kCAMediaTimingFunctionEaseInEaseOut]];
[CATransaction setAnimationDuration:1.0];
[layer setTransform:expandedTransform];
[CATransaction commit];
}];
[layer setBounds:someBounds];
[layer setPosition:somePosition];
[layer setTransform:initialTransform];
[CATransaction commit];
If I wrap the whole thing in another empty CATransaction, putting the code into
its completion block, it works.
What is the mistake here?
Regards
Markus
--
__
Markus Spoettl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Yosemite API discussions
Hi, since the OSX-beta devforum is virtually dead from a developer perspective, the only legal way to ask questions is using the black hole that is bugreporter. Lacking better alternatives, I reported several things (mostly related to new NSWindow features), even got feedback on one (though that took a week and the feedback was something like Is this really a problem for you?). Hardly a healthy conversion. Without proper feedback from peers or Apple how is this supposed to work? Not every detail is covered in the WWDC videos. Is there a better place where NDA-covered discussion is allowed *and* alive? I find it really really frustrating that this is being made so difficult. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Offsetting content of NSTable/NSOutlineView
Hi, is there any way to insert a margin above the first row of an NSOutlineView in a way that when scrolling (in my case Y-axis only) it will scroll the content through its margin but when at topmost position, will leave the margin, effectively offsetting the content and scroller downwards by the margin. I can almost achieve the desired effect by returning an increased row height in -outlineView:heightOfRowByItem: by the desired margin for only the first row. Problem is the scroller still spans the entire height of the view. The background of this is that a certain new OSX version has a nice feature that allows your window's contentView to span the entire window, underneath the title and toolbar area (you probably have seen it in the WWDC keynote or technical videos). The effect I'm after actually is implemented by NSTable/OutlineView when the window doesn't use the full-size contentView and the scrollView starts right below the title bar. However, I do need a full-size contentView and in that case, I don't know how to achieve it. So it might be plain obvious how to do this kind of offsetting (even in 10.9) but I failed to find out how. Before anyone suggests asking in the devforums, I did. It appears that any technical questions by developers are completely ignored there. I'm beginning to think there is a secret place where Apple directs people they want to hear feedback from. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Offsetting content of NSTable/NSOutlineView
On 25/06/14 15:45, Keary Suska wrote: This is just a wild stab, but have you considered/tried using a custom header view? I believe NSTableView is smart enough to accommodate a larger header. Then the only issue is making the visual/size changes when scrolling happens. That could work (or so I thought) and I just tried but it seems like changing the frame of the header view (in order to shrink it dynamically based on the clipview's bounds) from outside the table view isn't working. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Differences in string handling for NSString and NSAttributedString
On 5/5/14, 6:27 PM, Pax wrote: I believe that this should cause IMAGE HERE to be inserted at specific line endings. However, it often inserts into the middle of a paragraph instead - usually, but not always, close to where it should put the text. Furthermore, the positioning is usually at, or very close, to the correct location for the first instance of image insertion - and it gets progressively less accurate as it gets through the text. Is there some difference between the ways that strings are handled in NSAttributedString and NSString? Could there be some problem with characters like Non-Breaking Space? You should probably reverse the order in which you insert strings/images/stuff. Whenever you insert something, the insert locations that follow this location calculated before inserting a new item will move backwards. A simple way to get around this is to reverse the insert order, starting at the last index and moving towards 0. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: iOS: Cannot connect to iTunes Store
On 4/11/14, 1:41 AM, Steve Christensen wrote:
I’ve been testing IAP in the sandbox store on a development iPod and just
started getting this error in -paymentQueue:updatedTransactions: with
(transaction.transactionState == SKPaymentTransactionStateFailed):
Error Domain=SKErrorDomain Code=0 Cannot connect to iTunes Store
UserInfo=0x1aa5e060 {NSLocalizedDescription=Cannot connect to iTunes Store}
[...]
Does anyone have an idea of what else I should be checking?
I had the same thing for a couple of hours yesterday morning. I then removed all
incarnations of my app (a lot of different beta builds and an app-store
downloaded version) from the development machine, restarted the Mac (to make
absolutely sure storeagent doesn't cache things) and waited for 2 hours.
One of the things solved the issue.
Whenever something unexpected happens, a lot of times I find myself killing
storeagent and storehelper using the Activity Monitor. That helps sometimes.
Regards
Markus
--
__
Markus Spoettl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSDocument save incremental file package in-place
On 3/2/14 12:06 AM, Quincey Morris wrote: I’ve never used this, but I *have* seen documents use hard linking anyway (though, on reflection, that might have been UIDocument, not NSDocument — I’m not sure now). No, it is NSDocument/NSFileWrapper, UIDocument/NSFileWrapper doesn't know this kind of trick. Not sure why it's not working for the OP it certainly works fine for my app. Works fine meaning it saves package files containing hundreds of megabytes of data with thousands of files and folders in a fraction of a second (depending on how much content changed, of course): You basically need to overwrite: - (BOOL)readFromFileWrapper:(NSFileWrapper *)fileWrapper ofType:(NSString *)typeName error:(NSError **)outError for loading (and stashing the original wrapper reference) and - (NSFileWrapper *)fileWrapperOfType:(NSString *)typeName error:(NSError **)outError to return the original wrapper with all necessary changes to its subwrappers applied. You also need to overwrite - (void)setFileURL:(NSURL *)absoluteURL in which you call super and then update your stored wrapper (if you have one already) using -[NSFileWrapper readFromURL:options:error:]. You need to do this because the filewrapper you return in -fileWrapperOfType:: gets written to a temp location and moved in place. That causes all references to all the files and folders the wrapper and its subwrappers point to to move and to become invalid as a result, once the save is complete. Updating ensures the references are valid for the next go. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSDocument save incremental file package in-place
On 3/2/14 3:43 PM, Trygve Inda wrote: -Root - plist file (about 20mb) - Folder containing 3750 image files of about 50kb each - Folder containing 3750 image files of about 100kb each I did some testing about optimal number of files per folder for our package format and 3750 files per directory are way too many. The file system is much more efficient if you spread those files into sub-folders. We got the best performance with a 3-level sparse folder index (files are stored on the third folder level). Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSDocument save incremental file package in-place
On 3/2/14 5:22 PM, Trygve Inda wrote: I did some testing about optimal number of files per folder for our package format and 3750 files per directory are way too many. The file system is much more efficient if you spread those files into sub-folders. We got the best performance with a 3-level sparse folder index (files are stored on the third folder level). That's interesting. If I cut the files to 1875 per folder, the save takes half as long. The time cost seems very linear. What did you find to be a good max per folder? Can't say, probably less than 100 per folder. It's easy to find out, though, just create different layouts and see which one is getting saved most quickly. I can remember that we experimented extensively with the number of index levels (each level having 16 potential slots) and 3 turned out to work best for us for reading and writing. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
How to avoid exceptions when decoding incomprehensible archives
Hello, is there a way to stop NSKeyedArchiver from bombing out with an exception, crashing the app along with it, when it tries to decode an archive that it deems incomprehensible? From time to time we get support requests about crashes that originate basically in damaged archives (binary encoded). It would be much nicer if there would be a graceful way of handling this. Is an exception handler the only way to do that? Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Crash in -URLByResolvingBookmarkData::::: in sandboxed app
Hi,
I keep getting a crash in my sandboxed app when it terminates. It is not 100%
reproducible, but it happens a couple of times a day while working on the app,
both when run from Xcode and started from Finder.
Part of the termination cleanup requires me to decode a bookmark that was stored
in the user defaults previously (same app, same session).
NSData *data = [[NSUserDefaults standardUserDefaults] objectForKey:@mykey];
if ((data != nil) ([data isKindOfClass:[NSData class]])) {
BOOL stale = NO;
result = [NSURL URLByResolvingBookmarkData:data
options:NSURLBookmarkResolutionWithoutUI |
NSURLBookmarkResolutionWithoutMounting |
NSURLBookmarkResolutionWithSecurityScope
relativeToURL:nil
bookmarkDataIsStale:stale
error:error];
}
I call this same method in various places and it works fine, but during app
termination it sometimes just crashes.
Has anyone seen this? If so, is there any way to avoid it crashing like that?
I'm on OSX 10.8.5 with Xcode 4.6.3, base SDK is 10.7.
Regards
Markus
The exception details and callstack of the crash is this:
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0002, 0x
Application Specific Information:
*** __CFTypeCollectionRetain() called with NULL; likely a collection has been
corrupted ***
Performing @selector(terminate:) from sender NSMenuItem 0x7fb330c2aef0
#0 0x7fff94b92711 in __CFTypeCollectionRetain ()
#1 0x7fff94bbfac2 in __CFDictionaryRetainValue ()
#2 0x7fff94b91b8a in __CFBasicHashAddValue ()
#3 0x7fff94b98268 in CFBasicHashAddValue ()
#4 0x7fff94bcbe5f in CFDictionaryCreate ()
#5 0x7fff94bd273c in CFErrorCreateWithUserInfoKeysAndValues ()
#6 0x7fff95107ff2 in reportErrorForURL(__CFError**, long, __CFURL
const*) ()
#7 0x7fff950ef037 in _CFURLCreateByResolvingBookmarkData ()
#8 0x7fff94c4ae5e in +[NSURL
URLByResolvingBookmarkData:options:relativeToURL:bookmarkDataIsStale:error:] ()
#9 0x000100113588 in -[MyController getURL] at
/Users/markus/Projects/MyController.m:187
--
__
Markus Spoettl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: makeDocumentForURL:nil withContentsOfURL:fileURL causing deletion
On 2/8/14 8:43 PM, Trygve Inda wrote:
I am reading a document in the format of the old version of my app and
converting it to a new format. The old version is not a document at all but
is a fixed data file in /Application Support/MyApp/
MyDocument *untitledDoc = [[NSDocumentController sharedDocumentController]
makeDocumentForURL:nil withContentsOfURL:fileURL
ofType:kApplicationDocumentType error:error];
if (untitledDoc)
{
[untitledDoc makeWindowControllers];
[untitledDoc showWindows];
[untitledDoc setFileURL:nil];
[[NSDocumentController sharedDocumentController] addDocument:(NSDocument
*)untitledDoc];
}
I have something similar (loading an old file into a document with blank file
URL) but instead of do driving the whole documentation creation manually, I let
AppKit do it the way it wants to do it.
In other words, have you tried calling -openDocument: on your
NSDocumentController setting fileURL to nil when it is done?
Markus
--
__
Markus Spoettl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: makeDocumentForURL:nil withContentsOfURL:fileURL causing deletion
On 2/8/14 9:31 PM, Markus Spoettl wrote:
On 2/8/14 8:43 PM, Trygve Inda wrote:
I am reading a document in the format of the old version of my app and
converting it to a new format. The old version is not a document at all but
is a fixed data file in /Application Support/MyApp/
MyDocument *untitledDoc = [[NSDocumentController sharedDocumentController]
makeDocumentForURL:nil withContentsOfURL:fileURL
ofType:kApplicationDocumentType error:error];
if (untitledDoc)
{
[untitledDoc makeWindowControllers];
[untitledDoc showWindows];
[untitledDoc setFileURL:nil];
[[NSDocumentController sharedDocumentController] addDocument:(NSDocument
*)untitledDoc];
}
I have something similar (loading an old file into a document with blank file
URL) but instead of do driving the whole documentation creation manually, I let
AppKit do it the way it wants to do it.
In other words, have you tried calling -openDocument: on your
NSDocumentController setting fileURL to nil when it is done?
Meant to say -openDocumentWithContentsOfURL:::
Markus
--
__
Markus Spoettl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSToolbar delegate -toolbarAllowedItemIdentifiers:
On 2/8/14 12:25 AM, Quincey Morris wrote: It’s a while since I had to suffer through the pain that is NSToolbar delegate methods, but I suspect the problem is that the IB-created items are in a different universe from programmatically created ones. Therefore, in a “mixed” configuration, ‘toolbarAllowedItemIdentifiers:’ is queried only to supply the identifiers of non-IB items that you want to add to the IB-defined toolbar. The delegate method is, after all, optional *in this case*. If that’s correct, and you have a toolbar whose items are allowed in a *contextually* dependent way, you’ll have to create the toolbar contents programmatically — or at least those items. Note that I’m speculating. I vaguely recall that there was something very horrible about mixing IB and non-IB items, and this may or may not be it. Yes, horrible comes to mind. I ended up duplicating the entire toolbar so it's constructed at runtime - with embedded segmented controls that's a lot of fun. That was only way to make it work. Unfortunately I can't even use the same toolbar identifier (for auto-configuration saving purposes), because even though -toolbarAllowedItemIdentifiers: returns a reduced set, NSToolbar will reconstruct items with identifiers not currently allowed when restoring a toolbar configuration that was stored when all items were allowed. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSToolbar delegate -toolbarAllowedItemIdentifiers not getting called, other delegate methods are
Hi, I have a strange problem with a toolbar that is configured in IB which I need to adjust programmatically. It has a delegate set (to the window controller) but for some reason - (NSArray *)toolbarAllowedItemIdentifiers:(NSToolbar*)toolbar is never getting called. Other delegate methods such as - (NSArray *)toolbarDefaultItemIdentifiers:(NSToolbar *)toolbar are getting called. I need to adjust (restrict) the allowed items under certain circumstances and there's no other way to do that. Does anyone have an idea what might be wrong? This is with Xcode 4.6.3, OSX 10.7 base SDK, running on Mountain Lion. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSToolbar delegate -toolbarAllowedItemIdentifiers not getting called, other delegate methods are
On 2/7/14 10:31 PM, Markus Spoettl wrote: Hi, I have a strange problem with a toolbar that is configured in IB which I need to adjust programmatically. It has a delegate set (to the window controller) but for some reason - (NSArray *)toolbarAllowedItemIdentifiers:(NSToolbar*)toolbar is never getting called. Other delegate methods such as - (NSArray *)toolbarDefaultItemIdentifiers:(NSToolbar *)toolbar are getting called. I need to adjust (restrict) the allowed items under certain circumstances and there's no other way to do that. Of course I spoke too soon. It is called, but it doesn't seem to change what NSToolbar is doing. It is called when I open the toolbar customization, but even though I return a restricted set of identifiers, it still presents all items that were set up in IB, not the reduced set of items as it's supposed to present. So the question is: How do I remove an item with a given identifier in such a way that it does not appear in the customization, neither is single item nor as part of the default toolbar configuration. Thanks for any pointers! Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSToolbar delegate -toolbarAllowedItemIdentifiers:
On 2/7/14 11:19 PM, Jerry Krinock wrote:
I’ve never used -toolbarAllowedItemIdentifiers:. However, its documentation
states…
Sent to discover the allowed item identifiers for a toolbar.”
Wonderful :)) There is no indication of who sends it, when, nor what is done
with the result. The “Discussion” is no more enlightening either. Therefore I
have no idea what the purpose of this method is. Apparently, based on your
results, its purpose is not your purpose.
On 2014 Feb 07, at 13:43, Markus Spoettl ms_li...@shiftoption.com wrote:
So the question is: How do I remove an item with a given identifier in such a
way that it does not appear
Here is how I remove toolbar items that are present in nibs…
NSInteger someToolbarItemIndex = [[toolbar items]
indexOfObject:someToolbarItem] ;
if ((someToolbarItemIndex = 0 ) (someToolbarItemIndex [[toolbar items]
count]))
{
[toolbar removeItemAtIndex:settingsToolbarItemIndex] ;
}
where ‘toolbar’ and ‘someToolbarItem’ are outlets, connected in the nib. So a
disadvantage of my method is that you need an outlet for any removable toolbar
item. But I have only have one, and it works for me.
in the customization, neither is single item nor as part of the default toolbar
configuration.
I hope that clause was not important because I don’t understand it.
It is important, I'm afraid. Removing the items from the toolbar is not a
problem. However, I can't get the toolbar to remove them from the customization
sheet.
I thought the whole point of telling the toolbar which of the items are allowed
is that those items will not be shown them during customization (or anywhere
else). The -toolbarAllowedItemIdentifiers: delegate method is called at the
beginning of the customization (before the sheet comes up), that's a hint that
it's used for a purpose that has to do with customization. But apparently its
result is ignored because items that are disallowed (by not returning them in
this delegate method) are still visible.
Regards
Markus
--
__
Markus Spoettl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
UIDocumentInteractionController open-in multiple UTIs
Hi, my iOS 7 app shares data with other apps on the device using UIDocumentInteractionController's openIn. Works fine. The problem is that I'd like to share different file formats (all of which are declared and exported by UTIs from our app), depending on which app is the recipient. I tried to use the -documentInteractionController:willBeginSendingToApplication: delegate method to setup the exported file and its URL, but unfortunately the URL property must be set and be available before that method when the controller is presented. The documentation claims that URL can be set after initialization but I fail to see how that is true, except of course that you can call setURL before presenting the controller, which is rather pointless. I would be equally fine with offering a number of different UTIs for export and let UIDocumentInteractionController negotiate the format that should be generated. Any ideas on how to solve this? Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Crash on iOS when encoding an NSAttributedString
On 1/20/14 12:35 AM, Graham Cox wrote: It's probably worth filing a radar because I would say that archiving arbitrary fonts either needs to work robustly or fail cleanly. When I filed a radar on a similar kind of fault recently it got notified as a dupe, so some of these issues are known. Did that, we'll see what comes out of it. Thanks for the feedback, both of you! Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Can CFUUIDCreateString() return lowercase characters?
Hi, up until now I've been assuming that CFUUIDCreateString() returns strings using uppercase letters. There's lots of empirical evidence that it does do that, but nothing in writing. NSUUID's -UUIDString documentation also suggests uppercase characters being used, but doesn't commit to it either. Anyone with authority here to confirm that assumption? Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Can CFUUIDCreateString() return lowercase characters?
Hi Jean-Daniel, On 1/21/14 11:36 AM, Jean-Daniel Dupas wrote: According to the current CF sources, CFUUIDCreateString() returns an uppercase string. But if I really want to know what I get, I would rather use the libuuid functions provided by the system: uuid_unparse_lower() and uuid_unparse_upper(). See man uuid for details. Thanks a lot! Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Crash on iOS when encoding an NSAttributedString
Hello,
I got a crash log from a user that's mildly puzzling. It happens somewhere
deep down CoreText it seems, while encoding an NSAttributedString (whose content
I don't know). Any ideas how it can some to this?
My app has a standard UITextView that feeds the model property that is encoded
here. There is no processing of the attributed string going on in the App. The
UITextView is created dynamically (not loaded from a NIB), it is embedded in a
custom UITableViewCell (just in case that influences the way it constructs
attributed strings it spits out).
Google turns up some crashes with a similar top end of the call stack, but those
happen while drawing the attributed string. Does iOS draw a NSAttributedString
in order to object-encode it?
The code that eventually ends up crashing is
- (void)encodeWithCoder:(NSCoder *)encoder
{
[encoder encodeObject:notes forKey:@notes];
}
Does this ring a bell for anyone?
Regards
Markus
Hardware Model: iPhone6,2
Process: MyApp [3818]
Path:
/var/mobile/Applications/9C395437-7BC5-47A8-B4BE-C659F61F5628/MyApp.app/MyApp
Identifier: com.bla.MyApp
Version: 162 (1.0)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
Date/Time: 2014-01-19 06:44:51.347 +
OS Version: iOS 7.0.4 (11B554a)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x7300786966657250
Triggered by Thread: 0
Thread 0 Crashed:
0 ??? 0x7300786966657250 0 + 8286755708446536272
1 CoreText 0x00018c689bd8 TBaseFont::CalculateFontMetrics(bool)
const + 100
2 CoreText 0x00018c699930
TComponentFont::CalculateFontMetrics(bool) const + 52
3 CoreText 0x00018c689a2c TBaseFont::InitFontMetrics() const + 64
4 CoreText 0x00018c70bec8 TBaseFont::GetStrikeMetrics(double,
CGAffineTransform const*, bool) const + 96
5 CoreText 0x00018c689774 TFont::InitStrikeMetrics() const + 64
6 CoreText 0x00018c689704 CTFontGetAscent + 120
7 GraphicsServices 0x0001917ffc14 GSFontEnsureExtraData + 256
8 GraphicsServices 0x000191802940 GSFontGetExtraData + 52
9 UIFoundation 0x000194c3ee00 -[UIFont isIBTextStyleFont] + 12
10 UIFoundation 0x000194c3e904 -[UIFont encodeWithCoder:] + 112
11 Foundation0x00018c9dc210 _encodeObject + 1244
12 Foundation0x00018c9dd74c -[NSKeyedArchiver
_encodeArrayOfObjects:forKey:] + 468
13 Foundation0x00018c9dd374 -[NSDictionary(NSDictionary)
encodeWithCoder:] + 1024
14 Foundation0x00018c9dc210 _encodeObject + 1244
15 Foundation0x00018c9e9a80 -[NSAttributedString encodeWithCoder:]
+ 252
16 Foundation0x00018c9dc210 _encodeObject + 1244
17 MyApp 0x00010014bb64 -[Activity encodeWithCoder:]
(SRC.m:2319)
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Mixing UIDocument's NSUndoManager and -updateChangeCount:
Hi, I have an app that uses UIDocument and NSUndoManager. That way the system picks up changes to the data and knows when to auto-save. Some parts of the model are not using the undo manager (mostly settings where undo makes no sense or isn't wanted). Still that data is stored alongside the main data. What I want is that iOS saves whenever the app is backgrounded. So the questions is: Can I safely call -updateChangeCount: when my app is being sent to the background alongside the automatic NSUndoManager change handling? It seems to work quite nicely (when called from the app delegate's -applicationWillResignActive:), but I'm not sure if that's just an illusion and there's trouble waiting down the road. Any thoughts? Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Mixing UIDocument's NSUndoManager and -updateChangeCount:
On 1/13/14 5:29 PM, Kyle Sluder wrote: This does not strike me as a good idea. -updateChangeCount: is a counter; adding a place that increments the counter without having a corresponding decrement sounds like an invitation for state corruption, particularly in the presence of framework code that treats the counter as normal. Are you sure this is how it works? Reading the constants' documentation (especially that of UIDocumentChangeCleared) doesn't seem to imply that there is strict counter balancing going on: -- UIDocumentChangeCleared The document is cleared of outstanding changes. -- To me it more sounds like the change counter is reset, regardless of how it got incremented. Plus Mike doesn't seem to think that either (not proof of course). It would be better to add a flag to your UIDocument subclass that you set whenever the user changes a non-undoable model property, and override -hasUnsavedChanges to return the OR of this property and super's return value. The point of this is I'm trying to find a way around the necessity of tracking the settings for changes. We're talking about a bazillion of highly complex settings objects, not just 10 bools. Also, if I did that, I could easily use the undo manager and add appropriate changes. Of course I could overwrite -hasUnsavedChanges. But I want it to return YES (in addition to super returning YES) if and only if the app is being backgrounded and the system is trying to save changes as a result of that. That requires me to know when that happens, and I don't. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Mixing UIDocument's NSUndoManager and -updateChangeCount:
On 1/13/14 9:13 PM, Kyle Sluder wrote: But it's just generally a bad practice to violate the framework's stated assumptions. -updateChangeCount: manages a change counter, not a force saving flag. There's a very clear way to implement a force saving flag that fits within the framework design. The existence of that option should be entirely sufficient to discount all other approaches. I can't see any of that in the relevant of the documentation (that I have seen, I'm probably overlooking something) of the UIDocument. -updateChangeCount: -- Calling this method can affect the value returned by hasUnsavedChanges. You should not need to call method this if you access an NSUndoManager object from the undoManager property (or assign a custom one to it) and register changes with the undo manager. -- Telling from this that it's a violation using it if you're already using NSUndoManager just doesn't get across at all (to me anyway). It also doesn't say so in the Change Tracking section in the overview. Could you point me to the portion I'm missing? Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Correct use of CFArraySortValues context parameter
I recently discovered a strange memory leak in a 3rd-party component I use. A call to CFArraySortValues() sometimes produced a leak, sometimes it didn't. This was the invocation: int context = kCFCompareCaseInsensitive; CFArraySortValues(keyArray, CFRangeMake(0, count), (CFComparatorFunction)CFStringCompare, context); After reading through CFArraySortValues and CFStringCompare documentation it's clear (to me anyway) that the context is used incorrectly. The documentation doesn't imply it will dereference the context pointer at any point. That means that CFStringCompare will be called with the pointer value instead of the contents of that address. Changing it to CFArraySortValues(keyArray, CFRangeMake(0, count), (CFComparatorFunction)CFStringCompare, (void*)kCFCompareCaseInsensitive); made the leak go away. I can only assume that the author never realized the array wasn't going to be sorted the way he intended. Can anyone tell me if the latter use of CFArraySortValues() is correct? It doesn't feel right to cast an int option to (void *) but the documentation simply doesn't say it will pass on a dereferenced value. The fact that the leak went away tells me I'm on the right track. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Correct use of CFArraySortValues context parameter
On 12/7/13 3:35 PM, Ken Thomases wrote: Can anyone tell me if the latter use of CFArraySortValues() is correct? It is. Your analysis is correct. It doesn't feel right to cast an int option to (void *) but the documentation simply doesn't say it will pass on a dereferenced value. The docs for CFArraySortValues() describes the context parameter as [a] pointer-sized program-defined value. It is declared as a pointer only to guarantee that it's large enough to hold a pointer even on architectures where a pointer is larger than, say, an int. But semantically, it's just a value. It may have been better for Apple to have used uintptr_t. The fact that the leak went away tells me I'm on the right track. Well, I can't explain why passing the pointer to the context variable would have caused a leak. In theory, CFStringCompare() would simply have interpreted it as a option bit mask with an arbitrary variety of options set. I wouldn't expect any such options to cause a leak. But you're right that the original call was incorrect. Thanks Ken for the quick confirmation! In that case, a word of warning to all AquaticPrime users - that's where this code comes from. The function you're looking for is APCreateDictionaryForLicenseData(). Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Getting mouse clicks when the main loop is busy
On 11/10/13 1:21 PM, Uli Kusterer wrote: On 08 Nov 2013, at 20:17, Graham Cox graham@bigpond.com wrote: If the file is small and can be read quickly, it really doesn’t make much difference either way whether it’s threaded or not. But if it’s a large file, there may be some time (even minutes) between clicking ‘Open’ in the NSOpenPanel and the document opening its window. During that time, there is no feedback whatsoever that anything is happening. It acts, for all intents and purposes, as if the ‘Open’ click was ignored. Are you saying there’s no way to get the async document loading mechanism to open the empty document first, then asynchronously load the data into that window (giving you the opportunity to show partially loaded content or a progress indicator *inside* the document window)? That’s what I would expect it to do. Open the document, then call the read method asynchronously, giving you behaviour as if it was a “revert”, effectively. I haven’t used the async loading API, but I’d expect there to be some oddly-named call that gives you such behaviour, or something implicit you’re doing wrong that keeps your document from appearing? No, he's doing it right, this is just how the NSDocument architecture works. It reads the document file content first (asynchronously or synchronously), then creates the UI for it. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIActionSheet -addButtonWithTitle weirdness on iPad
On 10/2/13 10:40 PM, David Duncan wrote: On Oct 2, 2013, at 9:33 AM, Markus Spoettl ms_li...@shiftoption.com wrote: On the iPad (both device and simulator) this produces a sheet with Button2 missing. No matter how many buttons one adds, the last one added goes missing. On iPhone (again both device and simulator) this produces a sheet with the expected buttons Cancel, Button1, Button2. If I set the cancelButtonTitle: parameter to nil, both iPad and iPhone behave correctly, iow Button1, Button2. Try setting the cancelButtonIndex after you’ve added the extra buttons. The safest way to do this would be to stash off the number of buttons after you’ve created it (via numberOfButtons) then add your extra buttons, then reset the cancelButtonIndex based on the stashed value. -- David Duncan Thanks Duncan, I will try that. However, as Fritz pointed out, the HIG says cancel buttons are undesireable, so I guess the easiest solution is to do that. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
UIActionSheet -addButtonWithTitle weirdness on iPad
Hello, I just came across the following, would someone confirm this: UIActionSheet *sheet = [[UIActionSheet alloc] initWithTitle:nil delegate:self cancelButtonTitle:@Cancel destructiveButtonTitle:nil otherButtonTitles:nil]; [sheet addButtonWithTitle:@Button1]; [sheet addButtonWithTitle:@Button2]; [sheet showFromRect:someRect inView:someView animated:YES]; On the iPad (both device and simulator) this produces a sheet with Button2 missing. No matter how many buttons one adds, the last one added goes missing. On iPhone (again both device and simulator) this produces a sheet with the expected buttons Cancel, Button1, Button2. If I set the cancelButtonTitle: parameter to nil, both iPad and iPhone behave correctly, iow Button1, Button2. This is on iOS 7.0, Xcode 5.0 (5A1413). Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIActionSheet -addButtonWithTitle weirdness on iPad
OK, I admit I didn't pay attention to that, but removing another button instead of the cancel button hardly feels like just a documentation bug. Anyway, thanks for pointing that out! Regards Markus On 10/2/13 9:21 PM, Fritz Anderson wrote: The class reference _recommends_ not providing a Cancel button for an action sheet that presents in a popover — the user can easily cancel by tapping elsewhere. (there are times when you should not include a cancel button) xcdoc://ios/documentation/UIKit/Reference/UIActionSheet_Class/Reference/Reference.html The HIG is indirect, recommending a Cancel button for the iPhone, but silent on whether it means _only_ on the iPhone. But if the action sheet is to cascade from another popover, the class reference says you must provide one. The HIG is silent. Also, the HIG implies that a Cancel button should be added like any other button, which puzzles me about how to handle the special decoration a Cancel button requires. A Google search on stackoverflow.com tells me that if a Cancel button is specified on iPad, it will bump the last button from the sheet. So much for should not. I haven't made the experiment of cascading the sheet on a popover. When I'm off work, I'll try the experiment and file a documentation bug. — F On 2 Oct 2013, at 11:33 AM, Markus Spoettl ms_li...@shiftoption.com wrote: Hello, I just came across the following, would someone confirm this: UIActionSheet *sheet = [[UIActionSheet alloc] initWithTitle:nil delegate:self cancelButtonTitle:@Cancel destructiveButtonTitle:nil otherButtonTitles:nil]; [sheet addButtonWithTitle:@Button1]; [sheet addButtonWithTitle:@Button2]; [sheet showFromRect:someRect inView:someView animated:YES]; On the iPad (both device and simulator) this produces a sheet with Button2 missing. No matter how many buttons one adds, the last one added goes missing. On iPhone (again both device and simulator) this produces a sheet with the expected buttons Cancel, Button1, Button2. If I set the cancelButtonTitle: parameter to nil, both iPad and iPhone behave correctly, iow Button1, Button2. This is on iOS 7.0, Xcode 5.0 (5A1413). Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/fritza%40manoverboard.org This email sent to fri...@manoverboard.org -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
