![]() |
Eigene Komponente -> Handle vom Aufruf-Fenster bekommen?
Guten Morgen, wiedermal "Eigene Komponente"-Thema :-)
Wie gelangt ihr in Euren Komponenten (falls erforderlich) an das Handle vom Aufrufer-Fenster? Ich mache es zur Zeit so:
Delphi-Quellcode:
Ich möchte aber von Vcl.Forms wegkommen. Hat jemand eine Idee wie ich an das gleiche Resultat für FParentWnd komme wie oben gezeigt?
uses Vcl.Forms;
constructor TKomponente.Create(AOwner: TComponent); begin FParentWnd := (AOwner as TForm).Handle; end; |
AW: Eigene Komponente -> Handle vom Aufruf-Fenster bekommen?
Kathinka sagt:
Eigentlich sollte eine Komponente das Parent gar nicht kennen müssen und erst recht nicht dessen Handle. So wie Du es machst erzwingst Du nun auch dass ein Handle erzeugt wird. Ich selber mache auch keine Komponenten mehr seit es die TFrames gibts. Die finde ich im Handling viel einfacher. |
AW: Eigene Komponente -> Handle vom Aufruf-Fenster bekommen?
Zitat:
Delphi-Quellcode:
bal := TKomponente.Create(ed_blub);
Theoretisch geht auch NIL, also solltest Du auch das prüfen. Sinnvoller wäre aber vermutlich sowieso Parent statt Owner, denn Owner kann ein beliebiges TComponent sein, welches evtl. gar kein Window-Handle hat. Parent ist immer ein TWinControl, hat also ein Window-Handle. Wenn ich mich recht erinnere, gibt es eine GetOwnerForm-Methode (oder war's GetParentForm?) in TComponent. |
AW: Eigene Komponente -> Handle vom Aufruf-Fenster bekommen?
Zitat:
|
AW: Eigene Komponente -> Handle vom Aufruf-Fenster bekommen?
Ein HWND ist nicht unveränderlich, denn es kann unter Umständen entladen und neu erstellt werden.
Auch muß es beim Erstellen/Laden der Form noch nichtmal existieren. Besser das Handle immer bei Benutzung (maximal zu Beginn jeder Methode) frisch besorgen. Wenn man das Handle "aktuell" nicht unbeding "sofort" benötigt, dann kann man auch HandleAllocated prüfen, bevor man auf Handle zugreift. Zitat:
Bzw. was meinst du mit "wegkommen"? Zitat:
Außer man definiert fpr seine Klasse, dass der Owner unbedingt eine Form sein muß, was hier implizit gemacht wird, denn AS lässt ausschließlich TForms oder NIL zu. Aber wie immer in der Verärbung sollte man besser TCustomForm für den Cast verwenden, anstatt TForm. (Beispiel: siehe Result von GetParentForm) ![]() ![]() ![]() ![]() |
AW: Eigene Komponente -> Handle vom Aufruf-Fenster bekommen?
Hi,
das obige dient zur demonstration was ich erreichen will. Ja checking muss noch rein. Ich wollte ja von Vcl.Forms weg und nicht noch tiefer darin versumpfen. Das ![]() Danke schonmal für's Lesen. Sinn und Zweck soll sein: Später generiere ich dynamisch Fenster die von der Parent-Position abhängig sind, also ohne ein Fenster-Handle klappt dies nicht. Dann generier ich noch etwas, was einen direkten Bezug zum Parent bekommt (per CreateWindowEx mit FParentWnd als hWndParent parameter). Zitat:
Aufrufer-Fenster: Das Fenster wo meine Komponente raufgezogen wurde. |
AW: Eigene Komponente -> Handle vom Aufruf-Fenster bekommen?
Zitat:
Oder soll es immer das TForm sein? (wobei auch ein TForm in ein anderes TWinControl eingebettet sein kann - z.B. im IDE Embedded Designer) |
AW: Eigene Komponente -> Handle vom Aufruf-Fenster bekommen?
Das werde ich heute Abend mal durchtesten,
![]() Vielen Dank für Input! IdR. kann meine Komponente nur auf Hauptfenster gezogen werden und nicht eingebettet werden da es eine nicht-visuelle Komponente ist. (man sieht im Designer nur das kleine Rechteck auf dem Formular.) Per code wiederum ist, wie dummzeuch richtig schreibt, alles möglich. |
AW: Eigene Komponente -> Handle vom Aufruf-Fenster bekommen?
Unabhängig von GetParentHandle und Co.
Wenn du eine VCL-Komponente baust, dann ist die VCL so oder so im Programm, womit es keinen Grund gibt, warum diese Unit auch in deinem USES nicht drin sein sollte. (es macht einfach keinen Unterschied) Fazit: Falls man Funktionen/Typen davon braucht, dann nehme man sie, mache sich das Leben leicherter und erspare sich sonstwelche komischen Hacks. Ist auch viel unanfälliger für Fehler. Was leider nicht wirklich machbar ist, auch wenn es theoretisch ginge. Eine Nichtvisuelle-Komponente für FMX und VCL, die aber auf andere visuelle Komponenten Zugriff haben soll. Denn sowas wie {$IFDEF FMX} gibt es nicht, womit man zwar Code schreiben könnte, der mit VCL und FMX kann, aber dann nur mit kranken Hacks oder indem man alle Units von VCL und FMX einbinden müsste, was im Windows ginge (auch wenn es nicht schön wäre), aber ansonsten wunderschön abraucht. |
AW: Eigene Komponente -> Handle vom Aufruf-Fenster bekommen?
An himitsu,
wie immer überrascht mich Dein umfangreiches Wissen und vor allem auch die vielen definitionen/methoden die Du so aus dem Ärmel schüttelst! Aber nein, ich habe keine Vcl erstellt, Vcl ist bei mir auch nur mit "Vcl.Forms" eingebunden weil ich halt das Handle bzw "TForm" brauchte um da ran zu kommen, mehr nicht. Zu keinem anderen Zeitpunkt in meinem Komponenten-Project benötige ich das außer da oben. Ich greife auch auf nichts vom Caller zu, abgesehn einer Positions- und Dimensionsabfrage interessiert mich der Caller nicht. Alles was bei mir zZ. passiert ist WinApi (ich trauer immer noch wegen M.Puff). Entwickelt für Windows samt Abfragen die das auch sicherstellen bevor der Pc sich in einen Zombie verwandelt. Wo ich ins stottern gekommen bin war die stelle "vor" und "nach" dem einbinden dieser Unit. Die hat meine bpl Dateigröße grob verfünzigfacht, aus 35kb wurde ein megabyte. Nicht das mich das stört, aber irgendwie doch :P Da ich generell neugierig bin wollte ich weitere Anlaufpunkte finden, drei habe ich ja nun Dank Dir. Danke nochmal! |
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:02 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 by Thomas Breitkreuz