AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Delphi DLL Form mit "TCustomForm.Active" gleich FALSE

DLL Form mit "TCustomForm.Active" gleich FALSE

Ein Thema von jarib · begonnen am 24. Jan 2017 · letzter Beitrag vom 27. Jan 2017
Antwort Antwort
jarib

Registriert seit: 23. Aug 2007
Ort: Neumünster
7 Beiträge
 
Delphi 10.1 Berlin Professional
 
#1

DLL Form mit "TCustomForm.Active" gleich FALSE

  Alt 24. Jan 2017, 10:11
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?
  Mit Zitat antworten Zitat
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Heilbronn
675 Beiträge
 
Delphi 10.4 Sydney
 
#2

AW: DLL Form mit "TCustomForm.Active" gleich FALSE

  Alt 24. Jan 2017, 18:02
Nutzt Du run time BPLs ?
  Mit Zitat antworten Zitat
jarib

Registriert seit: 23. Aug 2007
Ort: Neumünster
7 Beiträge
 
Delphi 10.1 Berlin Professional
 
#3

AW: DLL Form mit "TCustomForm.Active" gleich FALSE

  Alt 25. Jan 2017, 21:58
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.
  Mit Zitat antworten Zitat
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Heilbronn
675 Beiträge
 
Delphi 10.4 Sydney
 
#4

AW: DLL Form mit "TCustomForm.Active" gleich FALSE

  Alt 26. Jan 2017, 17:43
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
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.027 Beiträge
 
Delphi 12 Athens
 
#5

AW: DLL Form mit "TCustomForm.Active" gleich FALSE

  Alt 26. Jan 2017, 18:12
Nicht nur Variablen, sondern auch Typen.

TForm der EXE ist etwas ganz Anderes, wie TForm der DLLs.
Typprüfungen ala IS schlagen dann fehlt und auch beim Casten kann es schnell knallen, da der Compiler manchmal was wegoptimiert und schon stimmen Speicheroffsets nicht mehr.

Delphi-Quellcode:
// 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;
Wenn die EXE also auf B einer Form in der DLL zugreifen will, dann erwischt es das C.


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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu (26. Jan 2017 um 18:15 Uhr)
  Mit Zitat antworten Zitat
jarib

Registriert seit: 23. Aug 2007
Ort: Neumünster
7 Beiträge
 
Delphi 10.1 Berlin Professional
 
#6

AW: DLL Form mit "TCustomForm.Active" gleich FALSE

  Alt 27. Jan 2017, 17:01
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.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:12 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz