Generally, when editing text in a text field/input/area/editor, pressing ⌘A will select all of the current text in said field/input/area/editor. I've subclassed NSTextField and NSTextFieldCell, and no matter what I try, I can't seem to get basic "Select All" functionality working. I've tried implementing delegate protocols, intercepting events, manipulating commands made by selectors, and every other thing I can think of. What gives? (I can already hear the "Ever heard of Google?" refrains because of how simple this probably is, but I haven't found a single answer out there. I guess I can thank iOS for that.)
And before I forget to mention it, I also dragged a standard NSTextField into my nib to see if a non-subclassed NSTextField implements Select All behavior by default, and to my shock, it doesn't. Am I going crazy here, or am I completely overlooking something? Isn't Select All almost a requirement when implementing a text field? Apple's First Responder proxy handles everything under the sun (including two versions of selectAll (selectAll and selectAll:), but the n00b is strong with me, and I can't seem to make sense of any of this.
Any help/ideas would be immensely appreciated. Cheers!
The application menu handles sending the keyboard shortcut actions to the application's current first responder. The missing connection would explain why your regular NSTextField objects are missing this functionality as well.
Related
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'm looking for a simple way of adding a refresh mechanism to my UIWebView. I've seen posts about the EGO pull to refresh but, to be honest, I don't understand how that works, especially since I have no clue on how to use it with a UIWebView instead of a table view. And it seems to me like a lot of overhead for just a simple refresh.
I thought about adding a navbar but instead of a back button, add a custom "refresh" one. But based on what I've found so far, it seems as complicated as the other solution.
So, basically, I'd like to know what you would do. Keep in mind that the only requirement is that the user have some easy way of refreshing the view. Any suggestion ?
*I'm a begginer in Objective-C so that is why I don't understand how to plug the EGO framework with a UIWebView even after downloading and running the code.
Well,
Create a button and inside button's IBAction,
- (IBAction) performReload:(id) sender {
[self.uiwebview reload];
}
Check the documentation, it will help you a lot at your beginning stage.
Visual Suggestion:
http://developer.apple.com/library/ios/#documentation/uikit/reference/UIWebView_Class/Reference/Reference.html
I'm trying to learn objective-c by making a GUI application using Xcode 3. I'm wondering if it is possible to change the text of a button outside of a tab view depending on which tab in the tabview is selected? As I said I am trying to learn objective-c so please act as though I know next to nothing in your answer. I should probably mention that I tried making a NSObject and tried to define an IBAction in a .h and .m file but that didn't seem to work. (I have tried setting some breakpoints in those files none of which were ever reached leading me to think something isn't wired the way think it is.)
Sorry for the long winded explanation.
Thanks for all the help!
I actually figured it out. What I needed was object delegation, this page, and of course Google to help get the correct syntax for the actual implementation.
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.
I'm slowly learning Objective-C and Cocoa, and the only way I see so far to capture key events in Text Views is to use delegation, but I'm having trouble finding useful documentation and examples on how to implement such a solution. Can anyone point me in the right direction or supply some first-hand help?
Generally, the way you implement it is simply to add the required function to your view's controller, and set its delegate. For example, if you want code to run when the view loads, you just delegate your view to the controller, and implement the awakeFromNib function.
So, to detect a key press in a text view, make sure your controller is the text view's delegate, and then implement this:
- (void)keyUp:(NSEvent *)theEvent
Note that this is an inherited NSResponder method, not a NSTextView method.
Just a tip for syntax highlighting:
Don't highlight the whole text view at once - it's very slow. Also don't highlight the last edited text using -editedRange - it's very slow too if the user pastes a large body of text into the text view.
Instead you need to highlight the visible text which is done like this:
NSRect visibleRect = [[[textView enclosingScrollView] contentView] documentVisibleRect];
NSRange visibleRange = [[textView layoutManager] glyphRangeForBoundingRect:visibleRect inTextContainer:[textView textContainer]];
Then you feed visibleRange to your highlighting code.
It's important to tell us what you're really trying to accomplish — the higher-level goal that you think capturing key events in an NSTextView will address.
For example, when someone asks me how to capture key events in an NSTextField what they really want to know is how to validate input in the field. That's done by setting the field's formatter to an instance of NSFormatter (whether one of the formatters included in Cocoa or a custom one), not by processing keystrokes directly.
So given that example, what are you really trying to accomplish?
I've done some hard digging, and I did find an answer to my own question. I'll get at it below, but thanks to the two fellas who replied. I think that Stack Overflow is a fantastic site already--I hope more Mac developers find their way in once the beta is over--this could be a great resource for other developers looking to transition to the platform.
So, I did, as suggested by Danny, find my answer in delegation. What I didn't understand from Danny's post was that there are a set of delegate-enabled methods in the delegating object, and that the delegate must implement said events. And so for a TextView, I was able to find the method textDidChange, which accomplished what I wanted in an even better way than simply capturing key presses would have done. So if I implement this in my controller:
- (void)textDidChange:(NSNotification *)aNotification;
I can respond to the text being edited. There are, of course, other methods available, and I'm excited to play with them, because I know I'll learn a whole lot as I do. Thanks again, guys.