Datei-Transfer mit DragAndDropComponentSuite

[harfes]

Ich möchte mit der DragAndDropComponentSuite eine PDF-Datei über mein Programm in ein bestimmtes Verzeichnis kopieren. Die PDF-Datei kommt entweder vom Explorer oder (als Email-Anhang) aus Outlook. Dazu habe ich auf einem Formular ein Panel gesetzt, auf dass die Datei gezogen werden soll und dazu ein DropFileTarget genutzt (als Target habe ich dort Panel 2 eingetragen). Wenn die Datei auf das Panel gezogen wird, soll der Dateiname angezeigt werden. Desweiteren liegt ein Button "Speichern" auf dem Formular, bei dessen Betätigung die Datei im vorgegebenen Verzeichnis gespeichert werden soll. Was bisher funktioniert: ich kann die Datei auf das Panel ziehen und es wird der Dateiname angezeigt. Beim Klick auf den Speichern-Button wird auch eine Datei im korrekten Verzeichnis abgelegt - aber ohne Inhalt. Irgendwie sehe ich gerade den Wald vor lauter Bäumen nicht...hat jemand eine Idee, was ich falsch mache? Hier der Quelltext:

FileName:=ExtractFilename(DropFileTarget1.Files[0]);
Panel2.Caption:=FileName;
//Prüfen, ob Dokument PDF
DesiredExtension:='.pdf';
S := ExtractFileExt(ansilowercase(FileName));
if S = DesiredExtension then
begin
FilePathB := Zielpfad+FileName
mem := TMemoryStream.Create;
DropFileTarget1.Files.SaveToStream(mem);
try
mem.SaveToFile(FilepathB);
finally
mem.Free;
end;
end
else
begin
ShowMessage('Das ist KEINE PDF-Datei!!!');
DropFileTarget1.Files.clear;
Panel2.Caption:='Dokument hier ablegen';
end;


Meine Vermutung ist, dass sich im FileName wirklich nur der Name der Datei verbirgt, aber nicht der Inhalt der Datei...was fehlt?


Hartmut

[jaenicke]

Du hast den korrekten Dateinamen. Warum greifst du nicht einfach auf die Datei zu und kopierst sie an die gewünschte Stelle?

So ein einfaches Empfangen von Dateien kann man aber auch ganz ohne eine solche Bibliothek machen:
https://delphidabbler.com/articles/article-11
Mit der DragAndDropComponentSuite kann man noch viel mehr machen, aber um einfach eine Datei ablegen zu können, ist die Abhängigkeit unnötig.

[harfes]

Hallo Sebastian,

wenn die Datei vom Explorer kommt, könnte ich direkt darauf zugreifen - wenn die Datei aber in einer Email angehängt ist, dann geht das nicht. Daher mein Gedanke über den Umweg einer Komponente (bei der Suche hatte ich dann die DragAndDrop-Suite gefunden). Aber so, wie es bei DelphiDabbler beschrieben ist, sieht es in der Tat deutlich einfacher aus. Danke für den Tip...ich werde mal testen.

Hartmut

[himitsu]

Wir kämpfen da auch gerade an einem Problem, was bei einem Kunden bei zwei Rechnern auftritt (vielleicht bei mehr, nach einem Blick auf andere Usernamen, aber ist sonst noch nicht aufgefallen),
also vom Outlook kommend und Dateien zufällig auch PDF, aber ist eigentlich egal.

Und zwar fehlen beim reinkommenden Dateinamen die letzten 1 oder 2 Buchstaben und dann heißt es natürlich, dass es diese Datei nicht gebe.

Wo genau der Fehler auftritt, kann ich noch nicht sagen .... vielleicht, wenn wir es die nächsten Wochen nochmal schaffen meinen zweiten Test dort laufen zu lassen ... beim Ersten war noch nichts eindeutig zu erkennen.

Aber was schonmal sicher scheint, dass es dort an einem "Problem" mit Kurznamen im NTFS hängt.

Der Kurzname im NTFS der beiden UserNamen ist länger, als der Langname,
und genau um diese Differenz fehlt "zufällig" hinten dann etwas im String.
https://www.delphipraxis.net/215264-...dateiname.html

Delphi-Quellcode:

C:\Users\m.xyzmuster\AppData\Local\Temp\abc.pdf
C:\Users\M~123456.XYZ\AppData\Local\Temp\abc.pdf
C:\Users\M~123456.XYZ\AppData\Local\Temp\abc.pd

Ach ja, wir verwenden den DropMaster2

Zitat:

Die PDF-Datei kommt entweder vom Explorer oder (als Email-Anhang) aus Outlook

Jupp, wie bei uns.

Der Explorer verwendet WM_DROPFILES,
aber Outlook nutzt IDropTarget. (früher konnte Outlook zusätzlich auch WM_DROPFILES, aber das hatten die vor Jahren ausgebaut und deswegen mußten wir dann den DropMaster einbauen)

PS: Thunderbird nutzt WM_DROPFILES und macht keine Probleme


Die ständigen Probleme mit Acrobat konnten wir nach Jahren endlich loswerden, indem wir diesen Scheißdreck losgeworden sind.
Ich würde zu gern auch Outlook verbannen, aber geht leider nicht.
Ständig, nach Updates, geht irgendwas plötzlich nicht mehr.
Bei der MAPI knallt es mit Outlook ja auch nur noch. (konnten wir durch Umstellung auf EML-Dateien beseitigen)


Und natürlich lässt sich das Problem nirgendwo bei uns nachstellen.


Relativ neue Windows 11, da tritt das Problem garnicht auf, aber dort sind die Kurznamen komplett inaktiv,
selbst GetShortPathName liefert immer nur den langen Namen.
Aber neue Windows 11 sind jetzt leider auch nicht die Lösung, welche den Kunden gefällt.

[harfes]

@himitsu: heisst das, ich kann WM_DROPFILES bei Outlook gar nicht verwenden? Dann ist der Hinweis von Sebastian auf DelphiDabbler hinfällig?

Das wäre seeehr unschön, da ich es vermeiden möchte, dass der Benutzer erst das PDF speichern muss um dann vom Explorer aus zu ziehen...

Hartmut

[himitsu]

Jupp, das von jaenicke Verlinkte, hilft hier leider nichts.


Prinzipiell kann man im Target beides implementieren, damit es egal ist, was der Sender benutzt.

WM_DROPFILES kann man leicht selbst implementieren.
IDropTarget ist aufwändiger und das will man nicht selbst machen, drum verwenden Viele irgendeine Drag&Drop-Komponente.
Bei den Komponenten ... tja, das muß man schauen, was sie implementieren, also das Eine oder das Andere oder Beides.

Normal funktioniert es, aber aktuell haben wir hier halt mit Outlook mal wieder Probleme.
Wir sind leider "immernoch" bei der Fehlersuche.

Es kann auch sein, dass es bei euch es ein anderer Fehler ist, aber du kannst ja dennoch mal nachsehn, wie der Nutzer bei euch "intern" heißt, also in C:\Users, bzw. im CMD set u aka set username oder echo %username% oder dir /x C:\Users , wobei hier der Punkt im Namen die Ursache darstellt.

[himitsu]

http://fnse.de/LongShortCheck.7z
[add] Weil mein Firefox grade was von wegen "gefährlicher Datei" plapperte -> https://www.virustotal.com/gui/url/6...219b?nocache=1

Nicht über die Größe wundern. Mit Debuginfos ist die EXE fast 150 MB klein.
Unsere Ableitung der Komponente liegt in einer Unit, welche extrem Abhängigkeiten mit sich zieht. (normal kompilieren wir gegen Packages, da fällt das so nicht direkt auf)

DragDropTest.exe

Und mit den anderen beiden Test.cmd und LongShortCheck.exe
hatte ich versucht zu schauen, ob ich das Problem bereits auf Dateisystemebene verifizieren kann,
aber dort passierte nichts, bezüglich dem Abschneiden.

Und ich es sag mal so: Es gibt eine Webseite, speziell zum Testen von Outlook,
aber so allgemein gibt es scheinbar keine Testseiten, für irgendwelche anderen Programme, bzw. so allgemein überhaupt ... also, wenn das nichts aussagt.
https://www.dragdrop.com/test/

Reine Testprogramme für Windows, oder sonstirgendwas, was man nicht erst installieren muß, nur um damit D&D testen zu können, fand ich irgendwie nicht.
Die Demoanwendung vom DropMaster2 mal ignoriert, da ich ja etwas "anderes" haben wollte, um testen zu können, ob der Fehler nicht vielleicht in unserer Komponente liegt, oder doch beim Outlook oder Windows.

[Redeemer]

@himitsu: tl;dr? Geht oder geht nicht?

Mein Stand ist: Man kann aus Outlook E-Mails und Anhänge mit der Endung .msg relativ einfach empfangen. Alle anderen Anhänge sind viel schwerer bis unmöglich, weshalb ich das in meiner Software nicht mache.

[Kas Ob.]

@himitsu

I am not sure if i do understand the problem, your software problem with drag and drop and outlook with lost/cutshort characters...

But looking at the attached project i see this strange lines

Code:

class function TForm25.GetLongName(Filename: string): string;
begin
  SetLength(Result, GetLongPathName(PChar(Filename), nil, 0) - 1);
  GetLongPathName(PChar(Filename), PChar(Result), Length(Result) + 1);
end;

class function TForm25.GetShortName(Filename: string): string;
begin
  SetLength(Result, GetShortPathName(PChar(Filename), nil, 0) - 1);
  GetShortPathName(PChar(Filename), PChar(Result), Length(Result) + 1);
end;

Why the "-1" ?
And more importantly :
Why you are not trimming after the second call based on the GetxxxxPathName result ?

My suggestion is to fix that then repeat your test with the customers:
The flow for this type of API use, should always be one call to decide the length, then allocate then call again then trim, don't cut corners, and never trust the first call for the length as it might change between the two calls.

When in doubt for Unicode and UTF8 for the real length in bytes against chars (WideChar, UTF8Char, UTF16Char....) change the allocate step mentioned above to RequiredLength*4, this will be removed with the last trim, in other words trade "little more work and allocation" against "will work always", also this will remove the need to keep tracking of the different APIs which some do return the 0 terminated and some doesn't, so you can with extra big allocated put the null char your self before the trim, and either keep it or remove it, based on the use case.

[Kas Ob.]

Also please declare those strings paramaters as const