Re: Weird crash in -[NSSearchField setRecentSearches:]
On 2014 Nov 07, at 16:02, Greg Parker gpar...@apple.com wrote: You may have better luck tracing it from the other side. Run to that line in appendToRecentSearches:, set a breakpoint on -[NSNotificationCenter postNotificationName:object:userInfo:], and step over your line. At those breakpoints you should be able to see the notification parameters in the parameter registers, assuming the notification is sent every time that line runs. Great idea, Greg. It worked. It told me that that setting recent searches in this menu posts 122 notifications, 120 of which are due to building the search field’s popup menu. • 40 NSMenuDidAddItemNotification, one for each item in the search field’s popup menu • 20 NSMenuDidChangeItemNotification, which are mixed in with the above, for items that changed. • 1 NSUserDefaultsDidChangeNotification. • 1 NSAutosavedRecentsChangedNotification • 40 NSMenuDidAddItemNotification, same as before. • 20 NSMenuDidChangeItemNotification, same as before However, nowhere in *my* code do I directly create an observer of any of those four notification names. So I’m still head-scratching. If anyone has any idea what disappearing objects in AppKit might be observing these notifications, let us know. ___ 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: NSSplitView parallel motion
FWIW ... achieved most of this by nesting split views and leveraging
autolayout constraints and priorities, almost no delegate code.
I'm still not sure how Mail pulls off the disappearing Source animation
though :-)
Thanks,
-Luther
On Sat, Nov 8, 2014 at 2:58 PM, Luther Baker lutherba...@gmail.com wrote:
Is there a conventional way to implement parallel divider bar motion in
an NSSplitView?
While resizing a window, I get the general behavior I want by setting the
holding properties of 3 view split view to 200, 250, 100 respectfully.
While randomly resizing the view, the 3rd view collapses first, the first
view follows leaving the 2nd view intact for the most part.
But how to do this while dragging dividers around? Holding priorities
don't work there and as soon as I start implementing split view delegate
methods, the holding priorities start to not hold true.
That said, I've tried doing this via delegate methods and gotten pretty
far until the parallel movement thing (If you make the 1st view bigger, I
want the 2nd view to move over and shrink the 3rd view) but when I try to
use something like setPosition:maxXOfView0+300 ofDividerAtIndex:1 from
within the splitView:constraintSplitView:ofSubviewAt - I get some sort of
loopback effect and the first view jumps way up in size and things start
flickering.
- (CGFloat)splitView:(NSSplitView *)splitView
constrainSplitPosition:(CGFloat)proposedPosition
ofSubviewAt:(NSInteger)dividerIndex {
if (dividerIndex == 0) {
NSRect rect = _sourceContainerView.frame;
CGFloat maxX = NSMaxX(rect);
CGFloat position = maxX + 300;
[splitView setPosition:position ofDividerAtIndex:1];
}
return proposedPosition;
}
Do I need to wait for something like splitViewDidResizeSubviews: and then
manually move the divider bar or change the view's frame size?
Also, I'm having pretty good luck simulating a collapse by simply
setting the divider to 0 for something like the first view - but most of
the online tutorials actually animate the view's frame to a size of 0.
Which way is more correct? I don't know if I can animate the approach
that directly sets the position of the divider bar.
Finally then, Mail has an altogether different, neat effect when you
collapse the first or Source view. If you notice, the second and third
views appear to simply slide over the Source view. Maybe the Source view is
getting smaller and auto layout is setup such that the labels don't shrink
but it looks more like the 2nd and 3rd view are simply sliding over-on top
of the Source view. And yes, the 2nd view isn't getting bigger, it is the
3rd view that is getting the extra space.
So, manual window resizing, dragging dividers around ... and programmatic
buttons - all acting generally the same. In general, all resizing is done
in the 3rd view ... and collapsing the 1st view has a special effect to it.
Thanks in advance for any suggestions,
-Luther
___
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: Weak linking
Thanks Greg for your suggestions. But I found something from https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPF rameworks/Concepts/WeakLinking.html I have tried the way mentioned in that, so passed -weak_framework Appkit² in Other Linker Flags under Build Settings of the framework(X.framework) target. It worked on 10.5 and 10.6 as well. Greg, as its working in the above approach, I can go ahead with it instead of having separate bundle/plugin/library, then loading it after OS validation.. Etc. Can you put some light on it and any thoughts on the final approach. Thanks, Satya On 11/8/14, 12:14 AM, Greg Parker gpar...@apple.com wrote: On Nov 7, 2014, at 3:54 AM, Satyanarayana Chebrolu satyanaraya...@ivycomptech.com wrote: Hi folks, We have an application, which is supporting from 10.5(Leopard) to 10.10(Yosemite). Inside the application, there is a custom framework(X.framework), which has some custom code for Appkit classes. Off late, decided to introduce a new feature, which will be supported from 10.7 to 10.10. And then subclassed the classes (NSTableRowView, NSTableCellView), which are part of the X.framework. Problem: The app is getting crashed when we launch it on 10.5 and 10.6 machines saying that “dyld: Symbol not found: _OBJC_CLASS_$_NSTableCellView”. Understand that NSTableRowView, NSTableCellView are not existing on 10.5 and 10.6, so the subclasses should be weakly linked. Weak import of Objective-C symbols does not work on 10.5 and 10.6. The runtime support for it was introduced in 10.6.8. One solution is to drop support for OS versions older than 10.6.8. Another solution is to use dynamic framework loading to keep the code that uses NSTableCellView out of your process when the OS is too old. You would perform an OS version check and use NSBundle or dlopen to load your framework if the OS version is new enough. This works for anything. Another solution is to use NSClassFromString(@NSTableCellView) and never access the class directly. This works for classes that you use but do not subclass; it does not work if you need to subclass a class. It is possible to create a subclass dynamically at runtime, after performing an OS version check. This is typically feasible only in simple cases. -- Greg Parker gpar...@apple.com Runtime Wrangler This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. ___ 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
Add target-action to AVPlayerViewController Done or subclass instead?
I have an ios8 portrait-only iphone app, but when presenting a AVPlayerViewController, I'd like to have it show in landscape. I got this working by creating a container view controller SCRParentPlayerViewController and in its -viewDidLoad I set a AVPlayerViewController as a childViewController(using the typical methods). I then override -preferredInterfaceOrientationForPresentation -supportedInterfaceOrientations -shouldAutorotate Finally I -presentViewController:parentPlayerViewController. This all works fine and dandy, but the Done button in the child AVPlayerViewController does not dismiss the presentation when tapped. Any suggestions? Should I just subclass AVPlayerViewController? I'm wondering if there is a way to add action and target to the Done button, which is what I'd prefer. Xcode 6.1 iOS 8.1 simulator ___ 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
