Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   RegisterClassAlias nur anders? (https://www.delphipraxis.net/215805-registerclassalias-nur-anders.html)

himitsu 10. Sep 2024 11:32

RegisterClassAlias nur anders?
 
Tachchen,

mit Delphi-Referenz durchsuchenRegisterClassAlias kann ich eine Komponente unter anderem Namen registrieren (z.B. kurz vor dem Laden der DFM)
Ich dachte erst, dass damit ein alter (gepeicherter) Name mit der neuen Klasse geladen würde,
aber leider sieht es nicht danach aus. Es bleibt die alte Klasse.

In den aktuellen Fällen passt es so, da man den Namen als String angibt, hätte ich gedacht, es wird dennoch die angegebene Klasse genommen, wenn etwas so heißt.


Ich kann aber noch nicht ausschließen, dass garnicht mein Alias genimmen wird, sondern noch irgendwo anders die alte Klasse registriert wurde. (hab aber bis jetzt nichts gefunden)
Doch, kann ich ausschließen. direkt vor meinen RegisterClass(es) und RegisterClassAlias meint Delphi-Referenz durchsuchenFindClass, dass es das noch nicht gibt.
PS: RegisterClass ist echt ein blöder Name, denn das gibt es auch in der Windows.pas :wall: (hatte von RegisterClasses auf RegisterClass umgestellt, da nun im Array einige NIL drin sind und es damit knallt)

Ach ja, Laden der DFM zur Laufzeit, nach dem Create der Form.
Greatis FormDesigner




Ach ja, wird das Alias zuammen mit dem UnRegisterClass weggeworfen?
Es gibt ja kein UnRegisterClassAlias, oder Dergleichen.

Und das mit den Alias darf beim späteren "normalen" Laden einer Form nicht treffen.

himitsu 10. Sep 2024 14:06

AW: RegisterClassAlias nur anders?
 
Boar, das ist schon pervers unerwartet.

Delphi-Referenz durchsuchenRegisterClass registriert nicht nur den angegebenen Typen, sondern auch dessen Vorfahren.
Es hatte nichts mit Delphi-Referenz durchsuchenRegisterClassAlias zu tun. :wall:

Vor/zwischen/nach dem RegisterClass und RegisterClassAlias geprüft,
wird jene Klasse (quasi TEdit vom TMyEdit) nach dem RegisterClass mit Delphi-Referenz durchsuchenFindClass/GetClass gefunden, obwohl der Vorfahr eigentlich garnicht registriert wurde.

Damit kann der DFM-Loader diese Klasse dann auch finden und laden. :freak:



Ich hätte es aber gern, dass stattdessen über den Alias der neue Typ geladen würde.
Mal sehn ob ich es wenigstens im FormDesigner hinbekomme, dass mindestens beim Bearbeiten die Klassen wie gewünscht getauscht/upgegraded werden.

Uwe Raabe 10. Sep 2024 14:45

AW: RegisterClassAlias nur anders?
 
Ich kann dein Problem aktuell noch nicht ganz verstehen. Kannst du mal ein Beispiel zeigen, wo man sieht was du machst, was du erwartest und was passiert?

Mit dem RegisterClassAlias wird eigentlich schon die dort übergebene Klasse erzeugt wenn der Alias-Name eingelesen wird. Allerdings nur, wenn eine Klasse mit diesem Alias-Namen nicht eh schon registriert ist.

Es gibt allerdings auch andere Wege, auf die Klassen Einfluss zu nehmen, die beim Einlesen tatsächlich erzeugt werden. Deswegen wäre ein konkretes Beispiel hilfreich, um zu entscheiden welcher Ansatz geeignet ist.

himitsu 10. Sep 2024 14:55

AW: RegisterClassAlias nur anders?
 
Wir haben in der DB mehrere DFMs,
dort sind teilweise noch ein paar "normale" Komponenten drauf (z.B. TCimEdit ... ein TdxEdit-Nachfahre),
welche jetzt ebenfalls endlich erweitert werden sollen, speziell für diese dynamischen Forms (ein neuer Nachfahre unseres TCimEdit, mit neuen Property, welche z.B. via SQL-Script selbsständig Daten laden sollen)

Komponenten also abgeleitet (erstmal nur abgeleitet und noch nichts geändert)
und nur hab ich bei der Registrierung, vor/um das DFM-Laden die neuen Komponenten drin,
dabei die Alten dort entfernt (aus der Registrierung) und als Alias registriert.

Ideal wäre es jetzt, wenn beim Laden die neuen Typen genutzt werden.
Aber es wäre schon OK wenn auch die alten Typen noch geladen würden ... was jetzt schon funktioniert, aber ich mich anfangs gewundert hatte, warum es funktioniert, da erwartet war, dass der DFM-Loader die "alten" Typen nicht kennt, weil "ich" sie eben nicht registriere, bzw. nicht mehr.

Uwe Raabe 10. Sep 2024 15:09

AW: RegisterClassAlias nur anders?
 
Du kannst in einem Form die Methode ReadState überschreiben und beim Reader den OnFindComponentClass-Event temporär auf eine eigene Methode umleiten, die für den ClassName die gewünschte ComponentClass zurückgibt. Wenn du einen gemeinsamen Vorfahren für alle Forms hast, dann lässt sich das dort elegant für die gesamte Anwendung implementieren.

Das gilt erstmal für reguläre DFMs, bei denen die Form-Klasse ja mit compiliert wird. Für das Laden aus der DB muss aber ja auch eine spezielle Form-Klasse verwendet werden. Das müsste dann eben dort eingebaut werden.

himitsu 10. Sep 2024 15:30

AW: RegisterClassAlias nur anders?
 
Bei unseren neuen Dashboards machen wir das Speichern selbst (TReader/TWriter, bzw. TComponent.ReadComponents usw.)
und auch die Verwaltung/Erstellung der Forms. (Kontextmenüs im Edit-Mode)

Hier fäuft es aber über den Greatis FormDesigner.
Der bekommt die DFM als String in ein FormData-Property reingeschoben und ausgelesen
und er macht alles intern. Hab da noch keine Events oder Übersetzungslisten entdeckt, um es ändern zu können.
(muß aber nochmal suchen, da wir eigentlich das Exception-Handling des TReader erweitert haben ... wie im FormDesigner von Delphi werden fehlerhafte Property/Komponenten ignoriert, anstatt einer Exception)

Aber wie gesagt, eigentlich hatte ich gedacht es über RegisterClassAlias zu lösen.
Hab aber leider grade (noch) keinen Test-Fall, wo die alte Klasse nicht mehr existiert, bzw. kein Vorfahre eines neuen Typen ist, also nicht durch RegisterClass läuft, und es dann nur noch durch RegisterClassAlias behandelt werden könnte.


Alle Zeitangaben in WEZ +1. Es ist jetzt 20:53 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz