VST / Drag and Drop Component Suite

[wicht]

Hi Forum.

Ich hab da ein Problem an dem ich verzweifel. Ihr seid meine letzte Hoffnung.. :)
Also, gegeben ist ein Programm mit eigener Ableitung von VirtualStringTree und den Drag and Drop Komponenten (von hier). Ich möchte gerne Dateien in den Explorer ziehen, das mache ich im abgeleiteten Baum im überschriebenen DoDragging() folgendermaßen:

Delphi-Quellcode:

procedure TMFileTree.DoDragging(P: TPoint);
var
  i: Integer;
  Entries: TFileDataArray;
begin
  if FDragSource.DragInProgress then
    Exit;

  FDragSource.Files.Clear;
  Entries := GetSelected;
  for i := 0 to Length(Entries) - 1 do
    FDragSource.Files.Add(Entries[i].Filename);

  if FDragSource.Files.Count = 0 then
    Exit;

  DoStateChange([], [tsOLEDragPending, tsOLEDragging, tsClearPending]);
  FDragSource.Execute(True);
end;

Funktioniert auch blendend. Ich benutze die Drag und Drop Komponenten, weil ich gerne asynchron Draggen möchte. Und jetzt zu dem für mich unerklärlichen Phänomen.

Wenn ich das Programm auf einem anderen Rechner laufen lasse (Beide Rechner sind Win7 x64) kommt es zu Problemen. Sobald ich die Drag&Drop Aktion starte, bekomme ich die schöne Meldung "Thread-Fehler: Das Handle ist ungültig (6)" und das wars mit Draggen. Das interessante ist jetzt aber folgendes (war auch ein schöner Zufall, dass ich das gemerkt habe):
Starte ich das Programm von irgendeinem Pfad aus (exe hinkopieren, doppelklicken), der nicht "C:\Programme (x86)\" oder ein Unterverzeichnis davon ist, funktioniert alles blendend. Wohnt das Programm in "C:\Programme (x86)\", kommt es zu besagtem Fehler.
Eine weitere Merkwürdigkeit ist, dass, wenn ich das Programm aus dem Programme-Ordner heraus als Administrator starte (Rechtsklick->Als Administrator ausführen), auch alles gut funktioniert...

Hat da irgendjemand vielleicht einen Hinweis oder einen Denkanstoß? Vielen dank im vorraus und erstmal noch einen schönen Abend :P

[taveuni]

Was sagt Dein Debugger?
Welches Handle ist den ungültig?
Die Sourcen scheinen ja dabei zu sein.

[wicht]

Hi,

vielen Dank erstmal für deine Antwort. Bis jetzt konnte ich auf dem Rechner wo der Fehler auftritt noch nicht debuggen, ich werde das heute Abend mal versuchen irgendwie zu regeln...
Was ich so noch so halb aus dem Kopf weiß, ist der Callstack, der mir von madExcept verraten wird:

ntdll.Ki*Irgendwas*
TThread.WaitFor()
TDropFileSource.Execute()
DoDragging()

Ich denke mal das bedeutet, dass der Drag gestartet wird, aber der Drag-Thread dazu dann direkt stirbt. Nur warum passiert das nur auf diesem einen Rechner unter C:\Programme? Vielleicht hätte da noch jemand, der sich mit den Änderungen von XP->Vista->7 auskennt, was die Benutzerrechte angeht, eine ganz allgemeine Idee, was los sein könnte. Weil als Administrator geht es ja auch ohne Probleme. Ansonsten werde ich heute Abend noch mehr Forschung betreiben und alles Posten, inklusive madExcept-Log, was ich noch herausfinden kann...

Erstmal Danke für die Mühe und liebe Grüße :)

[taveuni]

Das einzige was mir dazu einfällt ist dass im Programmverzeichnis keine Schreibrechte vorhanden sind.
Dies ist wohl seit win2k so - es haben aber nicht alle bemerkt da als Administrator angemeldet.
Seit Vista ist das bereinigt. Du wirst doch nicht etwa beim Drop da was reinschreiben?
Da Du es bei Dir nicht nachvollziehen kannst: Läuft bei Dir Delphi als Administrator oder/und im Kompatibilätsmodus?

[wicht]

Nein, meine Programme arbeiten alle sauber, die schreiben nichts in C:\, C:\Programme, oder sonst wohin, wo man es nicht darf. Und das Draggen stürzt ja direkt ab, nicht erst wenn ich Dateien "fallen lasse". Also es crashed, bevor sich der Mauszeiger zu dem "Du draggst jetzt was"-Symbol verändert.

Zitat:

Da Du es bei Dir nicht nachvollziehen kannst: Läuft bei Dir Delphi als Administrator oder/und im Kompatibilätsmodus?

Ich lasse es auf beiden PCs ohne laufendes Delphi, also ohne Debugger, laufen. Beim einen tut es aus dem Programme-Pfad, bei dem anderen nicht. Der Benutzer ist auf beiden Rechnern "Administrator", aber seit Vista (?) ist das ja kein echter Administrator mehr, ausser man startet das Programm per Rechtsklick->Als Administrator starten. Das behebt ja bei dem einen das Problem, bei dem anderen nicht. Diese UAC-Virtualisierung ist auch auf beiden Rechnern laut Taskmanager für das Programm deaktiviert. Ich denke, dass man hier nicht weiter kommt, ohne auf dem Rechner, wo es nicht funktioniert, Delphi zu installieren. Das versuche ich mal nach Feierabend... Was mir noch aufgefallen ist: Ein Testprogramm, was, was das draggen angeht, den selben Code enthält, funktioniert aus C:\Programme auf beiden PCs. Ist doch zum Mäuse melken.... Mehr dazu hoffentlich später. Danke nochmal! :P

[wicht]

Spitze.
Auf dem Rechner ein Delphi installiert, gestartet, und ich werde mit der netten Meldung '"false" ist kein gültiger Integerwert' begrüßt. Dann kommt die IDE im Undocked-Classic-Mode und beim Projektöffnen oder Projekt neu anlegen haut es mir eine Zugriffsverletzung bei Adresse 0 um die Ohren.
Vermutlich war es das dann mit der Fehlersuche :| ...

[taveuni]

Zitat:

Zitat von wicht (Beitrag 1046612)

Ich denke, dass man hier nicht weiter kommt, ohne auf dem Rechner, wo es nicht funktioniert, Delphi zu installieren. :P

Seit Delphi 2007 funktioniert der RemoteDebugger einigermassen O.K.

[wicht]

Irgendwie bekomme ich das nich gebacken. Aber ich mache es jetzt anders.
Habe ein Testprogramm gebaut, funktionierte alles wie gewünscht. Selben Code in mein "Problem"-Programm gepackt - Crash.
"Problem"-Programm kastriert, also alle "uses" weg, alle Komponenten etc. entfernt - alles funktioniert wie gewünscht. So werde ich jetzt nach und nach alles noch einmal entfernen. Wenn ich das dreckige Schwein gefunden habe berichte ich hier. Der Jagdtrieb ist geweckt!

Nochmal danke für deine Unterstützung beim im-trüben-Fischen. Hätte mir hier keiner geantwortet, hätte ich einfach aufgegeben...

Schönen Abend noch :P

[wicht]

So... geschafft.
Erstmal durfte ich feststellen, dass das Programm die Drag&Drop-Operation startet, wenn "Jeder" auf den Ordner, wo es drin wohnt, Schreibzugriff hat. Damit konnte ich das Problem dann auch auf meinem Rechner nachvollziehen - ich installiere Programme oftmals woanders hin.. Darum trat das Problem bei mir wohl nicht auf. Hätte ich eigentlich auch früher ausprobieren können. Dann habe ich herausgefunden, dass ein OleCheck() für "CoMarshalInterThreadInterfaceInStream" das Draggen zum Absturz bringt. Hört sich ja erstmal verrückt an... Ich habe wirklich nachgedacht, ob ich nicht irgendwo etwas komisches, vielleicht dummes, mache, was so etwas auslösen könnte. Ich kam aber nicht drauf. Nach viel ausprobieren hatte ich dann endlich die Funktion, die scheinbar Schuld ist. Da drin wohnte ein schönes ChangeFSRedirection(), welches Wow64DisableWow64FsRedirection() benutzte, falls vorhanden. Deswegen hat das Programm wohl immer unter Windows<Vista gut funktioniert, dort gibt es diese API ja nicht, meine ich.
Also, vorsichtig sein, wenn man nicht weiß, was man genau tut :wall::wall::wall:...
Ich wollte damit herausfinden, ob der aktuelle Programmpfad beschreibbar ist, um so zu ermitteln, ob das Programm portabel genutzt werden kann (ich versuche einfach eine Datei zu erstellen, bei Erfolg wird sie wieder gelöscht). Das funktioniert aber auch ohne diese Funktion gut, ich vermute mal, weil der Taskmanager mir sagt, dass UAC-Virtualisierung für mein Programm deaktiviert ist...

Ich bin jetzt super glücklich.. Das hat mich echt nerven gekostet.. Danke nochmal. Jetzt gibt es die wohlverdiente Pizza und Schlaf, schönen Abend noch :stupid: ...