I have an action that does a few things to the NSManagedObjectContext, and they're all surrounded by begin/endUndoGrouping (A). Later, a timer checks on a managed object and sees that an outside change has been made (the mod date of file the object refers to has changed), so one attribute (modificationDate) on the object is updated, which I have bracketed with disable/enableUndoRegistration (B). At this point, if I click on the Edit menu or hit command-z, the undo manager runs a checkpoint, and the MOC ends up adding a separate undo to the stack, I assume for the change caused by B. This mystery undo has no name, because I didn't create it and set its name, and as far as the user is concerned, it's not an action they did, so it shouldn't be undoable, and the changes aren't user-facing in the first place.Why is this misbehaving? The method in the invocation for B is _undoUpdate: and the target is the MOC. It should not be on the undo stack.I see that NSManagedObjectContext has a private ivar called _ignoreUndoCheckpoints, which sounds exactly like a things I'd like to turn on, if it does what it sounds like it does. But there's no public interface for it.
Post not yet marked as solved
I've been rejiggering my Core Data model a bit, after moving from using an NSArrayController with my NSTableView and NSCollectionView to using an NSFetchResultsController instead (the table and collection views now supply data via the data source instead of relying on bindings to the array controller).It's been working fine until I tried to scroll soon after adding a bunch of managed objects. Then I get "Unexpected outstanding background CATransaction" in this thread:Thread 4 Queue : NSScreenUpdate (concurrent)#0 0x00007fff6db09b66 in __pthread_kill ()#1 0x000000010050e0f0 in pthread_kill ()#2 0x00007fff6da651ae in abort ()#3 0x00007fff50e99f8e in CA::Transaction::assert_inactive() ()#4 0x00007fff439d1d12 in __42-[_NSScrollingConcurrentVBLMonitor resume]_block_invoke.131 ()#5 0x000000010048ed8f in _dispatch_client_callout ()#6 0x00000001004a33d2 in _dispatch_continuation_pop ()#7 0x000000010049148f in _dispatch_source_invoke ()#8 0x00000001004a314f in _dispatch_continuation_pop ()#9 0x000000010049a41a in _dispatch_async_redirect_invoke ()#10 0x0000000100490bea in _dispatch_root_queue_drain ()#11 0x00000001004908c3 in _dispatch_worker_thread3 ()#12 0x000000010050b16d in _pthread_wqthread ()#13 0x000000010050abed in start_wqthread ()A few hits when googling this problem seem to indicate 10.13 introduced this bug. How do I work around it? As far as I can tell, all the managed objects have been fully loaded and there are no faults being loaded part way through the scroll. It doesn't matter if I scroll a tiny bit or really zing the Magic Mouse.
Post not yet marked as solved
The NSConnection and NSDistantObject headers say to use NSXPCConnection instead, but NSXPCConnection doesn't have an init method that takes a port. So what's the best way to send messages between 2 remote apps over a network?We have apps that do work, and users want apps to monitor the workers' progress. The old way we did this was with NSSocketPort, NSConnection, NSDistantObject<OurCustomProtocol>, then doing the whole NSMethodSignature, NSInvocation dance in the monitor app, and NSThread, NSTimer, and other objects in the worker to periodically send out progress updates to any listening monitors. The monitor also periodically sends out "are you there" messages to see if the worker has quit/crashed so the monitor can reset the progress display.How would this be done without deprecated classes like NSConnection?
Post not yet marked as solved
I have an iOS app that's giving me a pain. One view hierarchy has a scroll view, page view, and other views. The storyboard has 5 gesture recognizers scattered among a couple of the view controllers. The code has a few shouldBeRequiredToFailByGestureRecognizer and shouldRequireFailureOfGestureRecognizer delegate methods. The problem I'm seeing is that right after I segue to this view hierarchy and attempt to use one particular gesture (long press with 1 tap), the delegate doesn't even get the gestureRecognizerShouldBegin message, but eventually seemingly times out and other gestures will fire, such as my single tap gesture or the page view's next page gesture. But after doing ANY gesture, this gesture behaves like it should from then on.I've tried logging all the pairs of gesture recognizers sent to all of the delegate methods. The strange thing is that the logged pairs of gesture recognizers is different on that first attempt to use the gesture in question than it is on every other time, with more pairs being checked the first time.I was hoping the Simulator or Xcode had some sort of gesture debugging, like a way to spit out info about which gesture recognizers were attempted, failed, skipped, etc. But nope. So, what things can I try? I'm at a loss.
sjmills.