Hello,
If I want to add a functionality like accessibility to WidgetSet, which package could I use, lcl.lpk, or lclbase.lpk?
Also, how can I rebuilt the package when I modify/add some unit? Do I need to always rebuild the IDe, or there is a quicker way? I am thinking about syntax check / quick compilation to incrementally check and fix semantic / syntax errors.

Thanks

Lubos Pintes wrote

If I want to add a functionality like accessibility to WidgetSet, which package could I use, lcl.lpk, or lclbase.lpk?

I believe "accessibility" is beyond the scope of the LCL. It is expected that the underlying GUI toolkit (Qt, GTK, fpGUI etc) implement the accessibility and will magically be available in your application, if accessibility is enabled in your desktop environment.

Regards,
Graeme

Am 08.10.2017 23:15 schrieb "Graeme Geldenhuys via Lazarus" <

that the underlying GUI toolkit (Qt, GTK, fpGUI etc) implement the accessibility and will magically be available in your application, if accessibility is enabled in your desktop environment.

Not quite as the LCL still nerds to feed the necessary information to the widgetset's accessibility subsystem, especially with custom drawn controls. AFAIK there had been some work in the past to principally prepare the LCL for this...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171009/dc35792c/attachment.html>

I think there was some work before. (Afaik only carbon, Mac)

Look at TControl properties AccessibleRole, AccessibleValue, AccessibleDescription.
lcl\controls.pp line 1639

They refer to  TLazAccessibleObject (line 990)

Then in control.inc line 150   procedure
TLazAccessibleObject.SetAccessibleValue(const AValue: TCaption);
the widgetset is called
   WidgetsetClass :=
TWSLazAccessibleObjectClass(GetWSLazAccessibleObject());
   WidgetsetClass.SetAccessibleValue(Self, AValue);

TWSLazAccessibleObjectClass is at lcl\widgetset\wscontrols.pp line 80 TWSLazAccessibleObject is at line 71.

Search in files how it is sub-classed in carbon. Subclass it the same way in other widgetset.

If you want to subclass it in win32 go to
lcl\interfaces\win32\win32wsfactory.pas line 131
  function RegisterLazAccessibleObject: Boolean; alias : 'WSRegisterLazAccessibleObject';
see the commented code. only the gtk reference is a copy and paste. it needs to register the newly created class for win 32.

A few very short explanations:

Each widgetset (win, gtk, carbon, qt...) exports the methods for registration. the "alias" makes it visible to the linker. The LCL refers to those as external functions. So the LCL can be linked against each widgetset.

Also each widgetset inherits from the classes in the parent folder (generic classes).
e.g. TWSLazAccessibleObject in lcl\widgetset\wscontrols.pp line 71 and carbon inherits: TCarbonWSLazAccessibleObject = class(TWSLazAccessibleObject)  in lcl\interfaces\carbon\carbonwscontrols.pp

The generic classes are also compiled into the lcl. So the widgetset can provide the sub classes, and lcl knows how to call them.

You are quite wrong when you are talking about LCL. For example, even buttons are not accessible, on the IDE welcome page, screen reader reports only "button", instead of "StartIDE button", "Help button", etc. Yes, the button itself is native, but is broken. Another totally inaccessible component is, probably TTreeview. It is used in the options dialog where categories are displayed, in the package explorer etc. TCheckedListBox is yet another example. Code editor is totally inaccessible, etc, etc.
So again, you are wrong.

Dňa 8. 10. 2017 o 23:15 Graeme Geldenhuys via Lazarus napísal(a):

Thank you Sven for excellent answer. I already know about most of this stuff. You confirmed that my first small steps on this path were correct, and I didn't overlook anything. Thank again.

Dňa 9. 10. 2017 o 1:16 Sven Barth via Lazarus napísal(a):

Sorry I replied to wrong message. My thanks and my heart belongs just to you. :-)
Dňa 9. 10. 2017 o 4:43 Martin Frb via Lazarus napísal(a):

Thank for all replies, but my original question was overlooked. Can someone answer it?

Dňa 8. 10. 2017 o 22:09 Lubos Pintes via Lazarus napísal(a):

Lubos Pintes wrote

screen reader reports only "button", instead of "StartIDE button", "Help button", etc. Yes, the button itself is native, but is broken.

O wonder why that is so. The button really is a native button. Why does it not know its caption and name?

Juha

*I wonder ...

Lubos Pintes wrote

Also, how can I rebuilt the package when I modify/add some unit? Do I need to always rebuild the IDe, or there is a quicker way?

You can test with any small application. No need to build the whole IDE. The dependent LCL is compiled automatically when you compile your app. It goes fast enough.

Juha

I reported this problem years ago. If I remember properly, only TBitBtn has this behaviour.
Of course not all buttons in the IDE have empty names, but those on options dialog, or welcome page.
Dňa 9. 10. 2017 o 9:14 Juha Manninen via Lazarus napísal(a):

*I wonder ...

Lubos Pintes wrote

For example, even buttons are not accessible, on the IDE welcome page, screen reader reports only "button", instead of "StartIDE button", "Help button", etc. Yes, the button itself is native, but is broken.

It seems it is very LCL-widgetset dependent then. If using LCL-fpGUI widgetset, then accessibility works fine when using SAK (Speech Assistive Kit). Nothing special is required by LCL itself. At least that is how it worked last time I tested back in 2015.

Regards,
Graeme

And now I tested this and I am sure, only TBitBtn doesn't expose the name. And because TBitBtn is used mostly in the IDe, most buttons are not accessible.Dňa 9. 10. 2017 o 9:41 Lubos Pintes via Lazarus napísal(a):

Hello again,
I am hunting for hard-to-find bug and have no idea where it happens. Now I would like to ask about correct way of adding a new message into the Win32WidgetSet. Chances are that I am doing it incorrectly. I need to handle a WM_GETOBJECT message, and I did it as follows:

     WM_GETOBJECT: with WindowInfo^ do
       if(WinControl  nil) and(LParam = UiaRootObjectId) then begin
         Provider := TUIAControl(WinControl.GetAccessibleObject.Handle);
         Exit(UiaReturnRawElementProvider(Window, WParam, LParam,
Provider));
       end
       else Exit(CallDefaultWindowProc(Window, Msg, WParam, LParam));

I added this into TWindowProcHelper.DoWindowProc: LResult; Provider is the IRawElementProviderSimple interface and TUIAControl is a class implementing it based on information obtained from T(Win)Control.

I can confirm that Inspect can see the object(s). But one symptom I am receiving that a screen reader is unable to register that a form receives the focus. If I alt-tabbing, I hear "Project1", instead of "Form1". But when I place for example a button to the form, it is reported correctly. And when I place a TLabel on the form, I receive a bug I described in another thread.

So now I stopped here and am unable to continue. I added a trace information into every function I implemented to see what is happening, but I have no idea what is bad there...
Hope someone will be able to understand this. :)
Thanks!

Dňa 8. 10. 2017 o 22:09 Lubos Pintes via Lazarus napísal(a):

I am not 100% sure, but maybe this is because (afaik) there is a hidden form for the task button. This hidden form can be disabled somewhere, then the main form will be responsible for the task button.

Correct. Use Application.MainFormOnTaskbar := True to register the form
for the taskbar.

Ondrej

Hmm... But if I disable my UIA code then the form works as expected. Also If I place some standard control to a form like TButton. But I will try the MainFormInTaskbar property to see what happens. Dňa 26. 11. 2017 o 18:13 Ondrej Pokorny via Lazarus napísal(a):