[TIMOB-5051] Next field property on text entry widgets
GitHub Issue | n/a |
---|---|
Type | New Feature |
Priority | Low |
Status | Closed |
Resolution | Won't Fix |
Resolution Date | 2012-08-08T15:02:59.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | iOS |
Labels | n/a |
Reporter | Blain Hamon |
Assignee | Blain Hamon |
Created | 2011-08-18T15:40:42.000+0000 |
Updated | 2017-03-22T20:31:38.000+0000 |
Description
Proposing that there is a property on textField (and textArea?), called 'nextField' (TODO: maybe just 'next'?) that is of type textField (Area?).
For purposes of this spec, the return key is the key on a hardware or software keyboard that can generates a return and/or newline character. On iOS, this enter key may be renamed to Yahoo, Google, Go, etc, but is still a return key.
A text widget is defined as a textField, but on further review may also be a textArea. In future, this may be expanded to included other widgets that accept keyboard input.
"Focused text widget" refers to a text widget that has focus at the beginning of the behavior, and during the spec, is referring to only one specific text widget.
"Next widget" refers to the text widget that will gain focus at the end of the behavior.
When the focused text widget's suppressReturn boolean property is YES AND the return key is pressed, this behavior occurs to find the next widget and give it focus:
Starting with the next widget being the "nextField" property of the focused text widget,
If the next widget is 'null', 'undefined', or the focused text widget itself, the behavior is done and no new text field is focused.
If the next widget is a text widget that is onscreen, the behavior is done and this next widget is focused. Note that some lazy-loader interfaces may mean a text widget may not be onscreen despite being a child of an onscreen view.
If the next widget is a text widget that is not onscreen, the "nextField" property of the next widget is stored at the new 'next widget' and the search loops.
If the next widget is none of the above, then the behavior is undefined.
It is the end developer's responsibility to make a logical chain of nextFields, from the topmost to the bottommost, and their option to have the lowest widget declare the topmost widget the nextField for 'looping'.
After talking with Don, decided that this feature needs more planning before work, and now is not the time. So not into 1.8.
Due to issues that might arise, and the fact that the customer case turned out to be different, marking as 'won't fix' due to lack of need.
Closing ticket as the issue will not fix and with reference to the above comments.