![]() |
RegisterClassAlias nur anders?
Tachchen,
mit ![]() 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 ![]() 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. |
AW: RegisterClassAlias nur anders?
Boar, das ist schon pervers unerwartet.
![]() Es hatte nichts mit ![]() Vor/zwischen/nach dem RegisterClass und RegisterClassAlias geprüft, wird jene Klasse (quasi TEdit vom TMyEdit) nach dem RegisterClass mit ![]() 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. |
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. |
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. |
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. |
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