Why does the cursor change position after inputing a single character in a NULL field?

466
1
12-26-2019 09:43 AM
JOSHUALOGSDON
New Contributor III

Why can I not type sequence of characters (like 123) in the correct order? This is just an example of an issue where I click on a NULL field to input a value, and the cursor changes position after a single character is typed. This has been happening on ArcGIS Pro 2.4.2 and 2.4.3.

0 Kudos
1 Reply
DavidBollinger
New Contributor III

I wanted to ping/refresh this topic, and provide some additional information (per my experience anyway), because this is STILL happening (as of 3.1.0), and is INCREDIBLY frustrating!

Perhaps the key bit of info is that (for me, at least) this does not occur with file-based data - only occurs with data sourced from our EGDB (MSSQL-based).

But for any data stored in the EGDB, the first edit to a field will result in the "cursor moved back before first character typed" behavior - so that typing "123" results in "231", or typing "abc" results in "bca".

Sometimes, subsequent edits to that same field (e.g. tab or click away, then come back) will not exhibit the behavior (ie, will work as expected, correctly), but repeat a second/third/etc time and bad behavior might return again.  (and this unpredicatability makes it even harder to try to find a "muscle memory" keystroke approach work-around)

The field doesn't have to be null (though a null value ALSO exhibits problem) - attempting a first edit to an already-populated field as an "overwrite" will still do the cursor shuffle and "scramble" typing order as described. by OP..

Say a field contains pre-existing value "test", now single-click the field within attribute table, the entire field will highlight, but it's not yet in edit mode (indicated by bold outline and highlighted value inside), now type "abc" intending to overwrite/replace the entire value, and you'll get "bca".

I suspect there's something about the timing of the first typed character "auto-entering" edit mode (and perhaps a database read for a row lock) that causes the cursor to reset.  The only known workarounds involve using a different activation sequence..

If you slowly single-click twice (not double-click*) the field to highlight it first, then explictly enter edit mode, then any pre-existing value should remain selected and you can overtype it without cursor-shuffle - this is the only "reasonable" work-around known. (*double-clicking isn't as suitable because ~50/50 chance it won't leave pre-existing value selected)

6 bad, 3 good, in this screen capture:

arcgispro_bugged_field_editing_cursor.gif

0 Kudos