Anwendung zur Dateierweiterung aus der Registry lesen

[mm1256]

Hallo,

früher ging da ja einfach, und auch alle Suchergebnisse im WEB bringen das "alte" Ergebnis. Wo früher unter "shell\open\command" das Programm stand, steht bei mir beispielsweise unter ".mid" der "PersistentHandler". Suche ich über dessen ID weiter, komme ich zum Key "PersistentAddinsRegistered", welcher wieder einen Unter-Key hat. Der wiederum hat nur den Key "InprocServer32". Hier ist aber kein Verweis auch die Programmdatei.

Gibt es denn eine Doku, wie das alles zusammen hängt. Ideal wäre natürlich ein Beispielcode.

[Perlsau]

Was heißt "früher"? Windows 98, 2000, XP, Win7?
Was heißt "jetzt"? WinXP, Win2000, Win7?

[p80286]

W7 müßte unter "früher" fallen:

[mm1256]

Zitat:

Zitat von Perlsau (Beitrag 1302606)

Was heißt "früher"? Windows 98, 2000, XP, Win7?
Was heißt "jetzt"? WinXP, Win2000, Win7?

Du hast also auch keinen Plan und weißt nicht, was - und wann - Microsoft da geändert hat (nehme ich zumindest jetzt an, sonst würdest du nicht fragen, was ich mit "früher" meine).

Die "alte Logik" zum Eintragen einer Dateierweiterung funktioniert ja nach wie vor auch unter Win7 und Win8, aber ich muss leider den umgekehrten Weg gehen...die passende Anwendung zur Dateierweiterung finden.

[Dalai]

Ist zwar nicht so ganz das, was du suchst, aber vielleicht hilft es dir trotzdem weiter: ExtractAssociatedIcon:

Zitat:

lpIconPath [in, out]
[...]The function extracts the icon handle from that file, or from an executable file associated with that file. If the icon handle is obtained from an executable file, the function stores the full path and file name of that executable in the string pointed to by lpIconPath.

D.h. wenn man der Funktion ein "C:\dokument.doc" übergibt, müsste man den Pfad zu Word bzw. WordPad im selben Parameter wiederfinden. Ob das tatsächlich so ist, weiß ich nicht. Ich vermute sogar, dass es eine geeignetere Funktion für die Aufgabe gibt.

MfG Dalai

[DeddyH]

Evtl. FindExecutable?

[mm1256]

Vielen Dank DeddyH, genau das isses :thumb:

Zur Info für die Mitleser:

Delphi-Quellcode:

function FindExeForFileName(AFileName : string;
                          var AResult : string): boolean;
var
  Buffer : array[0..MAX_PATH] of Char;
  Handle: THandle;
begin
  AResult := 'Unbekannt';
  Handle := FindExecutable(PChar(AFileName),nil,Buffer);
  Result := Handle > 32; // EDIT: Fehler, war Handle >= 32
  if Result then AResult := String(Buffer) else
  case Handle of
    SE_ERR_FNF : AResult := 'Datei '+AFileName+' ist nicht vorhanden';
    SE_ERR_PNF : AResult := 'Ungültiger Pfad'; // kann eigentlich nicht sein ;-)
    SE_ERR_ACCESSDENIED : AResult := 'Zugriff verweigert';
    SE_ERR_OOM : AResult := 'Woow...kein Speicher mehr. XE-8 läuft ???';
    SE_ERR_NOASSOC : AResult := 'Kein assoziiertes Programm gefunden';
  end;
end;

[Luckie]

Und wo wird der Rückgabewert der Funktion zugewiesen?

[Sir Rufo]

Zitat:

Zitat von Luckie (Beitrag 1302704)

Und wo wird der Rückgabewert der Funktion zugewiesen?

In der dritten Zeile nach dem

Delphi-Quellcode:

begin

?

Allerdings wäre eine Exception hier besser ...

[Aviator]

Zitat:

Zitat von mm1256 (Beitrag 1302703)

Delphi-Quellcode:

function FindExeForFileName(AFileName : string;
                          var AResult : string): boolean;
var
  Buffer : array[0..MAX_PATH] of Char;
  Handle: THandle;
begin
  AResult := 'Unbekannt';
  Handle := FindExecutable(PChar(AFileName),nil,Buffer);
  Result := Handle >= 32;             ////  <---------------  Ich würde sagen ... hier!!
  if Result then AResult := String(Buffer) else
  case Handle of
    SE_ERR_FNF : AResult := 'Datei '+AFileName+' ist nicht vorhanden';
    SE_ERR_PNF : AResult := 'Ungültiger Pfad'; // kann eigentlich nicht sein ;-)
    SE_ERR_ACCESSDENIED : AResult := 'Zugriff verweigert';
    SE_ERR_OOM : AResult := 'Woow...kein Speicher mehr. XE-8 läuft ???';
    SE_ERR_NOASSOC : AResult := 'Kein assoziiertes Programm gefunden';
  end;
end;

Eine Exception wird ja so wie ich das sehe durch FindExecutable ausgelöst. Er könnte allerdings die GetLastError() Funktion verwenden, um die Fehlermeldungen noch auszugeben. Aber anscheinend wollte er sich seine eigenen Messages erstellen. :stupid:


[Edit]RedBox???[/Edit]

[Sir Rufo]

Nein, die API löst keine Exception aus

[Luckie]

Verdammt übersehen,weil ich es immer da setze, wo ich die Funktion verlasse und nicht irgendwo mitten drin.

Die API Funktion löst mit Sicherheit keine Exception aus. Sie hat ja Rückgabewerte. Die Exception musst schon du auslösen.

[Dalai]

Lies aber nochmal genau nach, wann die Funktion erfolgreich ist:

Zitat:

Returns a value greater than 32 if successful, or a value less than or equal to 32 representing an error.

MfG Dalai

[mm1256]

@Dalai: Danke für den Tipp. Du hast natürlich recht. Das >= ist falsch.

Delphi-Quellcode:

  Result := Handle > 32;

[Popov]

Zitat:

Zitat von Sir Rufo (Beitrag 1302705)

Allerdings wäre eine Exception hier besser ...

Ist vielleicht etwas OT, aber ich frage mich auch immer was besser ist: eine Exception oder eine alternative Lösung.

Muss es immer ein Krachbum Error-Messagebox sein mit der Info am Ende seines Weißheit zu sein? Sicher, manchmal geht es nicht anders, was soll man also noch machen wenn es keine Lösung gibt. Dann aber frage ich mich was ein Browser machen würde wenn er bei jedem Fehler in einer HTML-Datei aussteigen würde. Dann sage ich mir aber auch - warum die Mühe? Eine anständige Fehlermeldung erspart dir viel Arbeit. Und das Beste - keine wird dir Vorwürfe machen, schon gar nicht danken, wenn du statt einer Fehlermeldung versuchst den Fehler zu reparieren.

[mm1256]

Die Frage "Exception werfen" stellt sich doch bei einem WinAPI-Aufruf nicht, weil sowieso keine geworfen wird. Folglich gibt es auch nichts zu reparieren.

Es geht also lediglich um die Auswertung des Rückgabewertes. Was ich mit dem Rückgabewert "AResult" in der aufrufenden Prozedur mache, kann und möchte ich situationsbezogen entscheiden. Darum finde ich persönlich (jeder darf und soll seine eigene Variante für besser finden) diesen Weg für praktikabel, weil flexibel anwendbar.

Ob man für den Rückgabewert des Exe-Dateinamens und des möglichen Fehlertextes im Klartext jeweils eine eigene Variable nimmt, ist eine Designfrage. Ich mag's lieber kompakt, weil ich meinen Code leider öfter lesen als schreiben muss. Muss was mit dem Alter zu tun haben :?:

[Luckie]

Exceptions sind Teil der strukturierten Programmierung. Ist vielleicht Geschmackssache, ob man welche wirft und wann und wie. Aber wenn ich mit Klassen arbeite kannich einfach eine Methode nach der anderen aufrufen und die Fehlerbehandlung zentral an einer Stelle abhandeln. Hat den Vorteil, dass ich nicht zich if-then Ebenen habe und in der 10. dann gucken muss, wo ich eigentlich bin und ob alle Bedingungen noch Konsistent sind. Beispiel:

Delphi-Quellcode:

if funca then
begin
  if funcb then
  begin
    if funcc then
    begin
      // irgendwas
    else
      // irgendwas
  end
  else
    //irgendwas
end
else
  // irgendwas
end;

Jetzt der Code mit Exceptions:

Delphi-Quellcode:

funca ();
begin
  if not APIFunc then
    RaiseLastOSError;
end;

Delphi-Quellcode:

try
  funca;
  funcb;
  funcc;
execpt
  ShowMessage(EcodeToString(Exception.ECode));
end;

Das funktioniert natürlich nur, wen die Funktionen Exceptions werfen. Und da kann es schon sinnvoll sein eine API Funktion so zu kapseln, dass sie eine Exception wirft.

Siehe auch: http://docs.embarcadero.com/products...stOSError.html