Großschreibung (Capslock) wird ungewollt aktiviert / <Shift>, <Ctrl> oder <Alt> werden fest-gestellt #243
Etykiety
Brak etykiety
(╯°□°）╯︵ ┻━┻
Bug
Diskussion
Dokumentation
Duplikat
Gitea
Hardware
Hilfe
Invalid
Java
Lernen
Qt
Remote
Subversion
Tablet
Tastaturbelegung
Test
Treiber/Android
Treiber/iOS
Treiber/Linux/Konsole
Treiber/Linux/xkbmap
Treiber/Linux/xmodmap
Treiber/MacOS
Treiber/Windows/AHK
Treiber/Windows/kbdneo
Treiber/Windows/ReNeo
Verbesserung
Website
Windows 11
Wontfix
Worksforme
Brak kamienia milowego
Brak przypisanych
Uczestnicy 15
Powiadomienia
Termin realizacji
Brak ustawionego terminu realizacji.
Zależności
No dependencies set.
Reference: neo/neo-layout#243
Ładowanie…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Bei der Nutzung des Neovars-AHK-Skripts tritt das Problem auf, dass die Großschreibung ungewollt aktiviert wird. Ich kann das nicht konkret reproduzieren, aber nach meinen Erfahrungen tritt der Fehler dann auf, wenn die Shift-Taste dran beteiligt ist, um einen großen Anfangsbuchstaben zu schreiben.
Zuerst hatte ich die Capslock-Funktion in Verdacht. In einer geändeten Version des Skriptes habe ich in levelfunctions.ahk die Funktion ToggleMod2Lock() so verändert, dass bei Doppel-Shift – was wiederum ToggleMod2Lock aufruft – der Capslock stets AUSgeschaltet wird. Leider tritt der Bug trotzdem auf. Ich schließe daraus, dass irgendeine andere Funktion in Zusammenhang mit der Shifttaste den Capslock setzt, ohne dass ich das je getippt / gewollt habe.
Ein Nachtrag: Vor meiner Änderung an der ToggleMod2Lock()-Funktion war es so, wenn der Bug auftrat, dass ich anschließend zweimal(!) auf Doppelshift drücken musste, damit der Capslock ausgeht. Er wurde also beim ersten Mal „richtig“ aktiviert und erst beim zweiten Druck deaktiviert. Der Bug scheint dadurch etwas komplizierter, denn irgendwie wird Capslock ja aus heiterem Himmel aktiviert, ohne dass dabei das entsprechende Flag gesetzt wird. Muss was anderes sein.
Immerhin, mit der geänderten Toggle-Funktion brauche ich wenigstens nur noch einmal auf Doppelshift drücken, da in jedem Fall deaktiviert wird. Ist aber kein guter Umweg.
Ich kann den Bug bestätigen: Hatte ihn bei Verwendung des selben Treibers auf meinem Arbeitsrechner (Windows XP SP3) ebenfalls. Beim Schreiben jeden längeren Texts hatte ich dieses Phänomen in regelmäßigen Abständen mehrere Male.
Ich hatte den Treiber insofern angepasst, dass ich auf der 4. Ebene die Ziffern „123“ auf die Grundreihe und „456“ auf die untere Reihe gelegt habe. Ansonsten habe ich nichts an den Sourcen verändert. Auch bei Benutzung des vorkompilierten neovars-Treibers trat das Problem auf.
Ich habe auch eine andere Tastatur ausprobiert, dadurch hat sich aber nichts verändert.
Ich habe mittlerweile auf den nativen in Kombination mit dem kbdneo-Treiber gewechselt, dort tritt das Phänomen nicht mehr auf.
Ich kann den Bug ebenfalls bestätigen. Lebe schon seit langem damit.
Ich dachte, es läge vielleicht an meinem steinalten Rechner, dass deshalb beim Schreiben vom Treiber etwas verschluckt wird...Seit heute habe ich einen neuen Laptop mit i7-Prozessor und hatte gehofft, dass es hier nicht mehr auftritt...leider doch...es wundert mich jetzt, dass nicht alle Leute das Problem haben...?
Kompliziert ist wie ursprünglich beschrieben, dass man mal beide Shift-Tasten zusammen einmal drücken muss um wieder zur Normalschreibung zu gelangen, manchmal muss man zweimal drücken. Ich habe noch kein System dahinter entdeckt...ist dadurch leider ziemlich haklig. Ich schreibe recht viel und habe das Problem zigmal am Tag.
Aber immer noch besser als QWERTZ... :-)
Also, wenn man Shift-Shift zwei mal drücken muss, um den Lock-Effekt los zu werden, hat’s was im System. neovars gaukelt dem System eine normale Qwertz-Tastatur vor, indem es die Qwertz-Eingaben des Benutzers nach Neo-Layout als einen anderen Tastendruck erscheinen lassen – eben den der systemweiten Qwertz-Belegung. Wenn somit neovars nichts von dem Keylock weiß, muss entweder:
a) sich der Keylock im System aktiviert haben, oder
b) eine Shift-Taste hängen geblieben sein. In diesem Fall drückt man einfach jede Shift-Taste kurz (hinter einander), und der Spuk hat üblicherweise ein Ende.
Bei mir bleibt Shift manchmal beim Abschalten/Einschalten von Neo hängen. Wenn ich Shift-Pause mit dem einen Shift drücke, um Qwertz zu haben, und dann Shift-Pause mit dem anderen Shift drücke, um Neo wieder zu aktivieren, hat der Treiber das Loslassen der Shift-Tasten nicht richtig mitbekommen. Auch nacht dem Aufwachen aus dem Screensaver ist manchmal ein Mod permanent gedrückt: M3, M4 oder so.
Ich weiß noch keine Lösung und kann daher bestenfalls einen Workaround anbieten. Wenn Ihr mich mit einem nachvollziehbaren Rezept verwöhntet, könnte ich dem Problem auf die Spur kommen.
Hallo, ich habe dieses Problem auch ab und an.
Des weiteren meine ich beobachtet zu haben, dass der Lock nur beim drücken der linken Shift aktiviert wird daraus ist der Schluss zu ziehen, dass es wohl wirklich der Systemlock sein muss.
Kann diesen unglaublich nervtötenden Bug ebenfalls bestätigen. Er tritt bei mir sehr häufig auf allen von mir benutzten Systemen und Rechnern auf (Win XP und Win 7) wenn ich von QWERTZ auf NEO mittels LShift und Pause wechsel. Ebenso tritt er weniger oft auf wenn ich in NEO bleibe und längere Texte schreibe, vornehmlich mit vielen Sonderzeichen wie beim Programmieren. Reproduzieren lässt er sich allerdings leider nicht.
Großschreibung (Capslock) wird ungewollt aktiviertna Großschreibung (Capslock) wird ungewollt aktiviert / <Shift>, <Ctrl> oder <Alt> werden fest-gestelltHabe das Lock-Problem nicht nur mit <Shift>, sondern auch <Ctrl> und <Alt>. Ihr nicht? (Ein gelocktes <Ctrl> hat je nach Kontext natürlich besonders lustige Folgen, bis man es bemerkt… ;) )
Wenn's mich nicht täuscht, kann der Lock sowohl auf der linken als auch auf der rechten <Ctrl>-Taste liegen, so dass er nur durch Drücken der Richtigen von beiden auch wieder aufgehoben wird. Wenn das wichtig ist, kann ich das noch mal überprüfen, wenn es mal wieder passiert.
Ist wirklich ein ernstes Problem, z.B. weil durch den Shift-Lock manchmal Mails nicht gleich abgeschickt werden (und ich merke das nicht gleich. <Ctrl>+<Enter> schickt direkt ab, <Ctrl>+<Shift>+<Enter> legt erst mal in die Outbox.)
Hab das Problem auch täglich. Noch öfter als Shift "hängt" bei mir Strg/Super.
Leider nicht wirklich reproduzierbar. Benutze Windows XP SP3.
Gibt es einen Workaround? Debug-Logs um das Problem weiter einzukreisen?
Hab dasselbe Problem gestern bei einem Tastschreibwettbewerb gehabt. Äußerst ärgerlich, wenn ihr mich fragt grrr. Zuvor ist aber bei mir auch nie irgendwas dergleichen aufgetreten.
Ich dachte Anfangs, das läge an dieser tollen Einrastfunktion von Windows, aber diese war von vornerein deaktiviert, schied also als Ursache aus. Aber wenig später konnte ich dieses Problem folgendermaßen reproduzieren: Drückt man beide Shift-Tasten gleichzeitig (ist mir da anscheinend ungewollt passiert), wird Capslock aktiviert. Drückt man nochmal - wie hier zuvor erwähnt - beide Shift-Tasten gleichzeitig, hört der Spuk wieder auf. Das mit der Strg- und der Alt-Taste kann ich bis jetzt jedoch nicht bestätigen.
Im #neo Channel im IRC hat vorgestern ein gewisser mirko davon erzählt, dass er momentan ein C-Programm als Alternative zum AHK schreibt. Es arbeitet mit Lowlevelkeyboardhooks der Windows API und sollte das Problem mit den eingerasteten Shift/Ctrl/Alt-Tasten nicht haben. Scheint schon ziemlich ausgereift zu sein, die Ebenen sind implementiert nur Tote Tasten, Ziffernblock und Compose gibt es (noch) nicht.
Quellcode oder Programm hat er allerdings noch nicht hergegeben, hört sich aber trotzdem gut an :)
Es könnte also bald eine Lösung geben!
Ich muss sagen, dass ich kürzlich auch dieses Problem auf einem fremden System hatte. neovars.exe auf einem Win7/64 installiert, funktioniert soweit alles, aber hin und wieder bleibt das Shift hängen, das man dann mit einfachem Druck auf die linke Shift-Taste wegbekommt. Ich habe das Problem auf zwei anderen Computern nicht und noch überhaupt nie gehabt.
Wenn man das .AHK-Script im Source startet, kann man bei Auftreten dieses Problems die Tasten-History einsehen, um einen Hinweis auf die Entstehung zu bekommen. Ich habe derzeit leider wieder keinen Zugriff auf diesen Computer mit dem Problem, sodass ich auf Fischen im Trüben angewiesen bin. Meine Vermutung ist, dass sich die originalen Press/Release-Events und die vom neo-vars generierten Press/Release-Events auf den problematischen Systemen überschneiden, und so ein Release zu wenig im System ankommt. Wenn ich mich richtig erinnere, ist es mir häufiger nach dem Drücken von /, also M3+i (Neo/AdNW) passiert.
Ich werde dennoch versuchen, etwas beizutragen, und erst mal bei mir das neovars20.exe starten – normalerweise rennt bei mir der .AHK-Sourcecode. Vielleicht ist ja auch das irgendwie im Effekt unterschiedlich.
Ich könnte auch eine Debug-Version erstellen, die ein Log der letzten 100 Tastendrücke (in+out) mit Zeitstempel anlegen kann. Vielleicht liefert das dann Hinweise auf die Ursache.
Es mag ja Probleme geben, aber DAS steht so in der Neo-Referenz und ist also offiziell gewünscht.
Dafuq? Ich habe auf der kompletten Neo-Seite danach gesucht und nirgends etwas gefunden, wo auch nur ansatzweise steht, dass genau dieses - für mich ziemlich nervige - Verhalten gewollt ist. Ergo: Es ist ein Bug.
Schau doch mal in der FAQ unter „Gibt es keine Feststell-/Caps-Lock-Taste? Kann ich nicht mehr dauernd groß schreiben?“ Da steht das.
Hallo, ich beobachte den selben Fehler immer wieder, er nervt tierisch.
Bei mir kommt er interessanter Weise besonders oft vor, wenn ich in Power Point arbeite. In den anderen Programmen auch, aber viel seltener.
Er ist nicht gezielt reproduzierbar, kommt aber täglich vor (auf Arbeit).
Gibts da inzwischen eine Lösung? Kann ich bei der Fehlersuche noch etwas helfen?
Du könntest helfen, indem du folgendes machst:
Key-Logs von neo20-all.ahk nach ungewolltem Lock
weiterer Log eines festgefahrenen Ereignisses (Strg war fest)
habe zwei Logs geschickt. reicht das erstmal oder soll ich weiter sammeln?
Weiter Log: Taste festgefroren (Diesmal bei Alt&Tab)
Log von Strg-Taste (während Lock)
Log nach Lösen des Locks
Hallo,
ich habe noch etwas weiter gesammelt. Diesmal von der folgenden Seite interessant:
• 19.11.2013a.txt: habe gespeichert, während der Lock noch da war
• 19.11.2013b.txt: wenige Tastendrücke später, es ist erkennbar wie ich den Lock wieder gelöst habe (durch drücken der verschiedenen Strg/Alt/Shift-Tasten)
Auf diese Weise bekomme ich immer verlässlich den Lock gelöst.
Kann ich noch etwas zur Lösungsfindung beitragen?
Noch eine Anmerkung: Der Lock erscheint bei mir deutlich häufiger wenn ich in Power Point arbeite.
Regelmäßig geschieht es bei mir auch, dass beim Drücken von Alt+Tab das Anzeigefenster für den Wechsel bestehen bleibt. Es veschwindet, wenn ich ESC drücke.
Ich habe das Problem auch täglich. Sowohl mit Windows XP als auch mit Windows 7. Ich überlege ersthaft auf dvorak umzusteigen, die Sache ist unerträglich.
Hallo,
bei mir hat eine Veränderung der Systemumgebung stattgefunden. Das Problem besteht aber weiterhin in leicht veränderter Form (Lock tritt an anderen Stellen auf – z.B. nicht mehr bei alt+TAB)
Es wirkt auf mich so, als ob die Taste vom System einfach weiterhin als „gedrückt“ angesehen wird; als würde der AHK-Treiber nicht merken, dass die Taste wieder losgelassen wurde.
Wenn z.B. die SHIFT-Taste fest ist, verhält es sich anders, als wenn ich durch RSHIFT+LSHIFT das Großschreiben dauerhft aktiviere. Ich kann auch durch 2x RSHIFT+LSHIFT den Lock immer auflösen (nach dem 1. mal. alles Groß, nach dem zweiten mal wieder alles klein).
Mich verwundert auch, dass bei Benutzung bestimmter Programme der Lock regelmäßiger auftritt. Daraus würde ich schließen, dass die Verarbeitung der Tasteneingaben im Programm Auswirkungen hat.
Ebenso häuft sich der Fehler, wenn ich schnell tippe, vielleicht überschneiden sich ja irgendwelche Signale?
Mir wäre eine Lösung auch sehr wichtig! Ein Lock der Strg-Taste kostet manchmal viele Nerven, um die fälschlicher Weise gegebenen Befehle wieder rückgängig zu machen.
Wo können wir noch weiter nach Ursache und Lösung suchen?
Also, eine mögliche Ursache habe ich ausgemacht. Wenn jemand M3+G drückt, um einen * zu bekommen, sagt der neo-vars dem AutoHotKeyBitte schlage die Taste * an und halte sie gedrückt. Daraufhin simuliert AHK die folgende Sequenz von Tastendrücken: {Shift down}{+ down}{Shift up}, und das gleiche, wenn die Taste gedrückt bleibt und repitiert. Wenn die Taste * dann wieder losgelassen wird, macht er daraus: {Shift down}{+ up}{Shift up}. Meinem Empfinden nach sind hier zu viele Shift-Operationen im Spiel.
Besser wäre natürlich: {Shift down}{+ down} beim ersten Drücken, {+ down} beim repitieren, und {+ up}{Shift up} beim Loslassen. Es kann sein, dass sich das System beim Verarbeiten dieser nutzlos simulierten Shift-Drücke vertut und irgend ein {Shift up} vor eines der {Shift down} reiht. So glaubt das System, dass Shift noch gedrückt ist.
Wie dieser Effekt bzw. Fehler mit ALT+TAB zusammen läuft, kann ich noch nicht sagen, aber das unerwartete CapsLock wäre damit zumindest theoretisch erklärbar. Ich überlege gerade, wie ein möglicher Patch aussehen könnte, der die oben aufgezeigte Vereinfachung enthält, bin mir aber noch nicht schlüssig.
Das Problem ist bei mir auch immer wieder aufgetreten (XP + Win7).
Als Abhilfe habe ich mir einen eigenen Neo2 Treiber geschrieben: https://github.com/david0/neo2-llkh
Diesen habe ich jetzt schon länger im Einsatz und konnte derartige Probleme nicht beobachten.
Das Problem scheint immer noch zu bestehen... schaut sich das irgend jemand an?
Gruss
Jan
Das Problem tritt bei mir auch auf.
Nicht nur mit dem Shift-Lock, sondern auch mit dem M4-Lock.
Mir scheint, je schneller man schreibt, desto grösser das Problem.
Mir passiert es etwas 20 Mal täglich, dass Shift-Lock aktiviert wird, und genauso oft mit dem M4-Lock.
Ich benötige beide Locks überhaupt nicht. Ich setze sie also nie bewusst.
Lässt sich die Lock-Funktion nicht einfach deaktivieren? Für mich wäre das ein toller Workaround.
Weiss jemand, ob das möglich ist?
Ich hab hier Version 2.0-rcab903d-r5be0022 und es tritt hier sehr gehäuft auf. Manchmal scheint sich der Lock garnicht mehr zu lösen. Was dann hilft ist den Laptop zu zuklaken damit kurz der Energiesparmodus sich aktiviert und wenn ich den Laptop dann wieder auf klappe geht wieder alles.
Alles in allem sehr sehr ärgerlich.
Ich würde gerne auch eine Version präferieren in der es garkeine Locks gibt, weil ich die nicht benötige.
Deine Verärgerung kann ich gut nachvollziehen. Wie du siehst, existiert dieses Fehlverhalten seit vielen Jahren und tritt abhängig von gewissen Tippkombinationen und verwendeter Hardware (Notebook, Tastatur an USB-Hub) sogar gehäuft auf. Der Hauptgrund dafür ist sicherlich, dass NeoVars auf AutoHotkey (AHK) basiert, einem Programm und Programmiersprache für Makros und virtuelle Tastendrücke. AHK arbeitet sehr genau und merkt sich, welche Tasten virtuell gedrückt werden sollen und lässt diese auch bei erster Gelegenheit wieder los. NeoVars programmiert wiederum mit Hilfe von AHK dass Neo-Tastaturlayout. Dabei weiß AHK allerdings nichts vom Sinn und Zweck und streut so zuviele und unnötige Tastendrücke bzw. Tasten-Loslass-Folgen ein. Je nach Hardware und Tippgeschwindigkeit wird dann auch mal etwas verschluckt.
Nach dieser technischen Erläuterung nun die frohe Botschaft: ein paar Neolinge haben einen neuen Windows-Treiber namens ReNeo geschrieben, der technisch genauso wie NeoVars/AHK funktioniert, aber ohne die Zwischenschicht und die unnötigen Tastendrücke. Der Treiber ist schon einige Zeit im Einsatz und hat bisher keine solche Probleme gezeigt. Ich empfehle daher, einmal ReNeo im sogenannten Standalone-Modus auszuprobieren (ist voreingestellt). Es ist eine 1zu1-Ersetzung von NeoVars, also NeoVars beenden, ReNeo hier herunterladen, entpacken und starten.
Dieser Treiber wird vom Neo-Team vollkommen unterstützt und wird NeoVars ersetzen. Die Dokumentation ist allerdings noch nicht aktualisiert. Bei Fragen kannst du gerne hier oder im Neo-Chat schreiben.