Drag&Drop funktioniert unter Win 10 nicht

**Tweaky**

Hi,
ich habe folgendes Skript

AutoIt

#RequireAdmin ;aktiv = drag & drop funktioniert nicht             nicht aktiv = drag & drop funktioniert


#Region    ;************ Includes ************
#Include <WindowsConstants.au3>
#Include <GUIConstantsEx.au3>
#EndRegion ;************ Includes ************


Opt("GUIOnEventMode", 1) ;0=disabled, 1=OnEvent mode enabled


GUICreate("Test", 200, 200, -1, -1, -1, $WS_EX_ACCEPTFILES)
GUISetState()
GUIRegisterMsg(0x233, "On_WM_DROPFILES")
GUISetOnEvent($GUI_EVENT_CLOSE, "_ende")






Func On_WM_DROPFILES($hWnd, $msg, $wParam, $lParam)
	MsgBox(0,0,0)
EndFunc   ;==>On_WM_DROPFILES






Func _ende()
	Exit
EndFunc   ;==>_ende






While 1
	Sleep(10)
WEnd

Alles anzeigen

Wenn ich unter Win 10 64bit eine Datei auf das Skript ziehen will wird die Funktion "On_WM_DROPFILES" nicht aufgerufen.
Erst wenn ich #RequireAdmin deaktiviere funktioniert es.
Jedoch brauche ich #RequireAdmin für einen anderen Teil des Skripts.

Warum geht es nicht?

misterspeed

Ohne es genau zu wissen würde ich einfach vermuten, dass unter Windows 10 die Benutzerkontensteuerung verbessert wurde oder standardmässig in einer höheren Sicherheitsstufe läuft. Das was du beschreibst sieht jedenfalls so aus, als ob Benutzeraktionen (du als einfacher Desktop Benutzer) mit GUI's welche im erhöhten Adminkontext laufen eingeschränkt wurden.

Ein workaround wäre für mich die Teile des Scriptes zu trennen, sprich den GUI Teil des Scriptes nicht mehr mit erhöhten Rechten laufen zu lassen.

Dein Hauptscript (GUI) also ohne Requireadmin aufrufen, erstmal unsichtbarer start, dann wird die UAC Abfrage durch den Start des administrativen Teils getriggert und anschließend die GUI sichtbar gemacht. Für den Anwender ist es dann nicht mehr ersichtlich, dass nur ein Workerprozess mit erhöhten Rechten läuft. Die strikte Trennung von GUI und funktionalem Teil erfordert zwar etwas mehr Aufwand, weil die Scripte untereinander kommunizieren müssen, dafür hast du aber auch einen separaten Prozess der dafür sorgt, dass deine GUI stets reagiert und nicht durch Arbeitsprozesse blockiert werden kann.

**Tweaky**

Hat noch jemand eine andere Idee ohne 2 separate exe zu erstellen?

misterspeed

Hab mich aus Neugierde nun doch mal in das Thema eingelesen und wie vermutet hat es Sicherheitsgründe warum bestimmte Window Messages nicht an Fenster/Prozesse mit erhöhten Rechten durchgereicht werden.

Hier ein paar informative Links zum Thema. Wirklich sehr interessant wie man das ausnutzen konnte (letzer Link):

http://blogs.msdn.com/b/patricka/arc…l-and-uipi.aspx
http://www.tenforums.com/general-discus…sing-issue.html
http://www.net-security.org/article.php?id=162&p=1

Dem Blog Beitrag von Microsoft zu Folge wäre es wie schon von mir vorgeschlagen eine Lösung die GUI im selben Kontext wie die explorer.exe laufen zu lassen. Eine weitere Möglichkeit ist evtl. auch das hier ChangeWindowMessageFilterEx.

misterspeed

Hier noch weitere Infos bzgl. der "ChangeWindowMessageFilter" Lösung:

https://helgeklein.com/blog/2010/03/h…-vistawindows-7

EDIT:

Scheinbar ist es aber nicht unbedingt empfehlenswert die obige Lösung zu nutzen, siehe hier...
http://www.nynaeve.net/?p=151

Peter S. Taler · *Ab 19-10-22 ergänzt um:*

Probier doch mal ob die Vermutungen stimmen und schalte die UAc aus. Schau was passiert und fahr die UAC wieder schrittweise hoch bis der Fehler wieder auftritt. Danach kann man weitersehen?

Gruß

Peter

**Tweaky**

Also es scheint so zu sein:

Die UAC einfach ganz nach unten (am wenigsten Aggressiv) stellen
#Requireadmin enthalten >>> Skript geht nicht
#Requireadmin nicht enthalten >>> Skript geht

Deaktiviere vich UAC komplett (Reg-Eintrag "EnableLUA"=dword:00000000), dann geht es immer.

Ich würde UAC gerne immer komplett deaktiviert lassen, jedoch gehen dann die Apps nicht mehr.

Jemand noch eine Idee?

misterspeed

UAC deaktivieren ist sowieso keine sinnvolle Lösung. Reichen die beiden Lösungsansätze von oben nicht? Entweder sauber programmieren und GUI von funktionalem code trennen (siehe Drei-Schichten-Architektur) oder eben mit dem "changeWindowMessageFilter" rumspielen. Beides sollte zum Erfolg führen, wobei letzteres evtl. komplizierter ist und deine Anwendung unsicher macht.