Update:

Further experimentation with the MSAA SDK tools reveals:

1. The C0000005 crash error can be duplicated without a screen-reader running:

Create a new VFP 7 project. Create a new free table in the project, add a memo field to the table, and append a blank record. Create a new form in the project, add a standard VFP textbox and a standard VFP editbox to the form. Set the TabIndex properties of the textbox and editbox to 1 and 2, respectively. Set the ControlSource property of the editbox to the memo field in the table you just created. Add the field to the form's DataEnvironment. Set the form's ShowWindow property to 2 - As Top Level Form. Add the following code to the form:

INIT()

THISFORM.Text1.SetFocus()
READ EVENTS

QUERYUNLOAD()

CLEAR EVENTS
THISFORM.Release()

Create a program file that contains the following code:

DO FORM editform

CLEAR ALL
RELEASE ALL
CANCEL

Build a free-standing executable from these elements. Run the executable, then run the MSAA Accessible Events Watcher. In the Events Watcher open the Options menu and choose Settings. Under events, click OBJ_FOCUS and under Object Properties click Value. Click Apply.

In the form application you just created, tab from the textbox to the editbox. Whammo. C0000005 error.

2. Comparison of what the Events Watcher reports out from Microsoft Word radio buttons and checkboxes and what it reports from those controls in Foxpro verfies that the Foxpro controls' behavior is nonstandard under some circumstances:

A. Foxpro radio buttons and checkboxes only report "State=focused,focusable" whether or not they are checked, when their ControlSource is bound to a table field.

B. When these Foxpro controls' ControlSources are not bound to table fields, they report "State=focused,checked,focusable" when they're checked and "State=focused,focusable" when they're not checked, just as standard Windows controls do in MS Word.

Both of these issues have been independently confirmed by GWMicro, manufacturers of the WindowEyes screenreader.

It's hard to believe that I'm the only programmer out here working on this issue. Surely somebody else must have seen this.

I'm sending an update to the MS bug report site, but in my view this is an urgent matter. If someone can assist me in navigating a more direct route to the VFP team, I'd appreciate it.

Thanks.

>IMO, it probably won't help to post them here. However, you should ship them off to the Fox team.
>
>
>>The screen reader is WindowEyes version 4.0. It is a very popular screen reader that works quite well with IE 5.x, MS Word, and other MSAA-compliant MS products, as well as with the Win 9.x OS.
>>
>>My findings are not based exclusively on the performance of WindowEyes with my VFP application. I've tested the VFP controls using the MSAA SDK's Accessible Events Watcher. That tool reveals that the controls are not properly reporting their state to MSAA when they get focus under certain conditions. I've created reproducible test cases that verify my findings.
>>
>>If you'd like me to post the full text of my newsgroup post here, I'd be glad to do so. It fully describes the bugs and the tests.
>>
>>Thanks very much.