It seems that the NSDatePicker nextKeyView is never taken into account.
I can key tab to the NSDatePicker, but never get out of it though nextKeyView is correctly set.
When inside the picker, if I press the tab key, the focus goes correctly from day to month to year text fields, but is sticked in year text field and does never go to the nextKeyView control.
Same thing in the reverse direction, shift-tab goes correctly from year to month to day but is sticked there inside the NSDatePicker.
I guess this is a bug of NSDatePicker.
How can I subclass (or any other type of solution) to overcome this problem ?
Also, a log of the next key view chain, just to prove they are set
Initial first responder <NSTextField: 0x100587c60>
next key view <NSDatePicker: 0x6000035008f0>
next key view <NSComboBox: 0x100636740>
next key view <NSTextField: 0x10063e5a0>
next key view <NSTextField: 0x100587c60>
Here is the catch :
The controller that manages the view has a keyDown: method, because it needs to react on a "delete" key down. This method was not calling [super keyDown:event] if the pressed key was not "delete" (such as the "tab" key).
Adding the call to super when the key is not to be handled by the controller solved the problem.
Why was a tab key pressed handled correctly in some cases (e.g. when focus is on a text field) and not other cases (e.g. date picker) remains unexplained.
Thanks to all the persons that posted comments and help me figure this out.
Related
I'd like to alter a cell's data, but only when it enters "edit" mode. There are a lot of events I can use, onSelectionByProp seems close but it's firing too often to be useful. Let's say, for instance, that I want to add '*' to a cell that has a value that is invalid in some way, but only when that cell is about to be edited. OK, it's a silly example but it's easier to explain that than what I'm actually doing.
My current approach (haven't done it yet) is to find TD.current when a cell is double-clicked and then alter the text directly. Ideally I'd like to find a "retrieve data" event and alter what's coming back from that.
You can map keyup, keydown, keypress or change event from jQuery for .handsontableInputHolder element in a page. Is a textarea in which user enter data, so this is your 'edit mode' for handsontable.
onEditBegin is a proposed event for future version.
See here for list of events
I'd like to send a keypress to a SysDateTimePick32 common control.
Imagine the following scenario: There is a table with many rows and many columns, which is user-drawn. When you hit "Enter" in one of those columns, a SysDateTimePick32 control is created and placed into the current cell so you can pick a time for this cell's actual content. This works fine, but I'd like to enable the user to start editing the time without pressing enter first.
This means: The table is in "display" mode and a cell is selected. There is no SysDateTimePick32 control, yet. Instead of pressing enter (and therefore creating and showing a SysDateTimePick32), the user types e.g. "3". Now a SysDateTimePick32 should be created and shown and the previously typed "3" should be sent to it, just like the user pressed "enter" and then "3".
I'm trying
SendMessage(sysDateTimePick32Handle, WM_KEYDOWN, '3', MAKELPARAM (1, 0));
However, this does not seem to work.
What is a "clean" way to send specific keystrokes to a Win32 control, especially SysDateTimePick32?
Sending keystrokes like that is filled with bear traps. It isn't clear why it would not work, although it is the wrong way. WM_KEYDOWN is posted, not sent, so you should use PostMessage() instead. For typing keys like '3' you should send WM_CHAR instead, saves you from the hassle of getting the modifier keys state set properly (Shift, Ctrl, Alt) and removes the active keyboard layout as a failure mode. Favor SendInput() if that's not appropriate.
Do consider the less hacky way that makes this easier. Just always create the picker when the focus enters the cell. Destroy or ignore it when you find out that nothing was entered.
I have several text fields and would like to set a particular order in which they would cycle when the tab key is pressed. Currently, it starts at a text field with becomeFirstResponder and then goes on in the default order which xcode put. Can I somehow bypass that order and force the text fields to cycle in a particular order? Like linking the last one of the cycle back to the first one.
Thanks for the help.
Connect the initialFirstResponder outlet of your window to the first text field, then build a chain by connecting the nextKeyView outlet of that text field to the text field that should come next (and so on).
That's called the key view loop.
I have an NSTableView in which I need to be able to intercept keyboard events within an editable cell and replace the cell with strings. For example, press "a" and have the "a" intercepted and the value "Alpha" assigned when the table reloads. The actual situation is a bit more complex in that I'm also handling HID devices, but that's a whole other story. Suffice it to say, I just want to be able to go into edit mode and stop the keyboard-generated values from being displayed.
The latter part of this (displaying "Alpha") is easy, but I can't figure out the first part of the problem. If I subclass the table and make it first responder, I can receive the keyDown: event, but once the user double-clicks on a cell and starts typing, this goes silent.
Since none of the other NSTableView components (NSCell, NSTextFieldCell, etc) derive from NSResponder, I'm assuming there is an NSTextField buried in there somewhere.
So, what's the best way to filter text once the user goes into cell edit mode?
As always happens: after working on this for eight hours, reading all the docs five times, and then resorting to the net, I find the answer five minutes later:
- (BOOL)textShouldBeginEditing:(NSText *)textObject.
Sorry to consume bandwidth.
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.