Lets say I have a secured textfield and I am trying to change the focus to some other textfield on UIControlEventEditingChanged by calling BecomeFirstResponder or ResignFirstResponder then the last character is still visible
I am changing the focus to second text box when it reaches three characters but you can see third character is still visible even after the focus is on next textfield and one more character was also typed in.
if you non-programatically i.e manually change the focus from secured textfield to some other textfield then this problem is not happening.
Has anybody discovered any workaround to fix the issue ?
Please click here to go to a sample project which demonstrates this problem
P.S
I have already reported the issue in Apple Bug Reporter
Related
I originally had code that set the focus to the first widget in a dialog, in the onInit method. But there were problems with it: if I pressed TAB, indeed focus moved to next control (wxTextCtrl), which got the blue 'focus' color, but the 'focus' color/highlight was not removed from previous focus widget. So now it looked like both first and second control had focus at the same time...
When cycling manually (by pressing TAB) full circle (till last control and then wrap around to the first), suddenly all worked well. That is, when moving focus from first control to next one, the first visually lost focus (blue color was removed) as it should. From now on, only one item had the focus color/highlight.
So instead of setting focus on the first control, I tried a different approach: I set the focus to the last control in the dialog, which is always the OK button. Next, I want to emulate programmatically that a TAB is pressed and received by the dialog. So I wrote this (inside Dialog::onInit):
m_buttonOK->SetFocus();
wxKeyEvent key;
key.SetEventObject(this);
key.SetEventType(wxEVT_CHAR);
key.m_keyCode=WXK_TAB;
ProcessWindowEvent(key);
Now the focus indeed moves away from the OK button, but it does not wrap around to the first control.
Only when I manually press TAB after the dialog opened, the first item gets focus.
Question: why does this wrapping around to set focus on first widget not work with the code shown above?
First of all, your initial problem is almost certainly related to not calling event.Skip() in one of your event handlers, see the note in wxFocusEvent documentation.
Second, you can't send wx events to the native windows, they don't know anything about it. In this particular case you can use wxWindow::Navigate() to do what you want, but generally speaking what you're doing simple can't, and won't, work reliably.
I have a Cocoa Form (xib) which contains some NSTextFields and an NSMatrix of NSButtonCells. I can use the "Tab" key to tab though the NSTextFields, but the NSMatrix gets skipped over.
I want to be able to tab into the NSMatrix, and tab from one button to the next within the matrix.
I have put in the following line of code, but it is having no effect:
[mtxMyMatrix setTabKeyTraversesCells:YES];
Can anybody help with this problem or point me to an example? I have searched for hours with no success.
I had a similar problem and the solution I found was fiddling with the "first responder" setting. Specifically, making sure that the entire form didn't refuse, and each individual field likewise accepted first responder status. Again, the whole form, and each field as well. I too searched for a while... :( I'm also noob.
Inside a MFC dialog, I have 2 overlapping rows of text boxes (what user can see is only one row). when I clicked a button, i shifted down the row at bottom, so now user can see both rows.
The problem is if I have some data loaded in DoDataExchange() for the text boxes, I wouldn't be able to see them showing when the dialog boots up. But when I click inside the text box, the data shows.
I want to know what exactly happen when I clicked a UI? What drawing functions are invoked at backgrounds? So I can fix my problem.
Thank you.
ZQ
Nothing is drawn when you click, maybe you are seeing an Invalidate() being triggered for some reason that redraws the text boxes. Or maybe the parent control (dialog, I assume) doesn't have WS_CLIPCHILDREN set, or some other funny things are happening with the WS_CLIPXXX flags (they're somewhat of a black art).
More to the point, use Spy++ to check what 'happens' when you click - i.e. the messages that are posted at each point in time.
I have the same initial problem as described in Integrate NSStepper with NSTextField:
I need to have a NSTextField working with a NSStepper as being one control so that I can edit an integer value either by changing it directly on the text field or using the stepper up/down arrows.
Using bindings as commented on by carlosb results in a usable UI. However, in the initial question carlosb describes the following:
Problem is that if I edit the text field then click the stepper again it will forget about the value I manually edited and use the stepper's internal value.
This is why I am posting a variation on this question again. carlosb's use of bindings doesn't solve this problem. This happens in both the current project I am working on and a test project I have created. The test project can be found at GitHub. You can download it there (even without git) via the "Download Source" button in the top right.
Is there a clean way to solve this issue?
Text fields and sliders are both in the view layer of the MVC pattern. You'll have much better results by binding both of those views to a property of your controller.
Your problem is that that the editing isn't ended until you press return or the field loses focus (so the number is never actually changed). If you press return or leave the field after editing, you'll see it works as expected.
One solution is to check the "Continuously Updates Value" option in the text field's value binding and check the "Continuous" option in the text field's attributes.
This will make sure the value is being updated as it's typed, so an immediate click on the stepper will reflect these changes.
There are times when it makes sense to force an end of any edits that are currently being made. For instance, if the user is typing a value in a field on my document, and then clicks to the preview window, or chooses "Print" or "Save" from the menu.
The problem is, by forcing an end to editing (either by asking the NSWindow to make itself first responder, or by calling endEditingFor: on the window), the first responder focus is no longer on the field in question. This is disruptive to the user in some situations, where the action being taken is iterative and does not signify an end to their work on the document.
My first attempt at solving this is to pay attention whatever the current firstResponder is, and then to restore it after ending editing, by using NSWindow's "makeFirstResponder:". This works OK, but it has the undesired effect e.g. on NSTextFields of resetting the selection in the field editor to the entire length of the string contents.
Is there some trick I can use to force the entire system of "endEditing" methods to be called without disrupting the current field editor at all?
Thanks,
Daniel
Why not use your original method but also record where/what the selection range looks like and restore it after restoring the first responder?
I agree that this is the way to do it. On iPhone it is particularly important not to have the keyboard jumping up and down at inopportune moments. I have used:
[textView endEditing:YES];
[textView becomeFirstResponder];
successfully to complete pending spelling correction (as though a space were hit) before taking action on the content of a UITextView, but without any side-effects.