Erstmal nein, bei diesen
API liegt (derzeit) nicht der Fehler.
Womit man aber aufpassen muss, dass wenn die
Datei nicht existiert, diese Funktionen nichts (0) zurückgeben. (z.B. wenn hier Buchstaben am Ende fehlen)
Das, was ich bisher testen konnte, da war bereits vor dem GetLongPathName der String abgeschnitten.
LongStrings, wie AnsiString und UnicodeString/String, enthalten immer zwei folgende #0#0, damit PChar sich ohne Probleme direkt ableiten lässt.
So lange dort hinten eine #0 reingeschrieben wird, ist es egal.
Viele nutzten GetMem und Co. für den Zwischenspeicher des Strings, inkl. der letzten #0.
Andere nutzen einen String, aber reservieren
im String auch einen Platz für die letzte #0, welche sie abschließend nochmals abschneiden.
Ich finde es unschön, hier unnötig den kompletten Stringspeicher unnötig umher kopieren zu müssen.
Delphi-Quellcode:
class function TForm25.GetShortName(Filename: string): string;
begin
SetLength(Result, GetShortPathName(PChar(Filename), nil, 0));
SetLength(Result, Integer(GetShortPathName(PChar(Filename), PChar(Result), Length(Result))) - 1);
end;
Und außerdem sind diese beiden
API echt pervers.
Sind sie erfolgreich, dann ist im Result
keine abschließende #0 enthalten, aber im Falle eines Fehlers, ist die #0 doch mit drin.
OK -> Result sind nur die kopierten Zeichen (ohne #0)
ERROR, aka Speicher zu klein -> Result ist der komplett nötige Speicher, in Zeichen, inkl. der #0
.msg versteht im Grunde nur Outlook.
.eml verstehen nahezu alle Mailprogramme.
Und im integrierten
Indy ist die Behandlung der EML enthalten.
Wir nutzen es zum Senden von Mails, über das Standardmailprogramm, inkl. Anhänge und Formatierungen, was in der
MAPI offiziell nicht vorgesehen ist.
Zitat
Baum-Darstellung
