![]() |
DLL Form mit "TCustomForm.Active" gleich FALSE
Hallo zusammen,
das folgende Problem macht mir zur Zeit etwas Kopfschmerzen, aber bevor ich zu meinem Problem komme, vorab eine kurze Einführung in mein Projekt. Ich arbeite aktuell an einer Anwendung die aus einem Host (EXE) und einer beliebigen Anzahl (je nach Bedarf) an Plug-In Dateien (DLLs) besteht. Die Kommunikation zwischen der Host Anwendung und den Plug-In Dateien realisiere ich zu 100 % über Interfaces. Die Host Anwendung hat eigentlich keine "Intelligenz". Die Host Anwendung beinhaltet in der Oberfläche (einfach gesagt) nur ein Ribbon, Tabset und eine Scrollbox. Das Ribbon wird durch die Plug-In Dateien mit Steuerelementen (Buttons oder Comboboxen) "gefüllt". D.h. die Plug-In Dateien platzieren in dem Ribbon z.B. Buttons die ein Aufruf der Formulare aus den Plug-In Dateien ermöglichen. Die Formulare der Plug-In Dateien werden nicht direkt in der Scrollbox der Host Anwendung dargestellt. Zum besseren Handling der Formulare aus den Plug-In Dateien werden diese in einer "Container" Form des Hosts dargestellt. Der Host sowie alle Plug-In Dateien verwenden die Unit System.SimpleShareMem. In der Host Anwendung habe ich zusätzlich noch System.Controls.IsVCLControlHook gesetzt. Die Basis-Klasse aller Plug-In Dateien setzt unter anderem noch Application.Handle auf den Wert der Host Anwendung. Alle Formulare aus den Plug-In Dateien verwenden ein (Plug-In) Formular vorfahren was die Kommunikation mit der Container Form und der Host Anwendung ermöglicht. Das Formular der Plug-In Datei wird wie folgt Eingerichtet. Self.Align := alNone; Self.BorderIcons := []; Self.BorderStyle := bsNone; Self.ParentWindow := AHandle; // Handle der Container Form Die Breite und Höhe des Plug-In Formulars wird über die Container Form geregelt. Die Container Form regelt auch bei Bedarf ein neues Zuweisen des Handles für Self.ParentWindow. Alle VCL Inhalte der Plug-In Formulare haben wunderbar funktioniert bis auf eine Ausnahme die ich vor kurzem festgestellt haben. Ich verwende (fast) ausschließlich die visuellen Komponenten von TMSSoftware. Daher habe ich in einem Plug-In Formular ein TAdvStringGrid verwendet um dem Benutzer eingaben zu ermöglichen. Wenn die Zelle als Eingabefeld vorgesehen ist, dann kann ich zwar eine Eingabe tätigen, aber es ist mir nicht möglich die Eingabe mit ENTER abzuschließen. Die Zelle verlässt einfach nicht den Eingabemodus. Nachdem ich mich gezwungener Maßen mit den Internas des TAdvStringGrid und der VCL auseinandersetzen musste, habe ich das Problem gefunden. Beim "KeyPress" Ereignis durch RETURN erfolgt ein Abfrage ob das Steuerelement (das TAdvStringGrid) den Focus hat, bei dieser Abfrage werden verschiedene Methoden der Klasse der Units Vcl.Controls und Vcl.Forms aufgerufen. Unter anderem Vcl.Controls.SetFocus(), Vcl.Forms.TCustomForm.FocusControl() und Vcl.Forms.TCustomForm.SetWindowsFocus(). In der Methode Vcl.Forms.TCustomForm.FocusControl() erfolgt die Abfrage auf die interen Feldvariable "FActive". Und diese ist leider aus mir unbekannten Gründen in meiner Plug-In Form immer FALSE. Weil "FActive" = FALSE ist, erfolgt über Vcl.Controls.SetFocus() und Vcl.Forms.TCustomForm.SetWindowsFocus() der Aufruf von Winapi.Windows.SetFocus(FocusControl.Handle) und das wiederum löst in der Unit AdvGrid (Unit des TAdvStringGrid) WMKillFocus und WMSetFocus aus. Und das WMSetFocus ist wahrscheinlich das problem warum die Zelle nach RETURN den Eingabemodus nicht verlässt. Da die Klasse Vcl.Forms.TCustomForm keinen Zugriff von außen auf die Feldvariable "FActive" zulässt, habe ich zu testzwecken über einen etwas schmutzigen Hack die Feldvariable "FActive" manuell gesetzt. Und siehe da es funktioniert. Allerdings ist das keine Lösung die ich dauerhaft einsetzen würde. Daher meine Frage. WARUM wird bei einem Plug-In Form die mit Self.ParentWindow einer EXE Anwendung hinzugefügt wird, Vcl.Forms.TCustomForm.Active nicht auf TRUE gesetzt? |
AW: DLL Form mit "TCustomForm.Active" gleich FALSE
Nutzt Du run time BPLs ?
|
AW: DLL Form mit "TCustomForm.Active" gleich FALSE
Nein das mache ich nicht.
Ich habe mich bewusst gegen Runtime Packes entschieden um die zusätzlichen Dateien (Packages) zu vermeiden dann im BIN Verzeichnis rumfliegen würden. Ich glaube wenn ich Runtime Packes nutzen würde, hätte ich wahrscheinlich nicht das Problem. |
AW: DLL Form mit "TCustomForm.Active" gleich FALSE
Du kannst nicht mit Forms in DLLs arbeiten ohne runtime packages, weil sonst jede DLL und die exe ihre eigene instanz der VCL und RTL haben, mit globalen variables etc. Das heisst auch Application.MainForm ist in der DLL ein anderer Speicherblock als in deiner Exe.
Auch deine Registrierung der Klassen wie TFont sind anders und dir wird dann oft der Fehler "TFont kann nicht TFont zugewiesen werden" auftreten. Das ist also keine Frage der Entscheidung von Deiner Seite, Delphi geht einfach so nicht :) Helge |
AW: DLL Form mit "TCustomForm.Active" gleich FALSE
Nicht nur Variablen, sondern auch Typen.
TForm der EXE ist etwas ganz Anderes, wie TForm der DLLs. Typprüfungen ala
Delphi-Quellcode:
schlagen dann fehlt und auch beim Casten kann es schnell knallen, da der Compiler manchmal was wegoptimiert und schon stimmen Speicheroffsets nicht mehr.
IS
Delphi-Quellcode:
Wenn die EXE also auf B einer Form in der DLL zugreifen will, dann erwischt es das C.
// in EXE
TForm = class A: Integer; B: Integer; C: Integer; end; // in DLL TForm = class A: Integer; //B: Integer; das hat der Compiler wegoptimiert, weil es in der DLL nicht verwendet wurde C: Integer; end; Wobei es schon problematisch genug ist, dass EXE und DLL eigene Variablen haben. Da gibt es die globale Instanz von Application, wo EXE und DLL Eigene haben, dann die globalen Fonts, Brushs und vorallem Listen für "vorhandene" Fenster und active Forms/Controls in Application und Screens usw. |
AW: DLL Form mit "TCustomForm.Active" gleich FALSE
Wie bereits geschrieben hat es bis jetzt wunderbar funktioniert.
Weitere Tests mit einem Standard TStringGrid haben gezeigt das das Editieren ohne Probleme funktioniert. Ich danke euch aber für die Antworten denn die haben mich dazu bewogen meinen Ansatz nochmal zu überdenken. Ich bin zwar noch absoluter Anfänger in dem Thema Runtime Packages aber da muss ich jetzt wohl durch. Damit ist das Thema für mich abgeschlossen. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:08 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