Basic Cocoa Bindings: Toggle a boolean from menu in IB - cocoa

I'm just getting started with Cocoa Bindings and while I've read through much of the documentation, I'm still struggling to implement a basic feature, making me question wether I'm doing it wrong or perhaps it's just not possible via IB.
Goal: Have a menu item called "Toggle visibility" toggle the state of a Boolean property in my application controller (AppController) called "visibility." I think this should be possible completely through IB.
(Note: CoreData is not in use here)
What I think needs to happen is I need to have an NSObjectController who's content outlet is set to my AppController class. Then I think I need to use an Action Innvocation binding. But here's where I run into trouble.
Should the Controller Key be selection? Should the Model Key Path be the name of my Boolean Property? What should Selector Name be?
Or do I need to setup a separate action method called "toggleVisibility" that I can bind to? If I did, why wouldn't I just use standard target/action associations, rather than bindings?
Any input / direction appreciated.

Goal: Have a menu item called "Toggle visibility" toggle the state of a Boolean property in my application controller (AppController) called "visibility."
Your goal tells you why you are failing.
In your description of your goal, you say that you want to set this menu item up as a command, a verb, an imperative sentence—“toggle the visibility”. But that's not the right title for the menu item.
Moreover, implementing a verb menu item with Bindings is inherently difficult because Bindings is the wrong tool for the job. Bindings is for exposing properties in your UI. It isn't for performing commands.
The correct title is supported by the correct Bindings-based solution.
The correct title of the menu item is, simply, “Visible”.
This alone should give you a hint as to how to proceed. Here's another: When the selection is visible, the menu item should have a check mark; when it is not visible, the menu item should have no mark.
You want to bind a property of the menu item to, ultimately, a Boolean property of your controller. Normally, this property of the menu item would be state, but for whatever reason, the binding for it is named value.
So, bind the value binding of the menu item to the Boolean property of your controller.

Related

Performing action when NSRuleEditor criterion is selected

How can I determine which criterion is being selected in the NSPopUpButton menu of an NSRuleEditor? Inside ruleEditorRowsDidChange(_:)
I could track the criteria for each row and process the changes manually, but it seems like there should be an easier way.
I tried returning an NSMenuItem instead of a String for the criterion's value in the rule editor's delegate; then setting the target and action properties on the menu item. That allows me to have a method called when the menu item (criterion) is selected in the rule editor. It also means I know which criterion triggered the action method because each menu item's target is the criterion itself. However, setting the target and action properties on the menu item overrides the private target and action values that the rule editor sets on the menu item. This means that after selecting a criterion in the rule editor, the target/action that I set fires, but the selection change is not reflected in the rule editor.
My current solution is to return an NSPopUpButton as the criterion's displayValue (since it inherits from NSView) and manage the button's items and target/action manually. This works well but feels like it breaks the design of the rule editor a bit by having a single criterion managing multiple values itself instead of relying on the rule editor's delegate).
Am I going about this the wrong way? Is there a simpler method to run criterion-specific code when a criterion is selected within a rule editor?
Thanks!
Set the action of the menu item and inside the action call - (void)setCriteria:(NSArray *)criteria andDisplayValues:(NSArray *)values forRowAtIndex:(NSInteger)rowIndex of the rule editor to refresh the row. You can get the row with - (NSInteger)rowForDisplayValue:(id)displayValue.

Binding a Menu Item to a property of the First Responder

I have a document-based application.
In my document class,
I have a BOOL property : isActionPossible.
I also have an IBAction : - (IBAction) doTheAction:(id)sender.
Now, in MainMenu.xib, I want to connect a menu item to the action.
This is easy, when you know that the First Responder in Interface Builder "stands for" the active document of your application.
But how shall I do to bind the availability (the "enable property") of this item menu with the BOOL property isActionPossible of the active document ?
Indeed, in the list proposed, there isn't "First Responder".
Two choices:
You can implement menu validation, see Apple's docs. In short before a menu is displayed the system sends a validation request to the same object that handles the action, which includes the first responder. You simply add a method to your document class which returns a BOOL; in your case your isActionPossible property.
Use the currentDocument property of NSDocumentController which returns the document associated with the main window. You can then use bindings to bind <Document Controller>.currentDocument.isActionPossible. This approach is more general as you can bind label contents to values etc. as well as use it for menu bindings.

How to set the action of a NSButton in a binding scenario?

I have a button that is inside a view repeated inside a NSCollectionView. I can bind the title of the button to one of the properties in my model class but I want to wire the selector of the button to one of the selectors in my model class. Obviously, the button must send the message to the model object associated with the corresponding collection view item.
I managed to bind the target for the button but how to set the selector? I want to do that in Interface Builder if possible...
I figured it out. In the Ib there is a selector textbox bellow the path textbox where I bind the target. I don't know why I didn't see it. I spent nearly one hour trying to solve this issue.
How to add those blindings? I still can't find it.
I find it . It's Here.

Giving a Boolean property to a controller object in Interface Builder

After I drag a controller object to the document window, how do I give it a Boolean property?
Assuming you want the ability to expose and edit the property values of your custom controller as attributes showing up in IB's inspector, you'll need to write your own plugin which tells IB what the inspector should look like. This really can't be answered briefly.
Here's Apple's reference on IB Plugins:
http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/IBPlugInGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40004323-CH1-SW1
And here's the inspector portion:
http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/IBPlugInGuide/CreatingInspectors/CreatingInspectors.html#//apple_ref/doc/uid/TP40004323-CH6-SW1
If you truly just want to add a property to the controller's interface, you do this in Xcode (modifying the interface and implementation accordingly) and IB will pick up the changes automagically.
In the case of a checkbox, the checkbox itself is either checked or not. That state stores the boolean value instead of the controller (unless you wish it.)
To have the app undertake an action upon clicking it, think of it as a button instead of a data display and link it to an action method in the view controller. That's the simplest and old school way of doing it.
To use binding, you need to bind the checkbox's value attribute to a controller. Usually for binary values its an object controller. So, in IB, drag an Object controller to your nib window and bind it to your data source. Then, drag a checkmark button to the interface. In the checkmarks binding inspector. Set "value" binding to the name of the object controller, controller key to selection, keypath to the name of the data source attribute and provide a value transformer if needed.

What's the cleanest way to bind enumerated properties?

I have a menu which has an item for each value in an enum.
The menu:
[ ] Sort by Due Date
[ ] Sort by Priority
[√] Sort by Title
The enum:
typedef enum CW_TASK_SORT_METHOD {
CWTaskSortMethodDueDate,
CWTaskSortMethodPriority,
CWTaskSortMethodTitle
} CWTaskSortMethod;
The property:
#property(readwrite, assign) CWTaskSortMethod taskSortMethod;
What's the cleanest way to wire this up? I have two ideas but both strike me as unsatisfactory.
1st idea: Create properties for each value (sortMethodIsDueDate, setSortMethodIsDueDate: etc) These properties would call setTaskSortMethod: and call valueDidChange:#"sortMethodIsDueDate" etc. The menu items would then bind to these properties. This seems like a lot of work.
2nd idea: Connect each menu item to -(IBAction)updateSortMethod:(id)sender which could then iterate the menu items and set the value depending on sender. This approach is fine until taskSortMethod is changed by a different section of code at which point code needs to be added to keep the menu in sync with taskSortMethod.
I'm leaning towards the first approach as it has better separation between the V & C.
Any better ideas?
I think you're on the right track with your second idea, but there's something to consider:
NSMenu / NSMenuItem don't have a concept of "selected item" like NSPopUpButton for instance. I'd use the target/action mechanism to change the sort method and menu validation (Introduction to User Interface Validation) or even the NSMenu delegate method -menu:updateItem:atIndex:shouldCancel: (NSMenuDelegate Protocol Reference) to update the state of the item based on the result of -taskSortMethod.
Since the menu items only need to be updated when they're shown (which this mechanism does for you), you don't have to worry about updating the menu items yourself when -taskSortMethod changes elsewhere.
Ex:
[sortByDueDateMenuItem setState: ([self taskSortMethod] == CWTaskSortMethodDueDate) ];
IMO, this is a lot cleaner than trying to over-engineer a bindings-powered solution.

Resources