Ctrl-# funktioniert nicht (immer)

[Uwe Raabe]

Es gibt da gerade Bestrebungen das sporadische Nicht-Funktionieren von Ctrl-# in den Griff zu bekommen. Das Problem ist in diese QP-Eintrag beschrieben: Key combination Ctrl+# (comment) does not work.

Meine Vermutung ist: Das reine Öffnen des Popup-Menüs genügt um die Funktionalität wiederherzustellen. Ein Auslösen der Menü-Funktion ist dazu gar nicht nötig. Es sollte also reichen, das Kontextmenü aufzurufen, wieder zu schließen und Ctrl-# nochmal zu versuchen.

Jetzt ist es aber nicht einfach, das Problem zu provozieren, da wir bisher nicht wissen wodurch es ausgelöst wird. Aber es sollte dem Einen oder Anderen vielleicht mal über den Weg laufen und dann wäre es schön, wenn ihr kurz testen könntet, ob meine Vermutung noch stimmt oder nicht. Die jeweiligen Ergebnisse könnt ihr dann hier posten.

[Redeemer]

Klingt so, als wäre die Action einfach grundlos deaktiviert, weil nicht zuverlässig überprüft wird, ob sie wieder aktiviert werden muss.

So ein Bug existiert auch anderswo seit gefühlt BDS 1 oder noch länger und bis heute:
* Formular im Designer selbst auswählen, Rechtsklick machen, das Untermenü "Element" öffnen (Rechtsklick allein reicht nicht): "Nach vorne/hinten" ist deaktiviert. Klar, denn das Formular kann das nicht.
* Im Fenster "Struktur" ein Element auswählen und darauf rechtsklicken: Menü ist immer noch deaktiviert.
Geht auch andersrum: Erst im Designer etwas anderes als die Form auswählen und Rechtsklick machen, Untermenü "Element" öffnen. Dann die Form unter "Struktur" auswählen. Besagte Funktionen stehen sinnloserweise zur Verfügung.

[TurboMagic]

Hast du mal geschaut, ob das schon in QP erfasst ist und es falls nicht bitte erfasst?

[Benmik]

Ouh, das tritt bei mir völlig zuverlässig auf, nach längerem Arbeiten. Mit Popup-Menü ist Rechtsklick in den Editor gemeint? Wäre ja toll, wenn das so einfach ginge.

Da wir dabei sind, auch bei euch müsste es doch auftreten, dass die überwachten Ausdrücke im Debugger ausgegraut und nicht mehr erreichbar sind. Gibt's da auch so etwas Einfaches?

[TurboMagic]

Lass' uns mal erst an der einen Sache arbeiten!

Bei mir trat das Strg-# Problem auch zuverlässig auf, bis ich Uwe's neue Idee mit rechtsklick
im Editor zum Kontextmenü Aufrufen testen wollte. Da trat's dann vorher nicht mehr auf :-(

=> kannst du das mal testen und bitte Rückmeldung geben ob das alleinige Öffnen des Kontextmenüs
schon was bringt? Ich hatte dann immer mit der Maus den "Kommentar Umschalten" Menüpunkt betätigt
und ab da das Problem für die IDE Sitzung abgestellt gehabt. Aber Uwe will ja getestet haben,
ob das alleinige Öffnen des Kontextmenüs dafür reicht.

[Uwe Raabe]

Zitat:

Zitat von TurboMagic (Beitrag 1471343)

Hast du mal geschaut, ob das schon in QP erfasst ist und es falls nicht bitte erfasst?

Der QP wird aktuell mangels Reproduzierbarkeit nicht geöffnet - kann ich verstehen.

Meine Idee basiert auf der Annahme, dass ein TAction.OnUpdate den Shortcut wieder ins Rennen bringt. Mit dem Hinweis könnten wir den Bug vielleicht doch noch im System pushen. Ich würde es aber nicht ins QP übernehmen, wenn es eine Sackgasse ist.

[TurboMagic]

Hallo Uwe,

da hab' ich mich einerseits unglücklich ausgedrückt und du andererseits missverstanden was ich meinte.
Die Strg-# Sache ist mir bewußt (ich kenne den Report Erfasser).

Ich meinte die Sache im Formdesigner die Benmik in then Thread eingebracht hat.

Grüße
TurboMagic

[Uwe Raabe]

Zitat:

Zitat von TurboMagic (Beitrag 1471352)

Ich meinte die Sache im Formdesigner die Benmik in then Thread eingebracht hat.

OK. (War zwar Redeemer, aber egal)

[himitsu]

Jo das funktioniert bestimmt schon seit 10 Jahren nicht richtig und ein Muster konnte ich auch nicht erkennen.
Weiß aber auch nicht mehr wann es zuletzt war und ob es dann auch irgendwann wieder funktioniert.

Witzig ist aber, dass Strg+/ (Nummerblock) dagegen fast immer funktioniert und das Selbe macht. :wink:
Ist schon fast automatisch, dass ich dann zu

Delphi-Quellcode:

/

wechsel und es garnicht mehr richtig mitbekomm. :oops:

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1471358)

Witzig ist aber, dass Strg+/ (Nummerblock) dagegen fast immer funktioniert und das Selbe macht.

Das ist der entsprechende Key-Code für das Englische Tastatur-Layout. Hat 'ne Weile gedauert, bis die mit unserem Code überhaupt etwas anfangen konnten. Vermutlich ist das Ganze eine rein Deutsche Angelegenheit.

[Benmik]

"Befolgend dies ward der Tabant,
ein völlig deutscher Gegenstand."

(Christian Morgenstern)

[haentschman]

Moin...:P

Zitat:

Meine Vermutung ist: Das reine Öffnen des Popup-Menüs genügt um die Funktionalität wiederherzustellen

...nicht nur. Bei mir reicht auch ein beherztes Klicken auf "Einfügen" (Tastatur) und wieder zurück. :wink:

Zitat:

Das ist der entsprechende Key-Code für das Englische Tastatur-Layout

...der Code der "Einfügen" Taste ist doch überall gleich? Oder? (nicht kontrolliert :wink:) Dann wäre es doch ein "weltliches" Problem. :gruebel:

Zitat:

Meine Idee basiert auf der Annahme, dass ein TAction.OnUpdate

...da ist TAction nicht im Spiel.

[Uwe Raabe]

Zitat:

Zitat von haentschman (Beitrag 1471380)

...nicht nur. Bei mir reicht auch ein beherztes Klicken auf "Einfügen" (Tastatur) und wieder zurück.

Guter Hinweis. Widerspricht aber immer noch nicht meiner Vermutung. Das Umschalten des Mode könnte natürlich auch dafür sorgen, daß die ToggleComment-Action wieder aktiv wird.

Zitat:

Zitat von haentschman (Beitrag 1471380)

...der Code der "Einfügen" Taste ist doch überall gleich? Oder? (nicht kontrolliert :wink:) Dann wäre es doch ein "weltliches" Problem. :gruebel:

Die Delphi-Hilfe nennt für die Kommentar-Umschalten Funktion lediglich das Strg-/. Da das auf einer Deutschen Tastatur aber nicht so leicht zu erreichen ist wie auf einer Englischen, gibt es alternativ noch das Ctrl-#.

Zitat:

Zitat von haentschman (Beitrag 1471380)

...da ist TAction nicht im Spiel.

Woher willst du das wissen? Ich bin mir sogar ziemlich sicher, daß das Kommentar-Umschalten über eine Action realisiert wird. Ich kann dir sogar sagen wie die heißt: ecToggleComment

[haentschman]

...war nur eine Vermutung. Kein Menü, nur Tastatur. :?

[einbeliebigername]

Hallo,

ich kann unter 10.1 bestätigen, dass das aufmachen und gleich wieder schließen des Kontextmenüs reicht, um Strg+# wieder Funktionsfähige zu bekommen.

Zitat:

Zitat von Uwe Raabe (Beitrag 1471360)

Zitat:

Zitat von himitsu (Beitrag 1471358)

Witzig ist aber, dass Strg+/ (Nummerblock) dagegen fast immer funktioniert und das Selbe macht.

Das ist der entsprechende Key-Code für das Englische Tastatur-Layout.

Das sehe ich anders, da die Funktionsweisen der beiden sich unterscheiden. Wenn nichts markiert ist, schalten beide die Kommentierung der Zeile unterm Cursor um. Bei Strg+# bleibt der Cursor in der Zeile und Strg+/[Zehnerblock] setzt den Cursor eine Zeile nach unten.

Ich glaube das Problem ist größer.

Ich wage zu behaupten, wenn das Problem einmal aufgetreten ist, dass dann alle Tastenkombinationen des Kontextmenüs Buggy sind. Auch Refactoring -> Umbenennen alias Umsch+Strg+E hat Probleme. In Unit A Rechtsklick -> Refactoring -> Umbenennen und im Dialog abbrechen drücken. Auf Unit B wechseln und Umsch+Strg+E drücken. Er will dann den Bezeichner, welcher zuletzt in Unit A unterm Cursor befand, umbenennen. Auch das lässt sich mit Öffnen und Schließen des Kontextmenüs erst mal wieder lösen. Aber im Gegensatz zu Strg+#, welches bei weiteren Unit-Wechseln erst mal wieder funktioniert, erholt sich Umsch+Strg+E nicht. Man muss dann nach jedem Unit-Wechsel erst einmal das Kontextmenü aufmachen, damit Umsch+Strg+E funktioniert.

[TurboMagic]

Zitat:

Zitat von haentschman (Beitrag 1471380)

Moin...:P

Zitat:

Meine Vermutung ist: Das reine Öffnen des Popup-Menüs genügt um die Funktionalität wiederherzustellen

...nicht nur. Bei mir reicht auch ein beherztes Klicken auf "Einfügen" (Tastatur) und wieder zurück. :wink:

Klicken auf Einfügen bedeutet was genau?

1. Drücken der Taste Einfg (EN: Ins)
2. Drücken der Tastenkombination Strg-V
3. Anklicken eines Einfügen Kontext/Menüpunktes mit der Maus (deiner Formulierung nach eher nicht)

Ich frage so dusselig um den QP report möglichst präzise ergänzen zu können, damit wir möglichst schnell möglichst
hohe Chancen auf einen fix haben.

Grüße
TurboMagic

[Uwe Raabe]

Zitat:

Zitat von einbeliebigername (Beitrag 1471383)

Das sehe ich anders, da die Funktionsweisen der beiden sich unterscheiden. Wenn nichts markiert ist, schalten beide die Kommentierung der Zeile unterm Cursor um. Bei Strg+# bleibt der Cursor in der Zeile und Strg+/[Zehnerblock] setzt den Cursor eine Zeile nach unten.

Gut erkannt :thumb:

Interessant ist auch: Wenn man das Englische Tastaturlayout verwendet, dann wirkt der entsprechende Menüpunkt genauso.

Zitat:

Zitat von einbeliebigername (Beitrag 1471383)

Ich wage zu behaupten, wenn das Problem einmal aufgetreten ist, dass dann alle Tastenkombinationen des Kontextmenüs Buggy sind. Auch Refactoring -> Umbenennen alias Umsch+Strg+E hat Probleme. In Unit A Rechtsklick -> Refactoring -> Umbenennen und im Dialog abbrechen drücken. Auf Unit B wechseln und Umsch+Strg+E drücken. Er will dann den Bezeichner, welcher zuletzt in Unit A unterm Cursor befand, umbenennen. Auch das lässt sich mit Öffnen und Schließen des Kontextmenüs erst mal wieder lösen. Aber im Gegensatz zu Strg+#, welches bei weiteren Unit-Wechseln erst mal wieder funktioniert, erholt sich Umsch+Strg+E nicht. Man muss dann nach jedem Unit-Wechsel erst einmal das Kontextmenü aufmachen, damit Umsch+Strg+E funktioniert.

Vielleicht könntest du das ale Ergänzung in den QP aufnehmen?

[haentschman]

Zitat:

Drücken der Taste Einfg (EN: Ins)

...genau diese. :wink:

[TurboMagic]

Zitat:

Zitat von einbeliebigername (Beitrag 1471383)

Hallo,

ich kann unter 10.1 bestätigen, dass das aufmachen und gleich wieder schließen des Kontextmenüs reicht, um Strg+# wieder Funktionsfähige zu bekommen.

Ich glaube das Problem ist größer.

Ich wage zu behaupten, wenn das Problem einmal aufgetreten ist, dass dann alle Tastenkombinationen des Kontextmenüs Buggy sind. Auch Refactoring -> Umbenennen alias Umsch+Strg+E hat Probleme. In Unit A Rechtsklick -> Refactoring -> Umbenennen und im Dialog abbrechen drücken. Auf Unit B wechseln und Umsch+Strg+E drücken. Er will dann den Bezeichner, welcher zuletzt in Unit A unterm Cursor befand, umbenennen. Auch das lässt sich mit Öffnen und Schließen des Kontextmenüs erst mal wieder lösen. Aber im Gegensatz zu Strg+#, welches bei weiteren Unit-Wechseln erst mal wieder funktioniert, erholt sich Umsch+Strg+E nicht. Man muss dann nach jedem Unit-Wechsel erst einmal das Kontextmenü aufmachen, damit Umsch+Strg+E funktioniert.

Hast du schon mal geschaut ob diese rename refactoring Probleme schon in QP (quality.embarcadero.com) erfasst sind?
Falls nicht bitte erfassen und die Report Nummer hier melden.
Einziges Problem bei allen diesen Problemstellungen: die treten sporadisch auf, was ein Reproduzieren erschwert.

[TurboMagic]

Zitat:

Zitat von haentschman (Beitrag 1471386)

Zitat:

Drücken der Taste Einfg (EN: Ins)

...genau diese. :wink:

Danke für die schnelle Rückmeldung!

[Uwe Raabe]

Also, ob Deutsches oder Englisches Delphi ist schon mal egal. Der Menüpunkt arbeitet immer gleich und hält den Cursor in der Zeile.

Schaltet man das Windows-Keyboard um auf Englisch, wird im Menü Ctrl-/ als Shortcut aufgeführt. Über die Tastatur setzt Ctrl-/ den Cursor in die folgende Zeile.

Mit einem Deutschen Layout wird im Menü Ctrl-# als Shortcut angezeigt (auch in einem Englischen Delphi). Interessanterweise funktioniert Ctrl-/ auch hier, was vermuten lässt, dass das in einem Key-Event abgehandelt wird - und deswegen dann immer funktioniert.

Wir forschen noch weiter...

[Benmik]

Wie schon erwartet: Trat eben prompt auf, einfacher Rechtsklick in den Editor (war noch nicht mal auf der Zeile) behob den Fehler!

[TurboMagic]

Danke für die Rückmeldung!

[Benmik]

... und eben wieder:

EINF - ob man 1x, 2x oder 3x drückt - bewirkt nichts, Rechtsklick behebt die Sache nach wie vor.

[Uwe Raabe]

Danke!

Wir konnten mit Hilfe eines engagierten Embarcadero-Mitarbeiters bisher Folgendes feststellen:

1. Der Befehl lässt sich bei US-Layout nur mit
   Delphi-Quellcode:

   Ctrl+/

   ausführen. Das wird dort auch im Menü als Shortcut angezeigt.
2. Das Verhalten unterscheidet sich dort: Die Tastenkombination rückt eine Zeile weiter, der Menübefehl nicht.
3. Mit German-Layout wird
   Delphi-Quellcode:

   Strg+#

   als ShortCut im Menü angezeigt.
4. Die Funktion lässt sowohl bei Tastendruck als auch beim Menü-Befehl die Zeile unverändert.
5. Auch im German-Layout funktioniert
   Delphi-Quellcode:

   Strg+/

   (NumPad), dies auch wie bei US mit Zeilenänderung.
6. Die Taste
   Delphi-Quellcode:

   /

   bzw.
   Delphi-Quellcode:

   ?

   im US-Layout entspricht dem virtuellen Key Code
   Delphi-Quellcode:

   VK_OEM_2

   .
7. Im German-Layout entspricht
   Delphi-Quellcode:

   VK_OEM_2

   der Taste
   Delphi-Quellcode:

   #

   bzw.
   Delphi-Quellcode:

   '

   .
8. Die Taste
   Delphi-Quellcode:

   /

   (DIV) im NumPad entspricht dem Code
   Delphi-Quellcode:

   VK_DIVIDE

   , sowohl im US- als auch im German-Layout.
9. Je nach in der IDE ausgewählter Tastaturbelegung wird
   Delphi-Quellcode:

   CTRL+/

   und
   Delphi-Quellcode:

   CTRL+DIV

   dort bereits abgefangen.
10. Dadurch wird im US-Layout der Menü-ShortCut nie erreicht und die haben somit auch nicht das Problem im Titel dieses Threads.

Es gibt also eigentlich zwei Ursachen:

a) Irgendetwas blockiert den

Delphi-Quellcode:

Strg+#

ShortCut des Menüs - vermutlich ein Disablen der Action, was beim Anzeigen des Menüs wieder neutralisiert wird.
b) Die ausgewählte Tastaturbelegung registriert nicht

Delphi-Quellcode:

CTRL+VK_OEM_2

, sondern versucht das über den Character

Delphi-Quellcode:

/

, was im German-Layout aber nicht klappt.

Würde die IDE also bei der Tastaturbelegung nicht ein

Delphi-Quellcode:

ShortCut(Ord('/'), [ssCtrl])

verwenden, sondern ein

Delphi-Quellcode:

ShortCut(VK_OEM_2, [ssCtrl])

wäre b) schon mal gelöst und damit das Problem auch nicht mehr existent.

Vermutlich ist a) aber auch verantwortlich für eine Reihe anderer Probleme.

[TurboMagic]

Zitat:

Zitat von Uwe Raabe (Beitrag 1471899)

Würde die IDE also bei der Tastaturbelegung nicht ein

Delphi-Quellcode:

ShortCut(Ord('/'), [ssCtrl])

verwenden, sondern ein

Delphi-Quellcode:

ShortCut(VK_OEM_2, [ssCtrl])

wäre b) schon mal gelöst und damit das Problem auch nicht mehr existent.

Vermutlich ist a) aber auch verantwortlich für eine Reihe anderer Probleme.

Das bedeutet doch aber, dass man zumindest das oberflächlich reparieren könnte.
Natürlich sollte man sich dann vermerken, dem Punkt a) mal nachzugehen, aber wenn
b) schon mal dafür funktioniert, warum das dann nicht einsetzen?

Wir deutschen Anwender wären dafür sicher sehr dankbar!

[Aviator]

Leider habe ich in der letzten Zeit nicht sonderlich viel mit der IDE gearbeitet. Folglich ist auch das CTRL+# Problem nicht aufgetreten. Was ich aber öfters hatte war, dass ich das Refactoring (also Umbenennen) CTRL+SHIFT+E nicht ausführen konnte. Ein simples Öffnen und Schließen des Kontextmenüs hat auch hier geholfen, dass der Shortcut wieder angenommen wurde. Ausführen musste ich den Befehl über das Kontextmenü nicht.

[Benmik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1471899)

Auch im German-Layout funktioniert

Delphi-Quellcode:

Strg+/

(NumPad), dies auch wie bei US mit Zeilenänderung.

Verdienstvoll!

Ich habe mich gefragt, wo denn

Delphi-Quellcode:

Strg+/

(NumPad) auf einer deutschen Tastatur zu finden ist. Die Angabe ist semantisch und nicht symbolisch gemeint, das Zeichen auf der Tastatur ist das

Delphi-Quellcode:

÷

.:idea:

[Delphi.Narium]

Bei mir gibt es keine Taste ÷ sondern nur die Taste mit dem /.

Kommt wohl auf den Tastatur- / Notebook- / ...-hersteller an.

Gemeint ist also die Taste mit dem Symbol für eine Division.

[Sherlock]

Das kommt dann wohl sehr auf den Tastaturhersteller an. Bei meinem (Apple) ist es sehr wohl das "/" auf dem Numblock.

Sherlock

[Uwe Raabe]

Zitat:

Zitat von Benmik (Beitrag 1471943)

das Zeichen auf der Tastatur ist das

Delphi-Quellcode:

÷

.

Ist offenbar wirklich vom Hersteller abhängig.

https://commons.wikimedia.org/wiki/C...ads?uselang=de

Nach dieser Sammlung ist das

Delphi-Quellcode:

÷

aber eher die Ausnahme.

[TiGü]

Auf meinen guten alten "Microsoft Natural Ergonomic Keyboard 4000 v1.0" ist das auch ein ÷ zwischen Num-Taste und ×-Taste.

[Benmik]

Echt! Wusste gar nicht, dass es andere gibt. Ich habe eine höchst einfache Cherry KC-1000.

[himitsu]

Was draufgedruckt ist, ist erstmal egal,
so lange diese Taste nicht einen anderen ScanCode rausgibt,
ist / und ÷ identisch.

Wie das dann im Treiber/System in den KeyCode, bzw. Char übersetzt wird, ist eine andere Angelegenheit und hängt von installierten KeyboardLayout (KeyMapper) und MIME ab.
Mit einem englischen Layout ist z.B. da unten, bei "Entf" ein Dezimalpunkt und kein Dezimalkomma.

[Benmik]

Ich bin jedenfalls total dankbar für diese einfache Lösung. Ich wusste nicht, dass dieser Befehl im Kontextmenü ist und habe es daher nie ausprobiert.

Um auf meine Frage zurückzukommen: Bei euch passiert das nicht, dass im Debugger die überwachten Ausdrücke ausgegraut und nicht mehr erreichbar sind?

[himitsu]

F7/F8, da sind die kurz (*1) aus, aber kann mich nicht erinnern, dass die nicht zurück kamen.

*1 wobei das Kurz manchmal echt lang ist.
Schlimm, wenn man zu schnell/oft F7/F8 gedrückt hat, dann bleibt bei mir manchmal der Debugger komplett hängen und reagiert garnicht mehr. Die IDE kann ich dann nur noch abschießen, weil sie beim Beenden dann auch hängen bleibt, egal was ich bei "Debugger läuft noch. Beenden oder Trennen?" auswähle.

[Benmik]

Das sieht so aus und nein, es kommt nicht zurück.

[himitsu]

Blick nach rechts.
Ich frag mich, ob die es irgendwann mal wieder hinbekommen "vernünftige" Standardwerte zu benutzen.

Es ist einfach nur krank, dass seit paar Jahren die DebugDCUs standardmäßig aktiv sind und man ständig in der RTL/VCL landet.

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1471973)

Es ist einfach nur krank, dass seit paar Jahren die DebugDCUs standardmäßig aktiv sind und man ständig in der RTL/VCL landet.

Das kann man so oder so sehen. ;-)

Interessant fände ich eher, wenn man zwar in den Systemunits debuggen könnte, die impliziten Stringumwandlungen davon aber ausnehmen könnte...

Aber das ist hier das falsche Thema.

[TiGü]

Zitat:

Zitat von himitsu (Beitrag 1471973)

Es ist einfach nur krank, dass seit paar Jahren die DebugDCUs standardmäßig aktiv sind und man ständig in der RTL/VCL landet.

Hm...ja ja, gewiss...weil man ja auch jeden Tag fünf neue, produktive Projekte anfängt! :roll:

Ich bin hingegen immer schwer genervt, wenn die Kollegen das Ausschalten und die DPROJ commiten, weil in 7 von 10 Fällen man nur über den vollständig debuggbaren Callstack zum Ziel kommt.