Background: I have a custom derivation of NSTextField that I am trying to use as a cell in a grid similar to a spreadsheet.
I have set the nextKeyView of my NSTextField and am confused between two states that the NSTextField can have BOTH of which involve it having the blue focus-ring drawn around it:
- the cursor is blinking in it => in this case the TAB key behaves as expected and moves to the
nextKeyViewand it is in a "text accepting" mode - it has not quite "entered" the text field for the purposes of text editing => the TAB key does not respond with KIC behaviour and move to the
nextKeyViewand trying to enter any text just in fact results in the following:
-[NSEvent key]: unrecognized selector sent to instance 0x60800012bf40
From background reading and a bit of debugging it appears that the first state corresponds to control/focus being handed off to the window's shared text editor and the custom NSTextField actually loses firstResponder status in this process.
What's interesting is how this differs from the behaviour of two standard NSTextField controls dragged onto an NSView in Interface Builder. Running such a simple app only the first state above is present at all as you tab from one NSTextField to the other! I am glad to have the intermediate second state in my app (because I need it) but I don't understand why it is happening...
Summary: two related questions
How do I programmatically control the
NSTextFieldentering these two states of effectively accepting text and not while it has the focus [I do not know how to achieve this at all so this is my main problem...]How can I get the KIC behaviour in the situation where the
NSTextFieldhas the focus but is not in "text editing" mode since this is the behaviour I am trying to get. [My current conclusion is that KIC does not work in this situation and that standard practise would be to resort to the regular overriding ofkeyDownfor the set of keys that would normally be associated with KIC.]
