Klassennamen ändern

[Marco Steinebach]

Hallo zusammen,
Ich habe eine von TRichEdit abgeleitete Klasse, TMyRichEdit.
Kann ich den Klassennamen irgendwie ändern?
Folgender Hintergrund:
Ich verwende, weil ich blind bin, einen Screenreader zum Auslesen des Bildschirms.
Nutze ich ein Delphi-Prog mit einem TRichEdit funktioniert der Screenreader wunderbar, liest alles vor, markiert Text richtig, etc.
Mache ich das selbe mit meiner abgeleiteten Klasse TMyRichEdit, funktioniert entweder nix, oder zumindest nicht richtig.
Dem Screenreader kann ich zwar beibringen, das Elemente des Typs TMyRichEdit ein Edit sind, hilft aber nix.
Ich weiß leider nicht, woher der Screenreader den Namen bezieht, aber lese ich den Namen aus, wenn ich auf dem Feld stehe, erhalte ich TMyRichEdit, was ja richtig ist.
Kann ich in Delphi irgendwo sagen:
Du, falls dich jemand fragt, von welcher Klasse du bist, sag ihm, du seist ein TRichEdit.

Das würde mir echt doll helfen, wenn jemand eine Antwort, oder zumindest eine Idee hätte.
Ach so: falls man da mit Inline ran muss, kann mir das bitte gleich jemand machen ich hab nämlich sowas von keine Ahnung von inline...

Herzlich grüßt
Wandogau

[sh17]

Du könntest eine weitere DummiUnit einführen, die nur

Code:

uses
  MyRichEditUnit;

type
  TRichEdit = class(TMyRichEdit)

  end;

enthält.

Im Form änderst du die Deklaration dann so ab bzw bindest nur die MyRichEditUnitDummi Unit in den Uses ein

Code:

  TForm1 = class(TForm)
    re: MyRichEditUnitDummi.TRichEdit;
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

sollte eigentlich klappen

[Kas Ob.]

Hi,

Zitat:

Zitat von sh17 (Beitrag 1539982)

sollte eigentlich klappen

Most likely hill not help with that screen reader, the reason is :

The trick with the interposer will work internally on Delphi compiler and generated code locally, yet the class name is still TMyRichEdit, and when i say class name, i mean the created Windows class using the OS APIs.
Screen Reader can't enumerate or access an application internal naming, but will access the created windows classes and declared externally, and will only see TMyRichEdit.

I might be wrong though, in all cases, please test what Sven suggested, and in case didn't help, i am offering what is needed to find a solution, though the easiest and best solution is configuring the Screen Reader to handle TMyRichEdit as TRichEdit, yet there are few things i can think of, but does need little more.. lets say an unorthodox approaches, like memory patching and hooking and doing nasty stuff, yet again i volunteering to do it for you whatever it takes.

I hope your screen reader have better language than me :oops:

[himitsu]

Ein "ordentlicher" Screenreader sollte doch aber eigentlich auf die "innere" Fensterklasse / den Real-ClassName achten, bzw. eigentlich besser auf auf Funktionen, also ob eine API zum Auslesen des Textes vorhanden ist.

Wenn der wirklich auf den "aktuellen" Klassenname achtet, müsste er ja "Delphi" kennen und sonst auch jedes GUI-Framework, welches das RichEdit jeweils in einer eigenen Klasse kapselt.


Ich weiß leider nicht, wie es bezüglich VCL aussieht.
Insgesamt hab ich da eigentlich keine Ahnung, was dieses "Accessibility"-Thema für Blinde und Schlechtsehende betrifft.

OK, einmal kann man bei FMX angeben, dass es echte Windowskomponenten nutzt, anstatt selbst zu malen,
für einige wenige Komponenten, wie Edits und Buttons ... k.A. ob auch RichEdit.
Wo also unter Windows quasi die VCL-Komponente im FMX verwendet wird, welche wiederum Windows und somit auch ScreenReader finden können.
[edit] OH, FMX kennt kein RichEdit, aber erstmal egal [/edit]
ControlType = Platform
https://docwiki.embarcadero.com/Libr...on.ControlType

Für FMX/FireMonkey gibt es aber ein Addon, um die "selbstgemalte" GUI, ala JAVA, für ScreenReader zugänglich zu machen.
Es gibt im Windows eine API dafür, um dem Reader explizit "selbst" den Inhalt der Form zu sagen, anstatt er die Form abscannt.
https://docwiki.embarcadero.com/RADS...bility_Package

Prinzipiell gibt es dieselbe API auch für die VCL,
denn z.B. TLabel und Grids malen sich auch selbst, wo der ScreenReader nur die Pixel/Canvas via OCR analysieren müsste,
oder das Programm sagt ihm via API, was dort wo drin steht.

Es gibt auch einige andere proprietäre Schnittstellen, für spezielle ScreenReader.


PS: statt TLabel, was in Delphi kein WinControl ist, sondern sich selbst auf den Canvas seines Patents malt,
kann man hier auch TStaticText verwenden, welches das "echte" Windows-TextanzeigeControl "STATIC" ist.

[Marco Steinebach]

Hello,
@Sven:
Super-Idee, scheitert bei mir leider daran, das mein gutes altes D5 noch keine Referenzierung unit.Typ kann. Ja, ja, dann nimm D11.3, würde ich ja, wenn es auch nur halb so gut mit einem Screenreader zu bedienen wäre.

@Kas:
I think you're right. I tried to tell my screenreader (JAWS) to treat TMyEdit as an edit or multiLineEdit, but it makes no difference. So we have to find a way while creating the corresponding elements to change the class name.

@Himitsu:
Ich geb dir recht, ein Screenreader sollte, tut er in vielen Fällen auch, aber beim RichEdit spinnt er komplett.

Herzlich grüßt (with best regards)
Wandogau

[Mavarik]

Ich denke es heißt Superimposing oder so...

Ich mach das z.B. für TForm.

Deine Unit die TRichEdit Implementiert muss "nur" in der Uses hinter der original Unit stehen und schon wird Deine Implementation verwenden.

Mavarik

[Kas Ob.]

OK, then hooking it is.

I have few errands to attend now with few phone calls, in other words will be busy for few hours, but the solution is very easy as i think a simple hook for RegisterClassW/RegisterClassExW/RegisterClassA/RegisterClassExA and changing the ClassName will do the trick with the screen reader.

One thing though, i might didn't understand it right, you need the fix for Delphi 5 application?

If yes then the approach will still doable but will need some cut corners, i would go with using the great DDetours library from https://github.com/MahdiSafsafi/DDetours , alas it doesn't support Delphi 5, so either the hooking will be less general or a DLL can solve this easily.

Do you have problem in adding a small DLL to benefit form the wide range compatibility in hooking ? (in case Delphi 5 is the one needed)

By adding, i mean this DLL could copied to the system directory and for any or all of your application, all what you need is add one unit to uses without adding any code, also this DLL could be tweakable without rebuilding, like using one line in your application to change any ClassName, not just TMyRichEdit.

[Kas Ob.]

Zitat:

Zitat von Mavarik (Beitrag 1539994)

Ich denke es heißt Superimposing oder so...

Ich mach das z.B. für TForm.

Deine Unit die TRichEdit Implementiert muss "nur" in der Uses hinter der original Unit stehen und schon wird Deine Implementation verwenden.

Mavarik

No sure i do understand this,
Do you mean introducing the interposer for TMyRichEdit itself ?
, one level before, like,

Code:

uses
  MyRichEditUnit;

type
  TRichEdit = class(Vcl.ComCtrls.TRichEdit)  // TRichEdit on the left side is TMyRichEdit but renamed, and MyRichEditUnit must be in uses clauses before Vcl.ComCtrls in the form that uses it
....

This might work !

[sh17]

Zitat:

Zitat von Mavarik (Beitrag 1539994)

Ich denke es heißt Superimposing oder so...
Ich mach das z.B. für TForm.
Deine Unit die TRichEdit Implementiert muss "nur" in der Uses hinter der original Unit stehen und schon wird Deine Implementation verwenden.

genau, dann so

Code:

uses
  ..,MyRichEditUnitDummi;

  TForm1 = class(TForm)
    re: TRichEdit;
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

[Marco Steinebach]

Hi Mavarik,
Jep! So funktioniert es, auch wenn man dann darauf verzichten muß, das TMyRichEdit im Formulardesigner bearbeiten zu können, aber jetzt glaubt der Screenreader es sei ein TRichEdit und alles ist schön!
Ganz herzlichen Dank an alle für die rasche Hilfe!!!

Es grüßt
Wandogau