Is there a robust way of checking whether the window is currently in its maximized zoom state?
I'm not looking for a notification or delegate method that would tell me when the NSWindow changes its size but need to check at some point whether the current size is the maximized state.
Couldn't find anything straight-forward on NSWindow to achieve that..
You want the zoomed property of the window, whose getter is -isZoomed.
Prior to the 10.10 SDK, this was an informal property. Its getter method was declared directly. There was no related #property declaration. Apple converted a lot of such properties from informal to "declared properties" in the 10.10 SDK. In some cases, the old, stand-alone methods are listed as "deprecated" in the documentation, but that's just a side effect of the conversion. The getter method is still there, still named the same, still callable, and not deprecated. Just the mechanism by which it was declared has changed.
Well, isZoomed is available on 10.0 to 10.9, but... since you're asking this question, I guess you're probably on 10.10, wondering why it's not there. :)
But look at the "discussion" part of the Apple docs for isZoomed:
..snip..
Or maybe don't look at the docs in this case. :) See Ken Thomases' answer.
Related
I'm seeing here in changes page that setApplicationIconImage was deprecated. Man I couldn't believe it.
https://developer.apple.com/library/mac/documentation/General/Reference/APIDiffsMacOSX10_10SeedDiff/frameworks/AppKit.html
What is the an alternative for this now? Is there one that works in older versions then 10.10 too? If not its ok i can do version check and do setApplicationIconImage for <= 10.9 and the new way for >= 10.10.
Thanks
The setApplicationIconImage method did not get deprecated or removed.
Apple only changed the header to SHOW it as a property instead.
setApplicationIconImage IS the setter for the property. properties are only syntactic sugar for two 'standard' methods: a getter (applicationIconImage) and a setter (setApplicationIconImage)
you might get an ARC warning nowadays because it can't see setApplicationIconImage so use the dot-notation on ALL platforms -> no need for a runtime check of 10.10/10.9
It looks like maybe they removed the method in favor of a property. So use this instead.
[NSApplication sharedInstance].applicationIconImage = myNewIconImage
From the NSApplication class reference,
Assign an image to this property when you want to temporarily change the app icon in the dock app tile. The image you provide is scaled as needed so that it fits in the tile. To restore your app’s original icon, set this property to nil. Available in OS X v10.0 and later.
Currently, when selecting components or swiping the UIPickerView, the default is a lengthy animation time waiting for the selection, with a "gravity" effect near values. Is there a simple way to speed up this animation? I've looked at the delegate protocols as well as UIPickerView's methods and properties. Will I have to subclass and overload the animation method? Any help will be useful.
There is no way to do this. If you'd like for there to be a way to do this, please file a bug asking for it.
Also, relying on implementation details and a particular interval view hierarchy, as Fabian suggests, is a really excellent way to introduce a ton of fragility into your application and open the possibility of your app breaking in the future, should UIKit ever change anything.
I don't know of a way to achieve that using public API, but UIPickerView uses a UIPickerTableView as a subview somewhere in its view hierarchy. That is a subclass of UITableView which is a subclass of UIScrollView which has a decelerationRate property.
You shouldn't use private API, though. If you really need this and it's not for an App Store app this might be okay, but you should be careful and code defensively.
I don't have 50 rep, so can't comment on this (which is where this should really go). This question shouldn't have been downvoted since the question is legitimate. The valid answer is "no, you can't do that without private API hacks"), but the question is still valid.
I have implemented the JTRevelSideBar into my project, and it's working quite well, but I have been trying to figure out if it was possible to do something like with the Facebook app, where if the user presses the main viewcontroller, while the sidebar is revealed, the sidebar should be dismissed. Do anybody know this is possible to implement?
Never having used it before, I will say: probably.
Though, the github page for the pod you mention says that it's no longer being supported due to its use being discouraged at the WWDC14. Though, one of the alternatives that JT mentions is PKRevealController2 and seems to be fairly simple to use.
Though the reason I bring it up at all is that usually devs will give you some hint as to how to do what you are asking for in one of the project's main header files. For example in PKRevealController.h it lists the property
/// Whether to use the front view's entire visible area to allow pan based reveal.
#property (nonatomic, assign, readwrite) BOOL recognizesPanningOnFrontView;
Which is exactly what you'd want to set as YES in your project. I would recommend to take a look at the header files in the JTRevealSideBar pod to see if there is something similar.
Now, I have used MMDrawerController before (it's pretty great!) and similarly it has a MMCloseDrawerGestureMode which can be set to MMCloseDrawerGestureModeBezelPanningCenterView (The user can close the drawer by starting a pan anywhere within the bezel of the center view.)
So you see, you'll just have to do a little digging. Otherwise you'll need to implement a pan gesture recognizer... but I can't really say for sure where you'll be putting it in your particular implementation.
I'm having a difficult time understanding what's going wrong. I have an NSWindowController with a NSWindow and a NSTextView. I want to archive that NSWindowController and NSWindow (along with all of its controls) to a file.
Then, I want to unarchive that same NSWindowController and the NSWindow and all views from the file. But Apple docs say:
Note: Although the NSWindow class inherits the NSCoding protocol from NSResponder, the class does not support coding. Legacy support for archivers exists but its use is deprecated and may not work. Any attempt to archive or unarchive an NSWindow object using a keyed coding object raises an NSInvalidArgumentException exception.
Importantly, if I encodeWithObject:windowController, this doesn't store the NSWindow. Therefore, when I do decodeWithObject for the windowController, the NSWindow isn't loaded.
How do I archive/unarchive the NSWindowController / NSWindow and all of its controls? What am I missing?
Based on your answers, this is absolutely the wrong way to go about this. The only place an archived controller/view object graph makes sense is when it's archived as a nib/xib. A document contains data, not bits of the application's machinery.
If you're targeting anything below Lion, save your state somewhere in your document data when the document is saved and restore it when the document is loaded (see the various loading stages Document-Based Applications Overview for an understanding of where/when to do this).
If you're targeting Lion and above, the documentation isn't very detailed yet (and in some cases is completely nonexistent), but Lion supports EXACTLY this with very little effort on your part. See the WWDC 2011 videos, session 119 - Resume and Automatic Termination.
I want to expand on the functionality of NSTextField. AMong the things I want to achieve is:
Changing the look and feel of the caret.
Detecting when the text reaches a certain number of characters and then coloring the text after that limit differently. *
To my great frustration after spending quite some time googling I find hundreds of hits that simply state "Sublass NSTextField and use this code.", and to my humiliation I have found myself unable to grok exactly how to do this.
I would be extremely grateful if someone could give me a working example of a subclass that achieves one of the two things I list above, and instructions* on how to implement the code so I can try and figure out how it works by looking at some actual live code.
I am extremely apologetic for my late response!
Apologies to all of you. I have a colic infant at home, and as you (or at least those of you that have children) can imagine this takes up quite a lot of your available time. Thank you all for your responses.
I see that one of my main problems is that I don't have a sufficient understanding of delegates and outlets. I have purchased the book recommended here (and many other places. Some sort of "Bible" I gather) and I'm looking into it as we speak in the few silent hours I have these days. :)
But although I can see it's going to be an indispensable tool for me I still gain the most understanding from studying examples rather than reading the theory* and so I would be extremely grateful if someone would create a project with a proper subclass of the relevant class since I understand that I should probably not be extending the NSTextfield class?
I would instantly mark Mark Thalmans post as the answer as I'm sure it's a proper "for dummies" response, but I'll hold out for a few days since I'd really love a file to peruse. But I am not ungrateful!
Oh, and; Please believe me guys when I say I'm not quite as useless in languages I actually know. It's just that these concepts with the Interface Builder and GUIs connection to the code is very unknown to me. I usually just write the code and keep it at that.
*Yes, my first little training project is indeed a Twitter Utility.
*Like to a child
*Not that reading the theory hasn't got tremendous value for me as well. I wouldn't be where I am without Colin Moock definitive guide to AS3
setInsertionPointColor: will take care of setting the caret color, and using delegate methods would be the best way to color the text after the number of characters change. In general, a lot of classes in Cocoa are like this; you can subclass them, but most of the functionality you need to change are in delegate methods.
NSTextField is special, because it doesn’t actually implement text editing. That’s done by a shared (per-window) NSTextView, known as the field editor. You can provide a special field editor for a given NSTextField. This is canonically done by subclassing NSWindow (!) and overriding -fieldEditor:forObject:. When I was looking this up, though, I found NSTextFieldCell’s -setUpFieldEditorAttributes: method, which looks as though it could return a different field editor than the one it’s handed.
Recommended reading: Control and Cell Programming Topics for Cocoa, Text System Overview.
Martin,
I started with the "New File" dialog and chose "Cocoa" on the left and then Objective-C class.
That will generate the following code, without the comments. Then all you need to do is change the NSObject in the"#interface" line of the header to "NSTextView" and you have a working subclass. If you are using XCode 3.0 you can go to Interface Builder and change class of your NSTextField to "MyTextView".
You should also pick up Aaron Hillegass' book "Cocoa Programming for Mac OS X, Third Edition" It has bee updated for Leopard, if you haven't already.
Good Luck.
#import <Cocoa/Cocoa.h>
#interface MyTextView : NSTextView {
// Outlets & Members go here
}
// Actions & messages go here
#end
#import "MyTextView.h"
#implementation MyTextView
#end
If you really have to subclass it, you have to subclass the NSTextFieldCell. Informations about NSCells are available online.
Don't subclass the cell if not absolutely necessary. Use the delegate methods.
At least the color can be changed using NSTextField's bindings, use those.
You may also be able to get some of the functionality required with a formatter.