Support edit fields in MS Access

[nvaccessAuto]

Reported by briang1 on 2010-07-19 13:56 In a few MS Access applications and databases I have, although its possible to use them in the main, even in Access 2002, the edit fields do not act correctly when cursored or deleted, acting as if they are in fact blank. Also, sometimes when something is typed it remains and when you come back it is spoken but its in fact not there at all.

In order to help at least with the main problem, I'm hopefully attaching a very small application with one edit field that changes system date. It does show the editable problem. The nvda f1 reports as follows. INFO - appModules._default.AppModule.script_navigatorObject_devInfo (14:46:03): Developer info for navigator object: name: u'Change System Date to' role: ROLE_EDITABLETEXT states: STATE_FOCUSABLE, STATE_FOCUSED Python object: <NVDAObjects.IAccessible.IAccessible object at 0x022F0E50> Python class mro: (<class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>) description: u'' location: (230, 216, 100, 15) value: u'' appModule: <_default (appName msaccess, process ID 1072) at address 2372510> TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'> windowHandle: 394006 windowClassName: u'OForm' windowControlID: 1041 windowStyle: 1456406528 windowThreadID: 600 windowText: u'System Date Form : Form\x00' IAccessibleObject: <POINTER(IAccessible) ptr=0x1c18f0 at 2313490> IAccessibleChildID: 0 IAccessible event parameters: windowHandle=394006, objectID=3, childID=0 IAccessible accRole: ROLE_SYSTEM_TEXT IAccessible accState: STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048580)

[nvaccessAuto]

Attachment System Date.mdb (System Date.zip) added by briang1 on 2010-07-19 14:00 Description: Small access app with macros shows eddit prob. Update: File added from Trac

[nvaccessAuto]

Comment 1 by jteh on 2010-09-24 06:59 Tried to get this working with display model. Unfortunately, although our display model code can retrieve the text, it can't seem to find the caret. This is very low demand and probably very hard to fix.

Technical info for reference:

• Access seems to first fire a focus event on a window with class of OKttbx, MSAA role of client. Interestingly, the caret must be in this window because we automatically use !DisplayModelEditableText. (This must also mean the caret is in this window.) Unfortunately, this object doesn't contain useful info such as the name of the control.
• It then fires focus on an object with window class OForm, MSAA role of text and positive object ID. Unfortunately, using !DisplayModelEditableText here can't find the caret; see above.
• It's possible that the location of the OForm object is wrong and that we'd have better luck finding the caret with OKttbx. However, this requires us to somehow keep track of the OKttbx object while still moving focus to OForm. And I'm not even sure if this would work. Yuck. Changes: Milestone changed from 2010.3 to None

[nvaccessAuto]

Comment 2 by briang1 on 2013-04-11 17:32 I tried a runtime version of Access 2010 and the issue still occurs in xp as far as I can tell.

[nvaccessAuto]

Comment 3 by briang1 on 2013-11-13 10:39 Obviously in XP I cannot try Access 2013, but have been told the app crashes when nvda is run in windows 8.

[nvaccessAuto]

Comment 4 by nvdakor on 2013-11-18 07:51 Hi, Interestingly, in Access 2010, if I press backspace, I can tell that the obj.name changes. Technical (for Access 2010 under Windows 8.x):

• As Jamie said, devInfo says window class name is the name that was mentioned, and the obj.name is the text itself. This can also be verified if I do curNavObject command (NVDA+Numpad5) and checking each time I press BACKSPACE.
• Also, the MRO list contains dynamic_displayMOdel and iAccessible at the same level, indicating multiple inheritance 9not that useful, but hopefully could be a handy note). This ticket is by far the biggest show stopper for MS Access app module - something that gives me headache... Thanks.

[LeonarddeR]

@brian1gaff: Could you provide a status update for this issue?

[Adriani90]

@Brian1Gaff could you please give us an update regarding this issue? Could someone upload the attachment? I want to try it with newest NVDA and MS Access version. Thanks.

[ehollig]

@Adriani90, I have edited the original comment with the attachment.

[Adriani90]

I have tested this in MS Access. This attachment is not working properly after a security updated from MS made in June 2017. I guess this application has been created with a really really old MS Access version (maybe MS Access 2000). I get runtime error 13 when trying to delete the content in the field. That means that types are not consistent because they are using different programming sets. I also get runtime error 70 when typing the new system date and press enter. This is a permission restriction introduced by the new security update for very old MS Access files.

[Adriani90]

In any case, when i type something in the "change system date to", it is spoken by NVDA. When I press tab twice I land on the change date field and the content is being reported as it should be.

[Adriani90]

This issue cannot be reproduced peroperly, I suggest closing it. @Brian1Gaff, please open a new issue with current MS Access file (preferably MS Access 2007 or higher).

[josephsl]

Hi,

Actually, with Office 2010 and higher. Closing. Thanks.