Touch-Komponenten funktionieren in den ersten zwei Minuten nach der Anmeldung mit der benutzerdefinierten Shell nicht

648
Chris

Ich habe das gleiche Problem wie in diesem Beitrag beschrieben . Da dieses Problem jahrelang unbeantwortet blieb, dachte ich, ich würde sehen, ob jemand der Lösung näher gekommen wäre.

Das Problem ist, dass, wenn wir Windows mit einer benutzerdefinierten Shell ausführen, dh ohne zu explorer.exelaufen, die Touch-Komponenten in Windows ( wisptis.exe) in den ersten zwei Minuten scheinbar nichts bewirken. Nach dieser Zeit funktioniert alles wie geplant.

Es sieht also so aus, als würde explorer.exe beim Start etwas wisptis.exeunternehmen, das seine Sachen erledigt.

Ein Blick in den Prozessmonitor zeigt, dass nach den zwei Minuten wisptis.exeein Thread gestartet wird und eine Reihe von Einstellungen aus der Registrierung gelesen wird. Ich bin mir nicht sicher, wie ich herausfinden könnte, was dies auslöst.

Ich habe auch bemerkt, dass der Shell Hardware DetectionDienst anscheinend startet, wenn ich mich anmelde, und nach den zwei Minuten stoppt, genau dann, wenn die Berührung beginnt. Vielleicht weiß Windows nicht, dass der Computer einen Touchscreen Shell Hardware Detectionhat, bis er seine Sache getan hat. Erklärt immer noch nicht, warum es so schnell ist, wenn man die normale Explorer-Shell verwendet.

Hat jemand eine Idee, was hier los ist?

Update: Das Deaktivieren des Shell Hardware DetectionDienstes macht keinen Unterschied.

0
Das richtige Verfahren wäre, auf diese Frage eine Prämie anzubieten. Wenn Sie genau das gleiche Problem haben. Ramhound vor 9 Jahren 0
@Ramhound Du hast recht, macht Sinn. Diese Frage ist etwas unordentlich und schwer zu lesen. Chris vor 9 Jahren 0
Dies ist ein Duplikat von [Touch-Gesten im IE, die nicht ausgeführt werden, ohne dass explorer.exe einmal ausgeführt wird] (http://superuser.com/questions/447018/touch-gestures-in-ie-not-working-without-explorer-exe) -ein-einmal-einmalig) von 2012, und diese hatte keine einzige Antwort. harrymc vor 9 Jahren 0

2 Antworten auf die Frage

0
Hans Hubert Vogts

Wir hatten das gleiche Problem und haben es gelöst. Aus urheberrechtlichen Gründen kann ich Ihnen unseren Code nicht senden.

Die Lösung besteht jedoch darin, das Ereignis "ShellReady" auszulösen. Überprüfen Sie diese Adresse, um ein Beispiel für die Implementierung zu erhalten.

Zusätzlich mussten wir diesen Registrierungswert festlegen:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]  "DelayedDesktopSwitchTimeout"=dword:00000000
In Ihrer Antwort fehlt das "Beispiel zur Implementierung". Bitte fügen Sie mehr als nur einen Link hinzu. DavidPostill vor 8 Jahren 0
Interessant. Ziemlich sicher, dass ich am Ende versucht habe, dieses Ereignis abzufeuern. Ich bin nicht auf diesen Registrierungswert gestoßen, ich werde es versuchen! Chris vor 8 Jahren 0
0
user720427

Ähnliches Problem hier gelöst .

Um das Problem mit meiner WPF / C # -Anwendung zu beheben, habe ich Folgendes hinzugefügt:

using System; using System.Runtime.InteropServices; ... [DllImport("kernel32.dll")] static extern IntPtr CreateEvent(IntPtr lpEventAttributes, bool bManualReset, bool bInitialState, string lpName); [DllImport("kernel32.dll")] static extern bool SetEvent(IntPtr hEevent); ... YourStartupFunction() { ... IntPtr hEvent = default(IntPtr); hEvent = CreateEvent(IntPtr.Zero, true, true, "ShellReadyEvent"); SetEvent(hEvent);  ... }

Verwandte Probleme