Unknown action with subform in datasheet mode

[BJZeak]

Don't recall seeing this action before ... thought it was due to having the form Key Preview turned on ... does the same thing with Key Preview off ... basically the Parent form has no TabStops ... the Subform, in datasheet mode, is given focus within the Parent's form load routine ... only one field/column is unlocked in the subform which has always has focus ... subform record selectors are on.

When I press TAB or Arrow Down, the Selector changes to a pencil and doesn't move to the next row (what I am expecting) ... I then must press Tab or Arrow Down, AGAIN, before the selector changes back to an arrow and drops down to the next row (selector is an arrow again) ... have I inadvertently turned some feature on that is doing this or is this a normal operation? Do I have to trap Tab and Arrow keys and FORCE a NEXT or PREVIOUS record? It is not intuitive having to press the arrow key twice to move to the next row?

 

[dhookom]

I just created a form with a subform as you have described and the behavior of the up, left, right, and down arrow as well as the tab and shift tab move to the next or previous row as expected. I don't see the pencil (this suggests the record is being edited by you) unless I actually start typing in the control. My selectors are not "arrows" but rather just a colored selector.

I am running Access 2016.

Duane
Minnesota
Hook'D on Access
MS Access MVP 2001-2016

 

[BJZeak]

Thanks ... probably comes down to over complication

This field's lostfocus event was setting a dirty flag (another field on the record) which in turn was causing the EDIT (Pencil) issue ... may be some cart before the horse scenario whereby the field loosing focus is being given back focus due to the update of another field in the row

The intent is to make a dynamic editor for any table and or XML file (the editor builds a temp dynamic table where each table|XML field|element is a separate row and the field|element value is converted to a string) ... the SAVE button on the Parent is supposed to update fields|elements that are dirty

To solve the Pencil issue, now updating an array value on the parent with the record's position instead of another field on the same record

Functionality:
got focus sets a before value
lost focus compares the before value to the current value
if the compare fails, a parent function sbDirtyField is called with the record's index/position which updates a local var gsDirtyField

On save ... if not isnull(gsDirtyField) any record values indexed will be updated on the actual table or XML file ... one could do a direct actual field to dynamic field row comparison but the DirtyField approach is quicker.

Basically have several online forms exporting XML files which update tables in Access ... the XML files and the Data collected sometimes require tweaking ... not wanting to have to build N editors tailored to each XML|Table Format ... there are plenty of XML editors but found they were too involved for the end users.