Nach Explorer absturz

[venice2]

Wie kann ich am besten prüfen ob der Explorer abgestürzt ist ohne Timer?
Unter Win10 stürzt dieser leider immer öfter ab danach funktioniert mein Programm nicht mehr. (bsp. Wegen NVIDIA Control Panel)

[Bernhard Geyer]

Zitat:

Wie kann ich am besten prüfen ob der Explorer abgestürzt ist ohne Timer?

Evtl. ist das ein Ansatz
https://devblogs.microsoft.com/oldne...026-00/?p=9263

Zitat:

Unter Win10 stürzt dieser leider immer öfter ab danach funktioniert mein Programm nicht mehr. (bsp. Wegen NVIDIA Control Panel)

Am besten das Grundlegende Problem lösen.
Abstürze des Windows Explorer sind sehr häufig durch schlecht Programmierte Shell Extensions verursacht.
Diese zu identifizieren und zu löschen löst das Problem.
Evtl. findet sich ja in der Windows Ereignisanzeige zu dem Absturz ein Hinweis

[venice2]

Zitat:

Am besten das Grundlegende Problem lösen.

Ich soll das Problem beheben das von NVIDIA Control Panel verursacht wird?
Ist das nicht eine Sache die NVIDIA beheben sollte?

Mit den HOOK werde ich mir mal anschauen. Danke!

[Bernhard Geyer]

Zitat:

Zitat von venice2 (Beitrag 1473494)

Ich soll das Problem beheben das von NVIDIA Control Panel verursacht wird?
Ist das nicht eine Sache die NVIDIA beheben sollte?

Die Frage ist ob es wirklich ein Fehler in der SW ist (steht das wohl im Windows-Log)?
Falls der Rechner älter ist, dann hilft ab und zu ältere Treiber-Versionen, da die neuesten nur noch "mehr schlecht als recht" für die alten Grafikkarten angepasst werden.

[venice2]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1473495)

Zitat:

Zitat von venice2 (Beitrag 1473494)

Ich soll das Problem beheben das von NVIDIA Control Panel verursacht wird?
Ist das nicht eine Sache die NVIDIA beheben sollte?

Die Frage ist ob es wirklich ein Fehler in der SW ist (steht das wohl im Windows-Log)?

Ja! Steht es.

Welches Interesse sollte ich haben hier Unwahrheiten zu veröffentlichen?
Ja es ist der Menu Punkt um die NVIDIA Systemsteuerung aufzurufen.

Es gibt eine extra APP die aus dem Store von MS installiert werden kann die funktioniert aber auch nur mehr schlecht als recht.
Meistens crasht der Explorer beim ersten Aufruf des Explorer Kontext Menu nach dem Neustart und es hat nichts mit Treibern zu tun.
Und dann funktioniert meine Anwendung nicht mehr weil die ProcID des Explorer sich geändert hat.

Ich muss also Fehler abfangen die vom System selbst generiert werden. Stupid! Win10
https://answers.microsoft.com/en-us/...6-d30c8cc4d603

Ist das meine Aufgabe?
Sieht man auf das Datum dann erkennt man wie lange das Problem schon (immer noch) besteht.

[Michael II]

Zitat:

Zitat von venice2 (Beitrag 1473496)

Ja! Steht es.

Dann hilft es vielleicht, wenn du den vollständigen WinEventLog Eintrag hier mal postest.

Zitat:

Zitat von venice2 (Beitrag 1473496)

Ist das meine Aufgabe?

Zu einem Teil definitiv JA. Windows ist nicht zu verwechseln mit betreutem Wohnen. Du könntest ja mal prüfen, ob die ganze Sache läuft, wenn du Standardgrafiktreiber verwendest (?).

Zitat:

Zitat von venice2 (Beitrag 1473496)

Und dann funktioniert meine Anwendung nicht mehr weil die ProcID des Explorer sich geändert hat.

Erklär doch mal, wieso dein Programm nicht mehr funktioniert, wenn sich die PID wegen Neustart des Explorers geändert hat. Mit einem Neustart der explorer.exe sollte dein Programm doch genau so gut zurecht kommen, wie wenn sich Handles aus irgend einem Grund ändern (?).

Wenn du mit ein wenig Code erklärst, was nach der Änderung der explorer.exe PID dann nicht mehr funktioniert, dann kann dir doch sicher irgendwer helfen.

[venice2]

Zitat:

wenn du den vollständigen WinEventLog Eintrag hier mal postest.

Unnötig, da es niemanden etwas bringt und nichts mit dem eigentlichen Problem zu tun hat.
Wie kannst du helfen wenn du das Log siehst?

Zitat:

Windows ist nicht zu verwechseln mit betreutem Wohnen.

Aber es sollte ein gewisses maß an Stabilität mitbringen.
Davon jedoch kann ich mit der ewigen Beta Version von WIN10 nichts erkennen.

Zitat:

Erklär doch mal, wieso dein Programm nicht mehr funktioniert, wenn sich die PID wegen Neustart des Explorers geändert hat.

Weil der Papierkorb mit dem Explorer verbunden ist.
Wenn der Explorer abstürzt bekommt mein Programm nicht mehr mit ob dieser voll oder leer ist.
Es aktualisiert also den aktuellen Status nicht mehr.

Zitat:

dann kann dir doch sicher irgendwer helfen.

Ich kann mir selber helfen wenn ich den besagten Hook ins Programm implementiere.
Die Frage war also schon beantwortet.

Zitat:

ob die ganze Sache läuft, wenn du Standardgrafiktreiber verwendest

Was hat der Grafiktreiber mit dem Aufruf des Konfigurations Programm zu tun?
Das sind 2 paar Schuhe, zudem verwendet der Standard Grafiktreiber den Dienst "NVIDIA Display Container LS" gar nicht, bringt also nichts.

[KodeZwerg]

ich blicke gerade nicht so ganz durch ob das problem behoben ist ansonsten würde ich vielleicht so vorgehen:

Delphi-Quellcode:

function GetExplorerPID: DWORD;
var
  hWnd: Cardinal;
  PID: DWORD;
begin
  hWnd := FindWindow('Progman', 'Program Manager');
  GetWindowThreadProcessId(hWnd, @PID);
  Result := PID;
end;

Sowas in der art vor deinem "Schau nach Korb" dingens rein?

[venice2]

Zitat:

Zitat von KodeZwerg (Beitrag 1473539)

ich blicke gerade nicht so ganz durch ob das problem behoben ist ansonsten würde ich vielleicht so vorgehen:

Delphi-Quellcode:

function GetExplorerPID: DWORD;
var
  hWnd: Cardinal;
  PID: DWORD;
begin
  hWnd := FindWindow('Progman', 'Program Manager');
  GetWindowThreadProcessId(hWnd, @PID);
  Result := PID;
end;

Sowas in der art vor deinem "Schau nach Korb" dingens rein?

Es geht darum das Problem System weit zu kontrollieren ohne Timer das macht der Hook.
Deine Lösung ist aber sehr weit davon entfernt.
Es bringt mir nichts alle "ms" diese Aufzurufen. Danke

Die frage war auch nicht wie ich an die PID komme sondern

Zitat:

Wie kann ich am besten prüfen ob der Explorer abgestürzt ist ohne Timer?

@Bernhard hat es im 2 Beitrag schon beantwortet.

[venice2]

Nur nochmal zur Vervollständigung.
Ich registriere den Papierkorb damit das Event WM_SHELLNOTIFY ausgelöst wird.

Delphi-Quellcode:

{$REGION 'procedure RegisterRecyleBin'}

procedure TMainApp.RegisterRecyleBin(WinHandle: HWND);
var
  pidlRecycleBin: PItemIDList;
  stPIDL: TSHChangeNotifyEntry;
  hr: HRESULT;
begin

  hr := SHGetSpecialFolderLocation(WinHandle, CSIDL_BITBUCKET, pidlRecycleBin);
  if Succeeded(hr) then
  begin
    stPIDL.pidl := pidlRecycleBin;
    stPIDL.fRecursive := True;

    FHNotifyRBin := SHChangeNotifyRegister(WinHandle,
      SHCNF_ACCEPT_INTERRUPTS or SHCNF_ACCEPT_NON_INTERRUPTS, SHCNE_ALLEVENTS, WM_SHELLNOTIFY, 1,
      stPIDL);

    if 0 = FHNotifyRBin then
      RaiseLastOSError(GetLastError);
  end
  else
    RaiseLastOSError;

  // Hier werde ich nun den Hook implementieren und die Anwendung entsprechend des Event neu starten.
end;
{$ENDREGION}

Wenn nun der Explorer abstürzt wird das Event WM_SHELLNOTIFY nicht mehr ausgelöst da es zum vorherigen Prozess Explorer.exe nicht mehr gültig ist.
Bzw. Der Papierkorb ist dann nicht mehr registriert (FHNotifyRBin = Registrations ID) ist dann ungültig.
Wie gesagt es ist mir unverständlich das ein System so unzuverlässig ist und man selber eventuelle Fehler diesbezüglich abfangen muss.

[venice2]

Hier ist jetzt die Lösung.

Delphi-Quellcode:

procedure WinEventProc(hWinEventHook: THandle; event: DWORD; EHandle: HWND;
  idObject: Integer; idChild: Integer; idEventThread: DWord;
  dwmsEventTime: DWord); stdcall;
begin
 if (event = EVENT_OBJECT_DESTROY) and (EHandle = HwndTarget) and
   (idObject = OBJID_WINDOW) and (idChild = INDEXID_CONTAINER) then
   begin
     if (MainApp.FHNotifyRBin <> 0) then
     begin
       if SHChangeNotifyDeregister(MainHandle) then
       begin
         SendMessage(MainHandle, WM_COMMAND, IDM_Restart, 0);
         MainApp.RegisterRecyleBin(MainHandle);
       end;
     end;
   end;
end;

MainProc.

Delphi-Quellcode:

    WM_DESTROY:
      begin
        if (HWEH <> 0) then
          UnhookWinEvent(HWEH);

Delphi-Quellcode:

{$REGION 'procedure RegisterRecyleBin'}
procedure TMainApp.RegisterRecyleBin(WinHandle: HWND);
var
  dwProcessId: DWord;
  dwThreadId: DWord;
  pidlRecycleBin: PItemIDList;
  stPIDL: TSHChangeNotifyEntry;
  hr: HRESULT;
begin

  HwndTarget := FindWindow('Progman', 'Program Manager');
  dwThreadId := GetWindowThreadProcessId(HwndTarget, @dwProcessId);

  if (dwThreadId <> 0) then
    HWEH := SetWinEventHook(EVENT_OBJECT_DESTROY, EVENT_OBJECT_DESTROY, 0,
    @WinEventProc, dwProcessId, dwThreadId, WINEVENT_OUTOFCONTEXT);

  hr := SHGetSpecialFolderLocation(WinHandle, CSIDL_BITBUCKET, pidlRecycleBin);
  if Succeeded(hr) then
  begin
    stPIDL.pidl := pidlRecycleBin;
    stPIDL.fRecursive := True;

    FHNotifyRBin := SHChangeNotifyRegister(WinHandle,
      SHCNF_ACCEPT_INTERRUPTS or SHCNF_ACCEPT_NON_INTERRUPTS, SHCNE_ALLEVENTS, WM_SHELLNOTIFY, 1,
      stPIDL);

    if 0 = FHNotifyRBin then
      RaiseLastOSError(GetLastError);
  end
  else
    RaiseLastOSError;
end;
{$ENDREGION}

Aber!
Wie kann ich das nun zuverlässig testen?
Wenn ich nun einen Hard Reset ausführe also den Prozess Explorer kille dann startet der Explorer nicht automatisch neu und dann wird das DesktopListView nicht mehr gefunden.
Gibt es einen anderen weg den Explorer zu beenden so das er automatisch neustartet damit ich den Fehler gegenprüfen kann?

EDIT:
Es ist ja nicht die Aufgabe meiner Anwendung den Explorer neu zu starten oder?

[Klaus01]

.. geht es nicht über den TaskManager Windows-Explorer markieren -> unten rechts neu starten.

Grüße
Klaus

[venice2]

Zitat:

Zitat von Klaus01 (Beitrag 1473601)

.. geht es nicht über den TaskManager Windows-Explorer markieren -> unten rechts neu starten.

Grüße
Klaus

Ja. Danke.
Aber dazwischen greift ja das Event bzw. die Callback.
Wenn ich danach die Anwendung neu\restarte wird das DesktopListView nicht gefunden der Explorer startet ja erst danach neu!

Werde wohl einen Loop hinzufügen müssen der darauf wartet bis das Handle vom Progman wieder gefunden wird.

[himitsu]

Es gibt doch aber auch irgendwo ein Event, wenn der Explorer die Taskleiste neu gestartet wurde.
Wenn man etwas hat, was sich dort rein hängt, dann muß man eben auch auf dessen Events reagieren.


Und ja, es ist krank, dass Desktop/Taskleiste und Explorer.exe ein und das Selbe sind,
aber damit muß man eben leben, bis es endlich mal repariert/geändert wird.

[venice2]

Zitat:

Wenn man etwas hat, was sich dort rein hängt, dann muß man eben auch auf dessen Events reagieren.

Ich verwende nichts was sich dort reinhängt. ;)

Habe es jetzt so geändert. Ob das elegant ist mag dahin gestellt sein.

Delphi-Quellcode:

procedure WinEventProc(hWinEventHook: THandle; event: DWORD; EHandle: HWND;
  idObject: Integer; idChild: Integer; idEventThread: DWord;
  dwmsEventTime: DWord); stdcall;
var
  Counter: Integer;
begin
 if (event = EVENT_OBJECT_DESTROY) and (EHandle = HwndTarget) and
   (idObject = OBJID_WINDOW) and (idChild = INDEXID_CONTAINER) then
   begin
     if (MainApp.FHNotifyRBin <> 0) then
     begin
       HwndTarget := 0;
       Counter := 0;
       if SHChangeNotifyDeregister(MainHandle) then
       begin
         MainApp.FHNotifyRBin := 0;

         repeat
           HwndTarget := FindWindow('Progman', 'Program Manager');
           WinProcessMessages;
           inc(Counter);
         until (HwndTarget <> 0) or (Counter = 30000);

         if HwndTarget <> 0 then
           MainApp.RegisterRecyleBin(MainHandle);
       end;
     end;
   end;
end;

[Michael II]

Zitat:

Zitat von himitsu (Beitrag 1473606)

Es gibt doch aber auch irgendwo ein Event, wenn der Explorer die Taskleiste neu gestartet wurde.

Delphi-Quellcode:

RegisterWindowMessage('TaskbarCreated')

[venice2]

Zitat:

Zitat von Michael II (Beitrag 1473611)

Zitat:

Zitat von himitsu (Beitrag 1473606)

Es gibt doch aber auch irgendwo ein Event, wenn der Explorer die Taskleiste neu gestartet wurde.

Delphi-Quellcode:

RegisterWindowMessage('TaskbarCreated')

Ja. Aber ich mache nichts mit der Taskbar

[himitsu]

Zitat:

Zitat von venice2 (Beitrag 1473609)

Ich verwende nichts was sich dort reinhängt. ;)

Und als was bezeichnest du SetWinEventHook und SHChangeNotifyRegister?

Das ist egal. Explorer und Taskleiste sind quasi das Gleiche.
Die erste Instanz der explorer.exe ist der "Desktop", mit der Taskleiste drauf.
Genauso wie (File) Explorer und Internet Exporer untrennbar zusammen gehören.
Der Interactive Desktop und die WebView des Explorers ist ein Internet Explorer.
Das FTP im Explorer läuft über den Intenret Explorer. :wall: (und alle runtergeladenen Dateien landen im IECache, wo auch noch die gesetzte Speichergrenze ignoriert wird)
Man kann sogar über die selbe API alle Internet Explorer und (File) Explorer auslisten, mit samt ihrer URL/Pfad.

[Michael II]

[QUOTE=venice2;1473613]

Zitat:

Zitat von Michael II (Beitrag 1473611)

Ja. Aber ich mache nichts mit der Taskbar

Musst du auch nicht - ist aber meistens Methode der Wahl, wenn es darum geht auf Explorer Neustart zu checken. (ausführlich dokumentiert auf den microsoft Seiten)

[venice2]

Zitat:

Zitat von Michael II (Beitrag 1473618)

Zitat:

Zitat von venice2 (Beitrag 1473613)

Ja. Aber ich mache nichts mit der Taskbar

Musst du auch nicht - ist aber meistens Methode der Wahl, wenn es darum geht auf Explorer Neustart zu checken. (ausführlich dokumentiert auf den microsoft Seiten)

Ich verstehe euren Einwand jetzt nicht.
Was, wie, wo soll ich ändern? bzw. Ist bei mir nicht die korrekte Implementierung.

Ich habe doch ein Event
HWEH := SetWinEventHook

Warum soll ich jetzt noch eine Message Registrieren.
RegisterWindowMessage('TaskbarCreated')

Ich frage deshalb nochmal weil ich Probleme habe der HOOK greift nicht immer.

Delphi-Quellcode:

    if (HWEH <> 0) then
    begin
      UnhookWinEvent(HWEH); // HOOK zerstören wenn erstellt.
      HWEH := 0;
    end;

    HWEH := SetWinEventHook(EVENT_OBJECT_DESTROY, EVENT_OBJECT_DESTROY, 0,
      @WinEventProc, dwProcessId, dwThreadId, WINEVENT_OUTOFCONTEXT); // HOOK erstellen.

Papierkorb registrieren

Delphi-Quellcode:

      FHNotifyRBin := SHChangeNotifyRegister(WinHandle,
        SHCNF_ACCEPT_INTERRUPTS or SHCNF_ACCEPT_NON_INTERRUPTS, SHCNE_ALLEVENTS, WM_SHELLNOTIFY, 1,
        stPIDL);

Seltsamer weise incrementiert FHNotifyRBin bin mir nicht sicher ob das so sein soll.
Ich deregistriere doch das Event.

Delphi-Quellcode:

if SHChangeNotifyDeregister(MainHandle) then

trotzdem wird FHNotifyRBin incrementiert

[himitsu]

Es ist das Event, wo du dein anderes Event/Notifier neu registrieren kannst/musst/solltest/darfst.

z.B. wird das auch verwendet, damit man seine TrayIcons neu registriert, nachdem die Taskleiste neu erstellt wurde.

[venice2]

Zitat:

Zitat von himitsu (Beitrag 1473625)

Es ist das Event, wo du dein anderes Event/Notifier neu registrieren kannst/musst/solltest/darfst.

z.B. wird das auch verwendet, damit man seine TrayIcons neu registriert, nachdem die Taskleiste neu erstellt wurde.

Bin wohl zu dumm begreife nicht was ihr wollt.
Habe meinen vorherigen Beitrag nochmal editiert.

Könntet ihr mir vielleicht anhand meiner Implementierung zeigen was, wo ich etwas ändern soll.

[TurboMagic]

Würdest du dich da registrieren, bekämst do scheinbar automatisch eine Windows Botschaft sobald der Taskbar gestartet wurde, was nach einem automatischen Neustart des Explorers auch automatisch passiert. Wenn du aus diese Message triggerst, dann bräuchtest du vermutlich deine Warteschleife nicht.

Falls die Warteschleife doch unumgänglich sein sollte, schon mal dran gedacht diese mittels SLeep(1); drin etwas weniger CPU hungrig zu gestalten?

[venice2]

Zitat:

Zitat von TurboMagic (Beitrag 1473630)

Falls die Warteschleife doch unumgänglich sein sollte, schon mal dran gedacht diese mittels SLeep(1); drin etwas weniger CPU hungrig zu gestalten?

Warum?
Ich mache es anders.

Delphi-Quellcode:

         
repeat
  HwndTarget := FindWindow('Progman', 'Program Manager');
  WinProcessMessages;
  inc(Counter);
until (HwndTarget <> 0) or (Counter = 30000);

siehe!

Delphi-Quellcode:

procedure WinProcessMessages;
var
  ProcMsg: TMsg;
begin
  while PeekMessage(ProcMsg, 0, 0, 0, PM_REMOVE) do
  begin
    if (ProcMsg.message = WM_QUIT) then
      Exit;
    TranslateMessage(ProcMsg);
    DispatchMessage(ProcMsg);
  end;
end;

Da ist nichts CPU hungrig.
Alle Messagen werden weiter behandelt und sollten mit einem Sleep nicht unterbrochen werden.

Zitat:

Würdest du dich da registrieren, bekämst do scheinbar automatisch eine Windows Botschaft sobald der Taskbar gestartet wurde

Muss mich da mal schlau machen verstehe immer noch nicht warum ich ein extra Event definieren sollte.

[venice2]

Ok jetzt verstehe ich was ihr meint.

Habe den SetWinEventHook entfernt.
In WM_CREATE registriere ich jetzt die WindowMessage 'TaskbarCreated'

Delphi-Quellcode:

  case Msg of

    WM_CREATE:
      TaskbarRestart := RegisterWindowMessage('TaskbarCreated');  

    else
      if (Msg = TaskbarRestart) then
      begin
        MainApp.RegisterRecyleBin(WinHandle);
        SendMessage(WinHandle, WM_COMMAND, IDM_Restart, 0);
      end;
  end;
  Result := DefWindowProc(WinHandle, Msg, wP, lP);

Und gut ist.
Benötige dann die Schleife nicht mehr.

@Michael II, @himitsu
Thanks!

[himitsu]

Ich weiß noch nicht seit wann TApplicationEvents existiert (mindestens XE) und seit wann Delphi auch auf dieses Event registriert (mindestens seit es TTrayIcon gibt), aber ich weiß dass Delphi darauf reagiert und ...

Strg+Shift+F

Suchwort: TaskbarCreated
Dateifilter: *.pas;*.dfm;*.dpr;*.dpk;*.inc;*.txt
Verzeichnisse: $(BDS) mit Unterverzeichnissen

Schon findet man

Delphi-Quellcode:

else if Cardinal(Message.Msg) = RM_TaskbarCreated then
begin
  Perform(CM_WININICHANGE, 0, 0);
  Perform(CM_SYSCOLORCHANGE, 0, 0);
  Perform(CM_SYSFONTCHANGED, 0, 0);
  Perform(CM_PARENTCOLORCHANGED, 0, 0);
  Perform(CM_PARENTFONTCHANGED, 0, 0);
  Perform(CM_PARENTBIDIMODECHANGED, 0, 0);
  Perform(CM_PARENTDOUBLEBUFFEREDCHANGED, 0, 0);

...

initialization
  InitProcs;
  RM_TaskBarCreated := RegisterWindowMessage('TaskbarCreated');

und landet letztendlich z.B. bei Application.OnSettingChange oder besser noch bei ApplicationEvents.OnSettingChange .

[Michael II]

Cool venice2. Thema abgeschlossen :).

Nur noch eine kurze Frage himitsu... du schreibst:

Zitat:

Zitat von himitsu (Beitrag 1473646)

....und landet letztendlich z.B. bei Application.OnSettingChange oder besser noch bei ApplicationEvents.OnSettingChange .

Verstehe ich dich richtig? Du meinst damit, dass nach 'TaskbarCreated' ApplicationEvents.OnSettingChange ausgelöst wird?
Bei meinem Delphi 14.1/Windows 10 nicht. D läuft zwar nach 'TaskbarCreated' bei vcl.forms.TCustomForm.WndProc (also "if Cardinal(Message.Msg) = RM_TaskbarCreated (TRUE)...") durch, aber nicht bei ApplicationEvents.OnSettingChange. Auch im ApplicationEvents.OnMessage kommt 'TaskbarCreated' nicht an.

Was funktioniert: Im ApplicationEvents.OnMessage auf 'TaskbarButtonCreated' checken, also

Delphi-Quellcode:

procedure TForm1.ApplicationEvents1Message(var Msg: tagMSG;
  var Handled: Boolean);

begin
  if msg.message = rm_TaskbarButtonCreated then
    "tu etwas (zum Beispiel RegisterRecyleBin(..);)"
end;

wobei

Delphi-Quellcode:

rm_TaskbarButtonCreated := RegisterWindowMessage('TaskbarButtonCreate');

[Michael II]

Noch ein Tipp:

Windows registriert diverse Meldungen wie 'TaskbarCreated', 'TaskbarButtonCreated' und man kann auch eigene Meldungen registrieren (RegisterWindowMessage('MeineEigeneMeldung')). Einem Text wird also durch RegisterWindowMessage eine Nummer zugeordnet.

Es gibt auch die Umkehrfunktion: Wenn du in deinem Programm checken willst, ob Windows solche registrierte Nummern/Meldungen M an deine App sendet, dann prüfst du dies mit GetClipboardFormatName(M, ...).

In deinem Fall hättest du explorer.exe neu starten und dann in deiner App prüfen können, welche registrierten Windows Meldungen empfangen werden. Dies hätte dich auf die Spur 'TaskbarCreated' oder wenn du TApplicationEvents.OnMessage ausgewertet hättest auf 'TaskbarButtonCreated' geführt.

[venice2]

Zitat:

Zitat von Michael II (Beitrag 1473658)

Noch ein Tipp:

Windows registriert diverse Meldungen wie 'TaskbarCreated', 'TaskbarButtonCreated' und man kann auch eigene Meldungen registrieren (RegisterWindowMessage('MeineEigeneMeldung')). Einem Text wird also durch RegisterWindowMessage eine Nummer zugeordnet.

Es gibt auch die Umkehrfunktion: Wenn du in deinem Programm checken willst, ob Windows solche registrierte Nummern/Meldungen M an deine App sendet, dann prüfst du dies mit GetClipboardFormatName(M, ...).

In deinem Fall hättest du explorer.exe neu starten und dann in deiner App prüfen können, welche registrierten Windows Meldungen empfangen werden. Dies hätte dich auf die Spur 'TaskbarCreated' oder wenn du TApplicationEvents.OnMessage ausgewertet hättest auf 'TaskbarButtonCreated' geführt.

Danke für die Infos.
Mit dem neustarten des Explorers ist so eine Sache denke mal nicht das eine Anwendung den Explorer neustarten sollte das ist eine Sache des Betriebssystem auf etwaige Probleme zu reagieren.

Das mit der RegisterWindowMessage ist für mich vollkommen IO und was wichtig ist funktioniert immer.
Beim setzen des Hook war das leider nicht gegeben.
Nochmals Danke an euch.

Hier der Test OTTB64 Source include

1. Prog starten
2. erstelle imaginäre Text Datei.
3. Lösche diese (Papierkorb nicht löschen)
4. Starte den Windows Explorer neu
5. lösche den Papierkorb
5. Prüfe danach ob sich der Status des Papierkorbs von OTTB64 ändert.

Darum ging es mir.

EDIT:
Nebenbei deine VCL-Lösung würde ich jeden empfehlen der ein Icon zum Tray addiert damit nach einem Absturz des Explorers das Programm weiterhin über das Icon bedienbar bleibt.