Datei-Transfer mit DragAndDropComponentSuite

[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

[himitsu]

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.

[himitsu]

Aber dennoch, über FileName:=ExtractFilename(DropFileTarget1.Files[0]); wird ja ein Dateiname dort rausgeholt.
Und demnach ist in DropFileTarget1.Files etwas drin, was dann via SaveToStream in der Datei landen müsste.