Windows-7 Merkwürdigkeiten

09/10/2012 - 14:34 von Dieter Strassner | Report spam
Hallo NG'ler,

habe heute von einem Kunden berichtet bekommen, das unter Windows-7 der
Windowsexplorer kein Drag&Drop mehr ausführt, sobald mein VB6 Programm
geöffnet ist.

Es sollte eine Datei von einem Ordner in den anderen verschoben werden. Nach
der Sicherheitsabfrage ("wollen sie wirklich?") tat sich nichts

Schliessen meines Programmes, Wiederholung der Drag&Drop-Aktion:
Funktioniert! *staun*

Nochmal das Ganze für den interessierten Programmierer (meine Person):
Programm wieder geöffnet. Wieder Drag& Drop-Aktion.
Geht jetzt auch in dieser Konstellation. *staun*

Was kann ich daraus schlussfolgern`?
(...der Kunde berichtet zuverlàssig und genau)

Wie kann sowas überhaupt *irgendwie* miteinander zusammenhàngen?
Das VB6-Programm macht in dieser (Warte)Situation nichts, außer auf die
Eingabe zu warten.

Viele Grüße - Dieter

EDV-Kommunikation Strassner e.K.
68623 Lampertheim
Internet: www.strassner.biz
 

Lesen sie die antworten

#1 Schmidt
09/10/2012 - 15:24 | Warnen spam
Am 09.10.2012 14:34, schrieb Dieter Strassner:

habe heute von einem Kunden berichtet bekommen, das unter Windows-7 der
Windowsexplorer kein Drag&Drop mehr ausführt, sobald mein VB6 Programm
geöffnet ist.



Ohne da jetzt zu tief einzusteigen... nur eine Beobachtung
aus dem Betrieb der VB6-IDE auf Win7.

Wenn ich Drag&Drop-Sachen in der IDE testen will, dann
muss ich eine Instanz der IDE aufstarten, die *nicht*
unter Admin-Rechten làuft (der entspr. "Haken" im entspr.
*.lnk-File ist dann nicht gesetzt).

Für normale Entwicklung (Kompilieren von COM-Dlls oder
OCXen) benutze ich dann wieder mein anderes *.lnk-File mit
angehakten Admin-Rechten, da VB6 hierfür volle Schreibrechte
an der Registry verlangt.

Also mal nachfragen, ob Dein Programm beim Kunden u.U.
als Admin (oder einfach unter einem anderen UserAccount als
der Desktop) ausgeführt wird. Drag&Drop funktioniert
jedenfalls nur zwischen Prozessen die unter demselben
UserAccount laufen.

All das erklàrt aber noch nicht so richtig, warum eine
eigentlich unbeteiligte VB6-App das Drag&Drop zwischen
anderen (Dritt-)Prozessen verhindern sollte (ohne selbst als
Drag-Quelle oder Drop-Target beteiligt zu sein).

Wenn ein "bloßes Nebenherlaufen" einer Anwendung das
Drag&Drop von Dritt-Anwendungen verhindert, dann hat diese
Anwendung irgendwie "den ganzen Desktop beeinflusst" -
eventuell schaltet diese VB-App aufgrund ihrer Start-Up-
Settings ja auch das GUI um? (also "Aero-Glass aus - und
"Kein-Compositing" an ... bei dieser Umschalterei, die ja
alle laufenden Anwendungen beeinflusst, klemmt es manchmal
ein wenig, was das "beim zweiten Versuch gings dann wieder"
erklàren könnte).

Also nochmal genauer erklàren, ob die VB6-Anwendung eventuell
doch als Drag-Source oder Drop-Target benutzt wird - hierfür
gilt dann das Gesagte hinsichtlich "identischer UserAccounts
als Bedingung für erfolgreiches OLE-Drag zwischen Quell-Prozess
und Ziel-Prozess"... und halt zusàtzlich viell. nochmal nachfragen,
ob die Startup-Einstellungen der VB-App eventuell das Umschalten
der Compositing-Einstellungen des Desktops forciert.

Olaf

Ähnliche fragen