I've been reading into using the First Responder as a proxy object, and dragging connections from buttons in order to create usable actions (align left, right, etc). However, by default, the First Responder doesn't contain Bold and Italic actions. I tried adding these actions by opening my Menu.xib and dragging the (Font > Bold) menu item to the first responder and setting it as a boldIt function (custom) but that overwrites the existing action (Font Manager: Addtrait). Is there a way to somewhat efficiently add a bold/italic button on the document.xib? Seems like a lot of work for something so common. New to Obj-C
Best,
Zach
In the menu xib, there is an object (the Bold menu item), whose tag is 2, and whose action is connected to the -addFontTrait: method of an NSFontManager instance.
You simply need to do the same thing in document xib. Add an NSFontManager object; create your Bold button; set its tag to 2; and connect its action to -addFontTrait on the NSFontManager.
Related
I'm working on a Cocoa application that has editable text fields. These text fields need to accept values but don't need to be spell checked or use any of the other options given in the default context menu. I've read that the easiest way to remove the right click/ opt + click context menu is to override the function:
rightMouseDown:(NSEvent *)
I've done this in a custom NSTextfield class. This fix blocks the user from right clicking when the text box is enabled and unselected, but as soon as the user double clicks/enters the text field for editing the default right click functionality returns.
Is this because the firstResponder switches to a class in the inheritance chain upon trying to edit the field? Is this approach the right way to disable all context menu functionality for this NSTextField?
Thanks!
When a text field is editing, the actual first responder is the "field editor", an NSTextView supplied by the window. The field editor always uses the control on whose behalf it is acting as its delegate.
So, in order to influence its behavior with respect to the contextual menu, you need to use a custom subclass of NSTextField. (I guess you already are to override -rightMouseDown:.) Then, implement the text view delegate method -textView:menu:forEvent:atIndex: and return nil (i.e. no menu).
I'm wondering if anyone knows if it is possible to modify multiple NSTextViews with a menu bar command. For example if the user selects "Bold" from the menu bar, the different NSTextViews that are selected update all their content to show bold.
Here is the set up I have:
#interface MyCustomTextField : NSView <NSTextViewDelegate>{
NSTextView *textView;
BOOL selected;
...
}
So basically I have my own custom class and within each custom class I have a NSTextView, a var determining whether or not this view is selected and some other stuff.
I'm able to select multiple fields however from what I've read on Apple documentation every NSTextView in the window shares one field editor. When a user edits a NSTextView they are actually sending commands to the field editor which processes it and routes it to NSTextView. If this is the case does that mean that I need to create my own custom field editor and route the commands to all my custom selected text classes instead?
==edit==
My CustomTextField classes have a variable named "selected" (see above) and by holding the shift or apple key down I'm able to "select" multiple CustomTextField instances (I put a mask in front of the NSTextView instances which catches the mouseDown message).
So by this selection, multiple instances have their "selected" attribute set to true. As far as the first responder for the window, it would be set to the mask that shows the blue halo around all the NSTextViews.
I'm wondering if I can tell the app to accept default NSTextView commands (such as bold, italicize, etc.) and that if I supply a custom field editor, it will pass all the appropriate messages to the selected CustomTextFields which will then pass it on to the NSTextViews.
In my head the message would be passed like this:
User Submits Text Toolbar Command > Custom Field Editor > MyCustomTextField > NSTextView
Hopefully my explanation made sense or maybe I'm in LaLa land now.
I'd like to add a font picker in my app. Xcode's Interface Builder has a great implementation which is used in Xcode's own preferences' window too.
It's the one with a little 'T' button (seemingly) inside the font name text field itself.
Is this a standard cocoa implementation?
You'll need to roll your own. See Subclassing NSControl. You'll subclass NSTextField and NSTextFieldCell. Read the entire guide, actually. Once you've got a good understanding, then you can override the drawing/geometry routines to return a rect whose width is slightly smaller (small enough to leave room for the font "button"). Then draw your font button. You'll respond to its mouse events on the font button the same as you would for any NSView.
There's no standard control for the preview text box with the button, but there is the standard NSFontPanel class that you can use to let users select the font once the 'T' button has been clicked.
Best idea is probably to override NSTextFieldCell. I've been able to get the desired appearance by overriding -drawInteriorWithFrame:inView:, and passing a slightly less wide frame when calling through to super, then drawing the button myself. You'd also have to implement the mouse tracking of the button yourself, but you could probably just create your own NSButtonCell instance and call through to it for a few methods with the sub-rect for the button.
For convenience, you may also want to create a NSTextField subclass that uses this cell instead of a straight NSTextFieldCell, but if you're loading stuff from a XIB, you can just change the class of the cell in the XIB and leave it in a regular text field view.
I have NSOutlineView in my App. This function
-(BOOL)outlineView:(NSOutlineView*)outlineView isGroupItem:(id)item
sets some of items in outlineView as a group root(if function returns YES) + adds show/hide buttons at the end of cell to expand/collapse content of this group, but this button written in English. I'm from Belarus, and that is why I want show/hide words written in my language. Finder writes in my language, that is why i think, what there is some option to set it localized style for it.
How I can do this?
SOLVED:
Mac OS does this itself at the time of choosing localization of .nib file what contains NSOutineView
The official way to retrieve the localized show/hide button (as well as the disclosure button) is now documented in the NSOutlineView Class Reference.
let showHideButton = outlineView.makeViewWithIdentifier(NSOutlineViewShowHideButtonKey, owner: outlineView.delegate()) as? NSButton
It's important to note the state property of the button controls the Hide/Show title, which by default is not synced to the state of the NSOutlineView:
NSOnState = "Hide"
NSOffState = "Show"
NSOutlineViewDisclosureButtonKey
The normal triangle disclosure button.
NSOutlineViewShowHideButtonKey
The Show/Hide button.
The outline view creates these buttons by calling its inherited
makeViewWithIdentifier:owner: method, passing in the key as the
identifier and the delegate as the owner.
These keys are backwards compatible to OS X v10.7, however, the
symbol is not exported prior to v10.9 and the string value
(#"NSOutlineViewDisclosureButtonKey") must be used.
I'm in need of linking some buttons in a 'document based' application to the file menu (bold text, italic text, make text bigger etc.). The issue is that since its a document based application, the MainMenu.xib is a completely different XIB file than the MyDocument.xib, so I can't drag the connections in Interface Builder like I usually would. Does anyone have a workaround? Is there a way to link button actions to a separate XIB files' built in menu functions?
Zach
Generally, you use the First Responder place-holder object.
About the First Responder
"In Interface Builder, the First Responder is a proxy object that represents the first object in your application’s dynamically determined responder chain. Because the responder chain of an application cannot be determined at design time, the First Responder proxy acts as a stand-in target for any action messages that need to be directed at the application’s responder chain. Menu items commonly target the First Responder proxy. For example, the Minimize menu item in the Window menu hides the frontmost window in an application, not just a specific window, and the Copy menu item should copy the current selection, not just the selection of a single control or view. Other objects in your application can target the First Responder as well."
Also see:
Connecting Menu Items Across Nib Files
Also, if you want to create buttons whose actions are basically the same as the Format > Bold, etc. commands, see: Connecting the Font Menu in Interface Builder 3