Fensterwechsel erkennen

[norwegen60]

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]

Hi

Versteh ich das richtig das TForm.OnActivate in einer DLL nicht ausgeführt wird?

Freundliche Grüsse

[mm1256]

OnActivate schon probiert?

EDIT ooops Milos war schneller

[himitsu]

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]

Hallo,

Zitat:

Zitat von milos (Beitrag 1340029)

Versteh ich das richtig das TForm.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]

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]

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]

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]

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]

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