cancel
Showing results for 
Search instead for 
Did you mean: 

problem with MSAA support (accessiblename) in datawindows

Former Member
0 Kudos

We use Powerbuilder 12.5 with Jaws (a screen reading software for blind people). We want to use the accessiblename property to manipulate the text read by jaws. This works fine for most controls in datawindows e.g. checkboxes or dropdowns. But it doesn’t work for edit controls (i.e. style type “Edit”) within datawindows.

    

Is there a solution for this problem? Has anybody any experience with the usage of Jaws and the MSAA features in powerbuilder?

The text left of the field is usually read as description for the control. But we have to enhance an existing application and therefore we do not always have enough space to place a good description there. To make the MSAA features work would help.

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos


Hello Sandra,
This is an issue that engineering had investigated with PowerBuilder 11.5 and was determined not to be a bug.  The follwoing was their explanation:

"As  an acc server, PB exposes a datawindow as one IAccessible object , we didn't expose sub windows/controls inside the datawindow. According to MS acc SDK , clients (like Jaws) should access all acc information only through this IAccessible pointer. We used an edit window in dw to allow column editing, but we didn't expose an accessible object for this edit window, because this is just a detail in implementation. In such situations, MS oleacc provides a proxy to a client, so what a client gets is not what PB provides, This is the reason that a client can't get correct accessible information of an edit in a dw. In my point of view, this is a design fault in MS MSAA architecture.

The following is what I got using accEvent32.
///////////////////////////////////////////////////////
OBJ_FOCUS  Context=IN Event=8005 HWND=00061140 idObject=FFFFFFFC idChild=0
ThreadID=1B8 Window class="pbdw110" Name="none" Role=client State=normal
OBJ_FOCUS Context=IN Event=8005 HWND=000C10F2 idObject=FFFFFFFC idChild=0
ThreadID=1B8 Window class="Edit" Name=none [false] Role=editable text
State=focused,focusable
OBJ_HIDE (hidden) Context=IN Event=8003 HWND=000C10F2 idObject=0 idChild=0 ThreadID=1B8 Window class="Edit"
OBJ_FOCUS Context=IN Event=8005 HWND=00061140 idObject=FFFFFFFC idChild=0
ThreadID=1B8 Window class="pbdw110" Name="none" Role=client State=normal
OBJ_LOCATIONCHANGE (hidden) Context=IN Event=800B HWND=000C10F2 idObject=0 idChild=0 ThreadID=1B8 Window class="Edit"
OBJ_VALUECHANGE (hidden) Context=IN Event=800E HWND=001110FC idObject=FFFFFFFC idChild=0 ThreadID=1B8 Window class="Edit"
OBJ_FOCUS (hidden) Context=IN Event=8005 HWND=001110FC idObject=FFFFFFFC idChild=0 ThreadID=1B8 Window class="Edit"
OBJ_FOCUS Context=IN Event=8005 HWND=00061140 idObject=FFFFFFFC idChild=39
ThreadID=1B8 Window class="pbdw110" Name="Employee ID" Role=editable
text State=normal (Blue line per below ////)
OBJ_LOCATIONCHANGE Context=IN Event=800B HWND=001110FC idObject=0 idChild=0 ThreadID=1B8 Window class="Edit" Name=none [false] Role=window State=focused,focusable Location={l:359, t:184, w:45, h:15} (Red line per below ///)
/////////////////////////////////
Please note the blue line, this event is really fired by PB, it clearly said that one child element (id=39) in the dw (hwnd=00061140) got focus, the Name "Employee ID" is correct.

While the OBJ_LOCATIONCHANGE event in the red line is not fired by PB, MS oleacc sends it to a client automatically when the edit window moves inside the dw. When handling this event, the JAWs client tries to get an IAccessible object for the edit window. However, as I had explained before, PB didn't provide it, MS oleacc will return a proxy to the client. Obviously, this breaks.

So, I it's not a bug of PB."

I hope this answers your question.

Ted Zimmerman

Former Member
0 Kudos

Hi Sandra;

  We used this at the Supreme Court of Canada for our web applications with PB supplying the web pages using the HTML DataWindow feature. We had to make sure that the web pages were JAWS compatible, Whenever we found a deficiency like this (I seem to remember the EDIT style issue) we just tweaked the HTML as required.

  For native Win32 or  Winform applications coming from PB Classic or PB.Net though the support would have to be at the internal Window Control level. So, I would categorize this as a PB "bug" and report this to SAP technical support.

Regards ... Chris