Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Fensterwechsel erkennen (https://www.delphipraxis.net/189443-fensterwechsel-erkennen.html)

norwegen60 13. Jun 2016 16:35

Fensterwechsel erkennen
 
Hallo zusammen,

ich habe eine Datenbankanwendung und möchte erkennen wenn in ein Fenster zurück gewechselt wird um ein Refresh der Anzeige auszuführen.

Das Fenster, in dem Sub-Daten bearbeitet werden können, ist in einer DLL. Damit werden die Ereignisse
Delphi-Quellcode:
Form.OnShow
Screen.OnActiveFormChange
nicht ausgelöst.

Das Ereignis
Delphi-Quellcode:
Form.OnPaint
wird nur ausgelöst, wenn das Hauptfenster komplette überdeckt wurde. Sobald ein kleines Eckchen sichtbar bleibt, wird OnPaint nicht ausgelöst.
Getestet mit Win7 Pro und Delphi XE10

Gibte es eine andere Möglichkeit, die Reaktivierung des Fensters sicher zu erkennen?

Vielen Dank für eure Hilfe
Gerd

milos 13. Jun 2016 16:49

AW: Fensterwechsel erkennen
 
Hi

Versteh ich das richtig das Delphi-Referenz durchsuchenTForm.OnActivate in einer DLL nicht ausgeführt wird?

Freundliche Grüsse

mm1256 13. Jun 2016 16:49

AW: Fensterwechsel erkennen
 
OnActivate schon probiert?

EDIT ooops Milos war schneller

himitsu 13. Jun 2016 17:15

AW: Fensterwechsel erkennen
 
OnShow = Visible=False zu Visible=True, bzw. beim Aufruf von Show oder ShowModal.

Einige Events gelten nur innerhalb der VCL und betreffen nur Wechsel zwischen "eigenen" VCL-Fenstern, aber keine Wechsel zu anderen Anwendungen.
Appliaction.OnActivate wäre zur Erkennung von Anwendungswechseln.

Form.OnActivate
Form.OnDeactivate
Screen.OnActiveFormChange
Application.OnActivate (Application oder besser TApplicationEvents)
Application.OnDeactivate

OnPaint: Seit Vista werden Zeichenfunktionen standardmäßig über den DesktopWindowsManager umgeleitet und dort gecached, drum haben da hängende Anwendungen immernoch ein "Bild", auch wenn deren Zeichenroutinen nicht mehr funktionieren.

norwegen60 14. Jun 2016 15:25

AW: Fensterwechsel erkennen
 
Hallo,

Zitat:

Zitat von milos (Beitrag 1340029)
Versteh ich das richtig das Delphi-Referenz durchsuchenTForm.OnActivate in einer DLL nicht ausgeführt wird?

OnActivate hatte ich getestet, aber vergessen aufzuführen. Es gilt dasselbe wie für OnShow, d.h. der Wechsel in die DLL (.B. FormDLL) und danach wieder zurück in die ursprüngliche FormOrg wird im Ereignis FormOrg.OnActivate nicht erkannt

Zitat:

Zitat von himitsu (Beitrag 1340033)
Einige Events gelten nur innerhalb der VCL und betreffen nur Wechsel zwischen "eigenen" VCL-Fenstern, aber keine Wechsel zu anderen Anwendungen.
Appliaction.OnActivate wäre zur Erkennung von Anwendungswechseln.

Ja, das hatte ich schon mitbekommen.
Delphi-Quellcode:
Appliaction.OnActivate
funktioniert, wenn ich z.B. von meinem Programm zum Explorer und wieder in mein Programm wechsle

Der Wechsel in eine eigene DLL wird aber weder von
Delphi-Quellcode:
Application.OnActivate
noch von
Delphi-Quellcode:
FormOrg.OnShow, FormOrg.OnActivate, Screen.OnActiveFormChange
erkannt.

Wenn jetzt also noch jemand ein xxx.OnActivate kennt dass den Wechsel zur/von DLL erkennt wäre super

Grüße
Gerd

himitsu 14. Jun 2016 16:28

AW: Fensterwechsel erkennen
 
Wie jetzt, ihr hab eine VCL in der EXE und eine VCL in einer DLL?
Dann sollte man sich nicht beschweren, wenn die beiden VCL-Instanzen untereinander sich nicht so richtig komunizieren/verbinden.

Sowas mach man nicht, denn die VCL ist nicht darauf ausgelegt, dass sie mehrmals in einem Programm existiert.
Hier ist alles doppelt, also die RTTI und globale Instanzen, wie z.B. Application.

Aber wenn doch, dann besser mit Packages arbeiten und EXE+DLL gegen die "selbe" VCL linken, also gegen die VCL-BPLs.

norwegen60 14. Jun 2016 21:12

AW: Fensterwechsel erkennen
 
Hallo,

jetzt bin ich nicht ganz sicher ob es ein Verständnis- oder Wissensproblem meinerseits gibt.

Ich habe mehrere unabhängige Anwendungen (.exe) für unterschiedliche Aufgaben. Die MsSQL-Datenbank ist aber für alle Anwendungen dieselbe.
Manche Grunddaten, z.B. eine User-Verwaltung, werden von allen Anwendungen gleich benötigt, und so ist z.B. die Userverwaltung in eine DLL ausgelagert. Hier der Aufbau der DLL
Delphi-Quellcode:
library User;

uses
  SysUtils,
  Dialogs,
  Classes,
  ComCtrls,
  Forms,
  Ed_user in 'Ed_user.pas' {foedUser},
  Di_uslog in 'Di_uslog.pas' {fodiUserLogin},
  int_User in 'int_User.pas';
  dm_ConDoQMa in '..\All_Form\dm_ConDoQMa.pas',
  dm_User in 'dm_User.pas' {dmUser: TDataModule};

{$R *.RES}

exports
  edUser,
  GetUser,
  InitUser0,
  SetUser;

end.
und so der Aufruf von GetUser
Delphi-Quellcode:
procedure TintUser.GetUser;
const sBef = 'GetUser';
var
  fDLL : function:TUser;
  fIni: TIniFile;
begin
  SetDLL;

  if haDLL <> 0 then
  begin
    @fDLL := GetProcAddress(haDLL, sBef);
    if uHilfs1.CheckDll(@fDLL, sBef, sDll, sUnit, sFehler) then
      User:=fDLL;           { GetUser aufrufen }
  end;

  try
    { Aktuelle Benutzer unter PC-Kennung eintragen  }
    if intUser.sIni<>'' then
    begin
      fIni := TIniFile.Create(intUser.sIni);
      fIni.WriteString(intUser.sPC, 'LastUser', intUser.User.Name);
      fIni.Free;
    end;
  except
  end;
end;
Das Formular zum Login oder zum Ändern von Userdaten ist also in der User.dll, Die Daten-Connection wird über das für alle DLL und EXE gleiche dm_ConDoQMa bereitgestellt.

Dieser Aufbau funktioniert seit Delphi 3 ohne Probleme.
Was ist aus deiner Sicht daran nicht korrekt?
Ich habe mich mit dem Thema VCL bis jetzt nie wirklich beschäftigt. Hatte ja auch nie ein Problem.
Bis eben jetzt, wo ich erkennen wollte, dass Anwendung1.exe ein Formulat in User.dll aufruft und ich dann mitbekommen will, wenn Anwendung1.exe wieder den Focus bekommt. Beim User.dll ist das kein Problem, da ich mir auch die Daten aus der DLL hole und damit die Daten nur innerhalb der DLL aktualisieren muss.
Bei anderen Stammdaten werden die Daten aber nur in der DLL verwaltet (angelegt oder geändert), aber in Anwendung1.exe in einer Liste angezeigt, d.h. die Anwendung hat eine eigen Verbindung zu der Tabelle. Und die sollte halt auch aktualisiert werden, wenn ich aus XX.dll zurück komme.

Für Aufklärung wäre ich sehr dankbar.

Grüße
Gerd

Fritzew 14. Jun 2016 21:47

AW: Fensterwechsel erkennen
 
Hallo,

Die Dialoge in der Dll werden aber modal aufgerufen oder?

Wir benutzen für sowas immer ein System das die Dll speziell initialisiert

und zwar über eine DllInit und Dllfree function.

In der dll also:

Delphi-Quellcode:
function InitDll(aHandle : Thandle) : Boolean;
und

Delphi-Quellcode:
FreeDll(aHandle : Thandle) : Boolean;
in der InitDll wird dem Application Object der Dll das Handle zugewiesen
also
Application.Handle := aHandle;

und in der FreeDll wieder zurückgesetzt.

mm1256 14. Jun 2016 21:59

AW: Fensterwechsel erkennen
 
Zitat:

Zitat von norwegen60 (Beitrag 1340193)
Hallo,

jetzt bin ich nicht ganz sicher ob es ein Verständnis- oder Wissensproblem meinerseits gibt.

Ich habe mehrere unabhängige Anwendungen (.exe) für unterschiedliche Aufgaben. Die MsSQL-Datenbank ist aber für alle Anwendungen dieselbe....

Dann würde ich die DB-Connection (Datenmodul/e) und die dazugehörigen gemeinsam verwendeten Formulare in eine einzige BPL packen :thumb:

norwegen60 15. Jun 2016 16:52

AW: Fensterwechsel erkennen
 
Hallo zusammen,

sehe ich es falsch und die Vorschläge sind Optimierungen oder sollte durch einen der Vorschläge eines der Activate- oder Show-Ereignisse aufgerufen werden?

Grüße
Gerd


Alle Zeitangaben in WEZ +1. Es ist jetzt 09:28 Uhr.

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