TJumpList ist recht eigenwillig

[himitsu]

Code:

-2147023721
$80070497
 S         Severity = 1 = Failure
 R         Second Severity = 0 (z.B. 1=Warning oder Hint)
 C         Customer Defined = 0
 N         0
  X        0
  FFF      Facility = Win32
     CCCC Code = $0497 = ERROR_UNABLE_TO_REMOVE_REPLACED
                         Die zu ersetzende Datei kann nicht entfernt werden.

hmmmmmmmmmmmmmmm?

1175 (0x497) -> https://learn.microsoft.com/de-de/wi...es--1000-1299-

Delphi-Quellcode:

ShowMessage(SysErrorMessage($80070497));  // Cardinal o_O
RaiseLastOSError(-2147023721);  // Integer

[Ydobon]

Zitat von jaenicke:

Es klingt ja so, als ob der Fehler zwar nicht jedes Mal auftritt, aber mit etwas probieren relativ schnell kommt, oder? Kannst du das auch in einem separaten Projekt reproduzieren, dass du hier zeigen könntest?

Wie es sein soll, wenn ich ihn provozieren will, kommt er ewig nicht. Wenn ich das Programm mal laufen lasse, kann er gar nicht oft genug kommen.

Zitat von himitsu:

Code:

-2147023721
$80070497
 S         Severity = 1 = Failure
 R         Second Severity = 0 (z.B. 1=Warning oder Hint)
 C         Customer Defined = 0
 N         0
  X        0
  FFF      Facility = Win32
     CCCC Code = $0497 = ERROR_UNABLE_TO_REMOVE_REPLACED
                         Die zu ersetzende Datei kann nicht entfernt werden.

hmmmmmmmmmmmmmmm? [/DELPHI]

Ja, das ist einer der wenigen Treffer zu dem Fehler die man im Netz finden kann. Ich wollte das aber nach Möglichkeit ignorieren, erstens, weil ich keine wirkliche Verbindung erkennen kann (na ja, siehe unten) und zweitens weil es so wohl aussichtslos ist, etwas zu unternehmen. Allerdings, Windows schreibt seine JumpList-Schandtaten u.a. in %APPDATA%\Microsoft\Windows\Recent\CustomDestinati ons tatsächlich auf die Festplatte. Möglich wären Zugriffskonflikte also. Nur, warum ausgerechnet bei meinem Progrämmchen? Das macht doch nichts wildes. JumpLists gibt es seit Windows 7, wenn er häufiger auftreten sollte, wäre vermutlich mittlerweile das Internet voll davon.

[jaenicke]

Wenn es wirklich ein Dateizugriffsproblem sein sollte, kommt natürlich automatisch das Antivirenprogramm in den Blickpunkt.

Außerdem könntest du den Process Monitor mitlaufen lassen und, wenn der Fehler auftritt, nachschauen, ob da Fehler geloggt werden.

[Ydobon]

Ich habe mal ein Minimalprogramm erstellt. Hier ist er auch da.

Delphi-Quellcode:

procedure TForm1.btn1Click(Sender: TObject);
var
  item: TJumpListItem;
begin
  JumpList1.AddCategory('eins');
  JumpList1.AddCategory('zwei');
  item := JumpList1.TaskList.Add as TJumpListItem;
  item.FriendlyName := 'OSK';
  item.path := 'C:\Windows\System32\osk.exe';
  item.Icon := 'C:\Windows\System32\osk.exe';
  for var i := 0 to 4 do
  begin
    item := JumpList1.CustomCategories[0].Items.Add as TJumpListItem;
    with item do
    begin
      path := Application.ExeName;
      Arguments := 'Test'+i.ToString;
      FriendlyName := 'Test'+i.ToString;
      path := Application.ExeName;
      icon := Application.ExeName
    end;
  end;
end;

Die Idee mit dem Virenscanner scheint ziemlich gut gewesen zu sein. Wenn der abgeschaltet ist, geht es anscheinend ohne Fehlermeldung. Also erstmal danke.
Jetzt muss ich nur noch herausbekommen, wie ich dem Scanner abgewöhne dort zu stänkern. Kann ja nicht ständig das Internet abschalten. Schlucken tut er ihn nicht. Na ja, wollte sowieso wechseln.

[jaenicke]

Vielleicht reicht es ja, wenn du die Exe oder das von dir genannte Verzeichnis als Ausnahme hinzufügst.

[Ydobon]

Geht leider nicht, das Verzeichnis "existiert nicht". Wenn ich es oberhalb mit 'recent' - also 'Zuletzt verwendet' versuche, will er gleich den ganzen Dokumentenornder raus nehmen. Den würde ich aber eher ungern aus der Überwachung entfernen.
Bleibt noch die Frage, was macht C# anders, dass der Fehler dort nicht auftritt?

[Sinspin]

Zitat von himitsu:

Delphi-Quellcode:

function TCustomJumpList.CheckUpdateError(ErrNo: HRESULT; const Description: string): Boolean;
var
  LHandled: Boolean;
begin
  Result := Succeeded(ErrNo);
  if not Result then
  begin
    LHandled := false;
    if Assigned(FOnListUpdateError) then
      FOnListUpdateError(Self, ErrNo, Description, LHandled);
    if not LHandled then
      raise EJumpListException.CreateFmt(SJumplistException, [ErrNo, Description]);
  end;
end;

Möglicher Bugfix Fehlerabfangen/-ignorieren:
OnListUpdateError und dort True zurückgeben.

Hattest Du das gesehen?
Das ist zwar keine Lösung des wirklichen Problems, aber Du kannst den Fehler fangen.

[himitsu]

Vielleicht nicht unbedingt "blind" ein Result := True; , aber zumindestens Result := WinErrorCode = $80070497; .

[Ydobon]

Zitat von Sinspin:

Das ist zwar keine Lösung des wirklichen Problems, aber Du kannst den Fehler fangen.

Doch schon, aber ich wollte es so lange wie möglich ignorieren. Wenn man die Fehlermeldung abschaltet, ist der Fehler ja immer noch da. Falls das Schreiben der Datei tatsächlich nicht klappt, die wird doch sicherlich von Windows ausgelesen, wenn die Jumpliste angezeigt wird.

Allerdings scheint es zu funktionieren. Selbst wenn der Fehler auftritt landet wohl alles was soll auch in der Liste. Sie soll ja sowieso nur funktionieren, so lange das Programm läuft, vielleicht hat Windows dann alles im Speicher. Mit Bauchschmerzen wäre es eine Lösung. Falls die zu stark werden kann ich es ja immer noch in C# umschreiben. Dabei wollte ich nach fast zwei Jahren mal wieder etwas mit Delphi machen.
Also Danke an alle, die versucht haben mir zu helfen.

[himitsu]

Zumindestens kannst du es dort still und heimlich loggen, damit es nicht ganz verschwindet.
Und jupp, darum auch die Einschränkung auf den einen Fehlercode, damit andere Fehler dennoch gezeigt werden.

Zitat:

ja immer noch in C# umschreiben

Aktuell lösen wir es zwar über eine *.EML ans StandardMailProgramm,
aber prinzipiell haben wir für die MAPI, mit Dateianhängen an Outlook, auch ein C#-Konsolenprogramm gebastelt, was die OfficeAPI im .NET nutzt, weil MSOffice mag die MAPI oft nicht.