Also ich habe mir das mal angesehen.
Die Möglichkeit WM_DROPFILES freizuschalten ist gut möglich und funktioniert auch. Nur darf man kein
COM verwenden, wie z.B. IDropTarget.
TJvFilenameEdit und TJvDragDrop funktionierten nach dem ersten Prinzip. TJvDropTarget verwendet
COM, daher funktioniert es damit nicht.
Ich habe schon die
COM Einstellungen für den Prozess heruntergefahren ohne Erfolg (
COM Implementation von IAccessControl). Andersherum kann man den Zugriff für Drag&Drop einschränken, d.h.
COM Sicherheit nach oben schrauben.
Da IAccessControl.IsAccessAllowed im ersten Fall nie aufgerufen wird, vermute ich, dass
COM schon vorher die Prüfung selbst durchführt und die Nachrichten daher erst garnicht gesendet werden.
Internet Explorer macht es so wie rollstuhlfahrer es beschrieben hat. Es gibt einen Hauptprozess und für jedes Tab einen eigenen Prozess. Wenn man nun eine Datei in den IExplorer fallen lässt, dann wird dies in einem Medium Integrity Level (MIL) Tab geöffnet. Webseiten werden jeweils in einem Low Integrity Level Tab dargestellt.
D.h. der Hauptprozess vom IE übernimmt das Drag&Drop, was ja auch funktioniert, da es im MIL ausgeführt wird. Und die Fenster selbst sind wohl Prozessübergreifend verbunden. Das sieht man im ProcessExplorer, wenn man mal die verschiedenen Bereiche mit dem FindWindow Feature anklickt. Dann sieht man, dass es jedesmal ein anderer Prozess ist.
Mit Spy sollte man keine Nachrichten sehen können, weil bei IDropTarget alles nur noch über
COM Callbacks geht.