In my little cocoa application I have bound the properties of a class to some text fields with help of a NSObjectController. The only problem I have so far: you always have to leave a text field before the NSObjectController updates the class with the current input.
This becomes a problem if the user doesn't leave a texfield and clicks on a Save/Submit Button right away. The class doesn't contain the current input. Always a bad thing.
I am looking for a way to avoid this. Like telling the NSObjectController to get the current input even if the user had exited the field. If this is possible I could put this command in the save-Method before saving and all would be fine.
Send a commitEditing message to your controller in the handler for the OK button. This will do what you're asking for. It's as simple as:
- (void)save:sender {
if (![self.myObjectController commitEditing]) {
// Handle error when object controller can't commit editing
}
// Other stuff
}
If you go to the text field's value binding and check the "Continuously Updates Value" option, that will cause the new value to be set on the model object each time the user changes it, i.e. once for each keystroke. That would ensure that the model had the correct value before closing the window, though it may be a bit overkill, depending on what the effects (if any) are of the value being set in your data model.
Related
I have a sap.m.TabContainer control with multiple sap.m.TabContainerItem controls. Each of the TabContainerItem controls have a number of their own controls on them. I have created a custom control (DBPanel) with a label and text field. It also has an enabled property for which I have overridden the setEnabled(boolean) method to enable/disable the internal text field within DBPanel. There are five (5) of these DBPanel controls on a specific TabContainerItem. When I call setEnabled(true) on each of these DBPanels, only three of the five become enabled. When I switch to another TabContainerItem and then back to this one, the final two DBPanels are also enabled. It is almost as if the TabContainerItem needs to be re-rendered. But I have read elsewhere that if rerender or invalidate need to be specifically called then there is something wrong with the code.
Any help would be appreciated.
Thank you
At your overridden method, you can try to call the original method that is extended. If you don't need extra logic rather than disabling or enabling it, you don't need to extend that method but I guess you have some.
First check whether superclass implements the method and then call the
method with the original arguments
if (DBPanel.prototype.setEnabled)
DBPanel.prototype.setEnabled.apply(this, arguments);
I am new to ReactiveCocoa, but I think it's very nice and outstanding technique for reducing code complexity. I just started experiencing with the framework, and not everything is clear for me at the moment, so excuse me if my problem can be solved in some obvious way.
In my app I have login view controller with simple form contains two text fields (username and password) and a button. I would like the button to be disabled if any of two text fields is empty. So, I wrote this code:
RAC(self.loginButton, enabled) =
[RACSignal combineLatest:#[self.userTextField.rac_textSignal,
self.passwordTextField.rac_textSignal]
reduce:^(NSString *username,
NSString *password) {
BOOL valid = (username.length > 0 && password.length > 0);
return #(valid);
}];
It's very simple and it's working. The problem is that one of my text fields (the password field) has secureTextEntry and clearsOnBeginEditing properties set to YES. I will try to explain unwanted behavior that I am experiencing with this configuration:
Let's assume that both username and password fields are NOT empty. In this case the button is enabled. When user taps on password field, it becomes first responder (keyboard appears and user can enter his password), but because of clearsOnBeginEditing being set to YES for that field, the previously entered password is cleared from the text field. That's way password field is now empty. The problem is that signal is not being sent, so the button remains enabled, despite the password field is empty.
My first idea to solve this issue (well, more like workaround solution) was to observe isFirstResponder property on password field beside observing text changes. That's way the block that checks if button should be enabled would be called when password field becomes first responder. I don't know if this solution works, because I have no idea how to implement it using ReactiveCocoa. I have looking for creating a signal for isFirstResponder property changes, but without a luck. It might be not the best approach in order to solve this issue, but nothing comes to my mind at this point.
Then, the question is: how to observe isFirstResponder property with ReactiveCocoa?
And more general question: how to observe text field's text changes when clearsOnBeginEditing is set to YES?
UPDATE:
I found out that I can create signal for UIControlEventEditingDidBegin event that should give me substitution of observing isFirstResponder property changes:
[self.passwordTextField rac_signalForControlEvents:UIControlEventEditingDidBegin]
Unfortunately this does not solve the issue. Now I understand that field is cleared AFTER it becomes first responder, and clearing field automatically after it becomes first responder does not send signal for text changes. That's way when validation block is executed it still thinks that password field is not empty, and the button remains enabled despite password field was cleared and it's empty.
Unfortunately the -rac_textSignal only listens for UIControlEventEditingChanged. If UIControlEventEditingDidBegin were added, you'd be all set.
I suppose you could patch this into it and submit a pull request?
- (RACSignal *)rac_textSignal {
#weakify(self);
return [[[[[RACSignal
defer:^{
#strongify(self);
return [RACSignal return:self];
}]
concat:[self rac_signalForControlEvents:UIControlEventEditingChanged|UIControlEventEditingDidBegin]]
map:^(UITextField *x) {
return x.text;
}]
takeUntil:self.rac_willDeallocSignal]
setNameWithFormat:#"%# -rac_textSignal", [self rac_description]];
}
What is a generally accepted way to validate preference values in a Firefox extension, specifically when using the prefwindow mechanism in XUL?
I am introducing some new preferences in one of my extensions that I would like to validate before the preferences window is closed. If there's an error, the user should be allowed to correct the issue, and then proceed. I see that the prefwindow element has two potentially useful functions to help in this regard:
onbeforeaccept
ondialogaccept
The former seems to have an associated bug (Bug 474527) that prevents the prefwindow from remaining open when returning false from that function. This is bad in that it doesn't give the user an opportunity to immediately correct their mistake.
The latter appears to have the problem that the preferences get saved prior to exiting, which leaves the preferences in a bad state internally.
In addition, the prefwindow mechanism supports the browser.preferences.instantApply option, in which preference values are written immediately upon updating the associated control. This makes validation extra tricky. Is there a clean way to validate custom preferences in a Firefox extension, allowing the user to correct any potential mistakes?
Normally you would want to validate the preferences when they are changed. That's something that onchange attribute (and the corresponding change event) is good for:
<preference name="preference.name" onchange="validate(this);"/>
The event is fired after the preference value changes. There are two drawbacks:
In case of instantApply the new preference value is already saved, too late to validate and decline.
For text fields the preferences are saved every time a new character is typed. This becomes ugly if you report validation failure while the user is still typing.
You can solve the first issue by intercepting the change events for the actual input fields. For example, for a text field you would do:
<input preference="preference.name"
oninput="if (!validate(this)) event.stopPropagation();"
onchange="if (!validate(this)) { event.stopPropagation(); this.focus(); }"/>
So changes that don't validate correctly don't bubble up to the <prefpane> element and don't get saved. The events to listen to are: input and change for text fields, command for buttons and checkboxes, select for the <colorpicker> element.
The second issue is tricky. You still want to validate the input when it happens, showing the message immediately would be bad UI however. I think that the best solution is to assume for each input field initially that it is still "in progress". You would only set a flag that the value is complete when you first see a blur event on the field. That's when you can show a validation message if necessary (ideally red text showing up in your preference page, not a modal prompt).
So to indicate what the final solution might look like (untested code but I used something like that in the past):
<description id="error" hidden="true">Invalid preference value</description>
<input preference="preference.name"
_errorText="error"
onblur="validate(event);"
oninput="validate(event);"
onchange="validate(event);/>
<script>
function validate(event)
{
// Perform actual validation
var field = event.target;
var valid = isValid(field);
// If this is the blur event then the element is no longer "in progress"
if (event.type == "blur")
{
field._inputDone = true;
if (!valid)
field.focus();
}
// Prevent preferences changing to invalid value
if (!valid)
event.stopPropagation();
// Show or hide error text
var errorText = document.getElementById(field.getAttribute("_errorText"));
errorText.hidden = valid || !field._inputDone;
}
</script>
If you want to validate values as soon as the field is changed so you can handle the instantApply case, you could hook into the change events for the individual fields (e.g. oninput for a textbox). Display an error message and force the focus back to the field if the value is invalid. You can either set it back to a valid value automatically or block the user from closing the dialog until it is fixed.
When coding with cocoa I've noticed that it's not necessary to have sender parameter when defining IBAction, hence following action:
- (IBAction)showUserInfo:(id)sender;
can be declared as
- (IBAction)showUserInfo;
So I'm wondering if there is any other benefit besides having the button/menu item that sent the action? Only other situation I can think of is having few objects calling same IBAction. Anything else?
Doc says,
The sender parameter usually identifies the control sending the action message (although it can be another object substituted by the actual sender). The idea behind this is similar to a return address on a postcard. The target can query the sender for more information if it needs to.
The sender parameter helps if you want any data from it. For example, on UISegmentControl value change, as in #Mark Adams answer. So if you don't want any information from the sender, you can just omit it, as in your - (IBAction)showUserInfo; example.
It can be handy to use the sender argument when you're connecting the method to UI objects whose values can change and you may need to work with.
For instance if I wired up a method to a UISegmentedControl and set it's control event to UIControlEventValueChanged, I can use the object passed as the sender: argument to obtain it's selected segment index and then, based on the value, make a change in the UI.
-(IBAction)segmentedControlValueChanged:(id)sender
{
UISegmentedControl *control = (UISegmentedControl *)sender;
// Show or hide views depending on the selected index of the segmented control.
if (control.selectedSegmentIndex == 0)
someView.hidden = YES;
else
someView.hidden = NO;
}
I recently started another thread without an account, so I'm reposting the question here with an account so I can edit current links to the program so other users can follow this. I have also updated the code below. Here is my original question:
I read the other post here on Outlineviews and DND, but I can't get my program to work. At the bottom of this post is a link to a zip of my project. Its very basic with only an outlineview and button. I want it to receive text files being dropped on it, but something is wrong with my code or connections. I tried following Apple's example code of their NSOutline Drag and Drop, but I'm missing something. 1 difference is my program is a document based program and their example isn't. I set the File's Owner to receive delegate actions, since that's where my code to handle drag and drop is, as well as a button action. Its probably a simple mistake, so could someone please look at it and tell me what I'm doing wrong? Here is a link to the file: http://dl.dropbox.com/u/7195844/OutlineDragDrop1.zip
You're not responding to NSOutlineView's drag-validation message.
Your original code implemented tableView:validateDrop:proposedRow:proposedChildIndex:. As I pointed out on that question, that's wrong when your table view is an outline view; NSOutlineView will not send a table-view drag-validation message, only an outline-view drag validation message.
You've since changed your drag-validation method to be declared like so:
- (NSDragOperation)outlineView:(NSOutlineView*)view
validateDrop:(id <NSDraggingInfo>)info
proposedRow:(int)row
proposedChildIndex:(NSInteger)index
But nothing actually sends such a message.
Remember that NSOutlineView rarely deals with row indexes, since those can change as parent rows are expanded and collapsed. It deals instead with “items”, which are generally model objects.
Therefore, the correct validation method is:
- (NSDragOperation)outlineView:(NSOutlineView*)view
validateDrop:(id <NSDraggingInfo>)info
proposedItem:(id)item
proposedChildIndex:(NSInteger)index
Notice the name of the third component of the selector, and the type and name of the argument that goes with it.
With this change applied, your data source validates drops.