NSGraphicsContext currentContext() returns nil on OSX 10.11
I'm running our application on OSX 10.11. NSGraphicsContext currentContext() returns nil in one of the drawing methods. The same code works fine on OSX 10.9.5 and 10.10.3. According to the documentation, currentContext returns an instance of a concrete subclass of NSGraphicsContext. It doesn't mention that it can return nil. Is this is a known issue with OSX 10.11? Are there valid/un-documented cases when currentContext can return nil? Any help will be appreciated? Thanks,Lakshmi ___ 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: NSGraphicsContext currentContext() returns nil on OSX 10.11
> On Oct 12, 2015, at 8:45 PM, Lakshmi P Shanmugam > wrote: > > I'm running our application on OSX 10.11. NSGraphicsContext > currentContext() returns nil in one of the drawing methods. The same code > works fine on OSX 10.9.5 and 10.10.3. > According to the documentation, currentContext returns an instance of a > concrete subclass of NSGraphicsContext. It doesn't mention that it can > return nil. > > Is this is a known issue with OSX 10.11? Are there valid/un-documented > cases when currentContext can return nil? Apple docs can be sparse. It's implicit in 10.11 if it doesn't say nonnull or it isn't wrapped in NS_ASSUME_NONNULL The Swift version returns an Optional. So yes it can return nil. If your view is not in a view hierarchy in a window, it can be nil. In its essence a graphics context is a rect that can be drawn into. You can also draw into a bitmap context but that is really a buffer of sorts. ___ 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: NSButton with NSTexturedRoundedBezelStyle outside of NSToolbar
> On Oct 11, 2015, at 3:07 PM, Jacek Oleksy wrote: > > I am not subclassing NSToolbar, I am using NSView (and putting > NSButton as a subview). Why would you not use NSToolbar? I would bet that Apple “native” toolbars use NSToolbar or a subclass there of. > Sadly, that is not true. From the documentation on > NSTexturedRoundedBezelStyle: > > "A textured (metal) bezel style similar in appearance to the Finder’s > action (gear) button. The height of this button is fixed." > > Setting programatically the height does nothing. I have a NSTexturedRoundedBezelStyle button in a toolbar (actually as Jens pointed out a NSToolbarItem that displays a button). The height of my button is 22 points. If I programmatically set the height to 60 points the button’s position shifts vertically by half that amount in the tool bar. You are right that the graphics or image of the button does not change. When the documentation states that “the height of this button is fixed” I think that really means that visually the height of the image is fixed. But the frame height of the button can be use to adjust the vertical position of the button with respect to it’s superview which is a NSToolbarItem. Several years ago when this was fresher in my mind I believe I was also struggling with the 24pt vs 22pt height. Perhaps this is Apple’s way of adjusting the vertical position of the button image within the superview. --Richard Charles ___ 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: NSGraphicsContext currentContext() returns nil on OSX 10.11
On Oct 12, 2015, at 6:45 AM, Lakshmi P Shanmugam wrote: > I'm running our application on OSX 10.11. NSGraphicsContext > currentContext() returns nil in one of the drawing methods. What drawing method and who called it, you or the framework? For example, I recently worked with somebody who was calling -drawRect: themselves, which is never valid. The context won't be set up in that case because the framework is the one who sets it up prior to calling -drawRect: (which is why calling it yourself isn't valid). Regards, Ken ___ 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: More Swift issues, NSURLComponents
> On Oct 5, 2015, at 19:19 , Jens Alfke wrote: > > >> On Oct 5, 2015, at 6:59 PM, Rick Mann wrote: >> >> Huh. I continue to be bothered by the ambiguity/variability of "let"*. Is >> the reference immutable or the thing it points to? > > A variable (var or let) doesn’t “point to” a struct. It _contains_ the > struct. I.e. it’s a value, not a reference. > > It’s just like in C or C++, really. Given a struct Foo, > const Foo x; // a value: x is immutable; you can’t change its fields > Foo* const x; // a reference: the variable x can’t be changed, but the > Foo it points to can > > The thing Swift doesn’t have that C/C++ do is > const Foo *x; // the Foo can’t be changed through this reference > (though the value of x can) > The reason this was left out is probably that it doesn’t fit at all with > Objective-C and the Cocoa frameworks, which have no concept of a constant > reference to an NSObject. In all this discussion, I forgot to bring up the containers: are they special? A "let" container can't be reassigned, nor can its contents be changed. How is this implemented? -- Rick Mann rm...@latencyzero.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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: More Swift issues, NSURLComponents
> On Oct 12, 2015, at 2:00 PM, Rick Mann wrote: > > In all this discussion, I forgot to bring up the containers: are they > special? A "let" container can't be reassigned, nor can its contents be > changed. How is this implemented? No, they’re not special, but they’re structs (not classes). That means they’re passed by value (copied), and their methods can be marked ‘mutable’ to indicate that they modify the object. Under the hood, as an optimization, the collection classes use copy-on-write indirection — an Array struct just contains a pointer to an internal buffer (a class instance) that has the actual data. That makes copying an Array efficient. The implementation just has to be careful to allocate a new buffer before modifying the contents, if the buffer is shared with any other Arrays. (There are some low-level public Swift types that act as helpers for implementing this pattern.) If you want to know lots more, read Mike Ash’s article “Let’s Build Swift Array”: https://www.mikeash.com/pyblog/friday-qa-2015-04-17-lets-build-swiftarray.html —Jens ___ 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: More Swift issues, NSURLComponents
> On Oct 12, 2015, at 14:08 , Jens Alfke wrote: > > >> On Oct 12, 2015, at 2:00 PM, Rick Mann wrote: >> >> In all this discussion, I forgot to bring up the containers: are they >> special? A "let" container can't be reassigned, nor can its contents be >> changed. How is this implemented? > > No, they’re not special, but they’re structs (not classes). That means > they’re passed by value (copied), and their methods can be marked ‘mutable’ > to indicate that they modify the object. Oh! I thought they were classes. Thanks. > Under the hood, as an optimization, the collection classes use copy-on-write > indirection — an Array struct just contains a pointer to an internal buffer > (a class instance) that has the actual data. That makes copying an Array > efficient. The implementation just has to be careful to allocate a new buffer > before modifying the contents, if the buffer is shared with any other Arrays. > (There are some low-level public Swift types that act as helpers for > implementing this pattern.) > > If you want to know lots more, read Mike Ash’s article “Let’s Build Swift > Array”: > > https://www.mikeash.com/pyblog/friday-qa-2015-04-17-lets-build-swiftarray.html > Thanks! -- Rick Mann rm...@latencyzero.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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to make UISplitViewController behave ?
> On Oct 11, 2015, at 11:21 PM, Gerriet M. Denkmann > wrote: > > iPad / iPhone Master-Detail app. iOS 9.0, Xcode 7.0 > > Rotating the iPad to Portrait my AppDelegate will receive a > UIDeviceOrientationDidChangeNotification: > > 12:23:01.182 -[AppDelegate iPadHasTurned:] > and does: > UISplitViewControllerDisplayMode newMode = PrimaryOverlay > splitViewController.preferredDisplayMode = newMode; > [ self performSelector: @selector(delayedSetMode:) withObject: > @(newMode) afterDelay: 0 ]; // see below > > 12:23:01.183 -[AppDelegate splitViewController:willChangeToDisplayMode:] > PrimaryOverlay > good, that's what I just have told it to do. > > 12:23:01.196 -[MasterViewController viewDidAppear:] > 12:23:01.198 -[AppDelegate iPadHasTurned:] done > > So far so good. > > But now the pesky SplitViewController decides it knows best, and does: > > 12:23:01.199 -[AppDelegate splitViewController:willChangeToDisplayMode:] > AllVisible > > here my delayedSetMode will come to the rescue: > 12:23:01.212 -[AppDelegate delayedSetMode:] displayMode → PrimaryOverlay > > does: splitViewController.preferredDisplayMode = newMode; > 12:23:01.223 -[MasterViewController viewDidAppear:] > 12:23:01.224 -[AppDelegate delayedSetMode:] done > > Is there a better way than this hack with delayedSetMode ? Why are you doing this? If you always want PrimaryOverlay mode, just set it once, at configuration time, and never change it again. If thats not what you want, then please explain. > > Gerriet. > > > ___ > > 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/david.duncan%40apple.com > > This email sent to david.dun...@apple.com -- David Duncan ___ 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: How to make UISplitViewController behave ?
> On 13 Oct 2015, at 04:49, David Duncan wrote: > > >> On Oct 11, 2015, at 11:21 PM, Gerriet M. Denkmann >> wrote: >> >> iPad / iPhone Master-Detail app. iOS 9.0, Xcode 7.0 >> >> Rotating the iPad to Portrait my AppDelegate will receive a >> UIDeviceOrientationDidChangeNotification: >> >> 12:23:01.182 -[AppDelegate iPadHasTurned:] >> and does: >> UISplitViewControllerDisplayMode newMode = PrimaryOverlay >> splitViewController.preferredDisplayMode = newMode; >> [ self performSelector: @selector(delayedSetMode:) withObject: >> @(newMode) afterDelay: 0 ]; // see below >> >> 12:23:01.183 -[AppDelegate >> splitViewController:willChangeToDisplayMode:] PrimaryOverlay >> good, that's what I just have told it to do. >> >> 12:23:01.196 -[MasterViewController viewDidAppear:] >> 12:23:01.198 -[AppDelegate iPadHasTurned:] done >> >> So far so good. >> >> But now the pesky SplitViewController decides it knows best, and does: >> >> 12:23:01.199 -[AppDelegate splitViewController:willChangeToDisplayMode:] >> AllVisible >> >> here my delayedSetMode will come to the rescue: >> 12:23:01.212 -[AppDelegate delayedSetMode:] displayMode → PrimaryOverlay >> >> does: splitViewController.preferredDisplayMode = newMode; >> 12:23:01.223 -[MasterViewController viewDidAppear:] >> 12:23:01.224 -[AppDelegate delayedSetMode:] done >> >> Is there a better way than this hack with delayedSetMode ? > > Why are you doing this? I have defined two new displayModes, let’s call them UISplitViewControllerDisplayMode_FocusOnPrimary and UISplitViewControllerDisplayMode_FocusOnSecondary, or FocusOnPrimary and FocusOnSecondary for short. They should work like this on iPad: • Landscape: both Primary (Master) and Secondary (Detail) should be visible. Automatic works fine in this case. • Portrait with FocusOnPrimary: Primary (Master) should be visible, leaving the Secondary (Detail) partly obscured. Like PrimaryOverlay. • Portrait with FocusOnSecondary: Secondary (Detail) should be visible, completely hiding Primary. Like PrimaryHidden. The use case is as follows: • If the user shifts focus to Detail - e.g. by clicking on a row in the TableView of Master (which makes some info about this row show up in Detail), the Detail or Secondary should be completely visible (and remain visible), regardless of orientation of iPad. • Similarly if the user clicks the “< Master” Back-Button (or goes back to Master by some other means) then the focus should be on Master; and Master should remain visible, regardless of orientation of iPad. I have implemented these two new displayModes via UIDeviceOrientationDidChangeNotification. When I just set PrimaryOverlay in Portrait (while shifting focus to Main), all is fine (for the time being). But when I then rotate iPad to Landscape only the Detail view is shown, which is wrong. Kind regards, Gerriet. ___ 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: Data not retained in document based core data app with cocoa bindings
> On 2015 Oct 11, at 09:30, Richard Charles wrote: > >> On Oct 11, 2015, at 2:41 AM, Devarshi Kulshreshtha >> wrote: >> >> Looking for more clues :-| Devarshi, I tried the kludge which Richard found on Stack Overflow (self.view.window.windowController.document.managedObjectContext), and it worked for me. Here you can get the demo from github: https://github.com/jerrykrinock/CoreDataDocStoryboard/tree/master The only think you left out of your description is that the table view assembly in the Interface Builder library now as view cells, so to make it work for text you need to drop a text field cell onto the view cell and it magically becomes a text field cell. > You may want to give up on storyboards and swift for the time being. Well, at least give up in storyboards in a document-based Mac app. I got interested in this because I could not believe that such a ludricously long binding self.view.window.windowController.document.managedObjectContext was the recommended approach. But it is the best answer I’ve found so far. The problem is that the storyboard has these two scenes, “Window Controller” and “View Controller”, with no way to get a message between them, *and* your document only gets access to only *one* of them in -[NSStoryboard instantiateControllerWithIdentifier:]. However, you need access to both: the window controller, to display the window, and the view controller, to bind to your data model. But neither Cocoa Bindings nor outlet connections can cross from one scene to the other. I wonder if it possible to pass something in the segue which would be less of a kludge? ___ 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
