Board index » delphi » Q: Delphi's *Improper* Windowed Controls in need of a fix

Q: Delphi's *Improper* Windowed Controls in need of a fix

Hi all,

I am writing apps for blind users.  They have access to Windows
through speech synthesizers and screen reading software.  In order for
the screen reader ("Jaws" in particular) to read dialog boxes, it
accesses the WINDOW STYLE attribute of each focused control and
reports the name of the control, the type of control, and the state.
(e.g. speaking  "Auto Save, Check box, Unchecked", or "OK Button" ).

Here's my major problem:

Delphi doesn't set the proper window attributes to allow the screen
reader to identify controls. You can see this if you have
WinSight.Exe. Open a detail window for a control in an app created by
Delphi, and under the Window Style item you will see the type of the
control is missing (PushButton, GroupBox, etc). Apps generated by
MSVC++ have the name showing up properly.

The source of the problem is (heh) in the source of the VCL. In
Controls.Pas, for the tWinControl class, the CreateWnd procedure calls
CreateParms, then CreateWindowHandle which does the Windows API call
to CreateWindowEx (using the parameters set in CreateParams).
CreateParams imposes its own incomplete set of Style attributes based
on some settings in Delphi. This is where BS_CHECKBOX, BS_PUSHBUTTON,
etc. need to be set (I think). I've tried using SendDlgItemMessage and
SetWindowLong to modify the style attribute after the window is
created, but evidently some of the values have to be set *before* the
control's window is created.

 :-O

Why, oh why did Anders' minion not set these switches?

TLabel is another issue entirely since Delphi doesn't even create
windows for them. I can get around that one by writing my own windowed
Label component.

Is there a way to inherit from TWinControl, override CreateWnd, set
the proper Style values, and then let the rest of the heirarchy
inherit from the improved tWinControl?  Or do I have to <gasp> modify
the VCL?  (Are these questions from an OOP retard?)

Or...  is there some other way to fix the Window Style after it is
created so I don't have to invade the VCL.  

Any ideas, anybody?

Thanks * 1,000,000

Gary Barber
gbar...@erols.com

 

Re:Q: Delphi's *Improper* Windowed Controls in need of a fix


Quote
On Wed, 11 Dec 1996 23:11:09 GMT, gbar...@erols.com wrote:
>Is there a way to inherit from TWinControl, override CreateWnd, set
>the proper Style values, and then let the rest of the heirarchy
>inherit from the improved tWinControl?

You cannot just "squeeze in"...

Quote
>Or do I have to <gasp> modify
>the VCL?  (Are these questions from an OOP retard?)

This is certainly an option...but...

Quote
>Or...  is there some other way to fix the Window Style after it is
>created so I don't have to invade the VCL.  

...you almost found the solution yourself - good!

Create your own descendands and use these only, e.g. for TEdit:

  TNewEdit = class(TEdit) { or, perhaps, derive from TCustomEdit ?}
  protected
    procedure CreateParams(var Params: TCreateParams); override;
  end;

...
procedure TNewEdit.CreateParams(var Params: TCreateParams);
begin
  inherited CreateParams(Params);
  Params := Params + .... ; { what you need / want }
end;

You effectively get the old TEdit + the changed creation behaviour.
--
Stefan Hoffmeister                   Stefan.Hoffmeis...@Uni-Passau.de
University of Passau, Bavaria, Germany

Re:Q: Delphi's *Improper* Windowed Controls in need of a fix


Quote
On Wed, 11 Dec 1996 23:11:09 GMT, gbar...@erols.com wrote:
>I am writing apps for blind users.  They have access to Windows
>through speech synthesizers and screen reading software.  In order for
>the screen reader ("Jaws" in particular) to read dialog boxes, it
>accesses the WINDOW STYLE attribute of each focused control and
>reports the name of the control, the type of control, and the state.
>(e.g. speaking  "Auto Save, Check box, Unchecked", or "OK Button" ).

>Delphi doesn't set the proper window attributes to allow the screen
>reader to identify controls.
...
>TLabel is another issue entirely since Delphi doesn't even create
>windows for them. I can get around that one by writing my own windowed
>Label component.

If I understand the problem, you are writing a custom application for
visually impaired users, but you are letting the users use their
existing Windows screen readers.

My question is, "Why?"

Windows screen readers have major problems. If you are using a TMemo
component, for example, the average screen reader just reads the text
that appears in the control, but cannot read anything that has
scrolled out of view.

I recommend making your application self-voicing. It's harder, of
course, but it works. You can read all the text in the TMemo
component, not just the text that is currently visisble. This goes for
any control, such as an edit box that holds a very long file name.

Eventually, Microsoft will finish its accessibility SDK, but until
then, if you are going through the trouble of creating new components
just for a custom application for visually impaired users, why not go
all the way and make the application self-voicing? Your users will
appreciate the extra effort.

If you want to use the screen reader method, you can try deriving new
controls from the Delphi controls, and change the window styles and
class names to match the standard Windows controls. I don't know if
that will work, but it's worth a try. Override CreateParams.

--
Ray Lischner, Tempest Software, Inc., Corvallis, Oregon, USA
Author of Secrets of Delphi 2 (http://www.tempest-sw.com/secrets/)

Other Threads