Trotz %CURSOR steht der Mauszeiger an der falschen Stelle

  • Ich hoffe, meine Anfrage passt auch unter diesen Oberbegriff:

    Mir ist schon seit einiger Zeit (ich glaube, seit Beginn von 9.x) aufgefallen, dass bei mir der Cursor nicht mehr an die Stelle springt, an der in der Vorlage %CURSOR steht, sondern an den Anfang der ersten Zeile. Und dort auch "festhängt" - ich muss erst POS1 oder STRG-POS1 drücken, damit er sich dort wegbewegen lässt.

    Meine Vorlage für neue Nachrichten oder Antworten lautet schon seit Urzeiten

    ------------------------------------------------------------------------------------------------------------------

    Hallo %TOFName!

    %CURSOR

    Viele Grüße

    %FromFName

    ------------------------------------------------------------------------------------------------------------------

    Dies alles zumindest bei HTML-Mails, sowohl unter der Version 9.x als auch 10.x in der Windows-x64-Version.

    Irgendwas scheint in dem "neuen" HTML-Teil noch nicht in Ordnung zu sein.

    TheBat! Pro 10.x (64 Bit) NAU • Win 11x64 Pro • keine PlugIns

  • sondern an den Anfang der ersten Zeile. Und dort auch "festhängt"

    Bei mir hängt der Mauszeiger im AN-Feld, selbst wenn der Empfänger bereits gesetzt ist. Ich kann dann allerdings ohne Probleme mit Tab oder Maus zum nächsten Feld springen. Das betrifft auch den Nur-Text-Editor, jedoch nur neue Nachrichten. Bei einer Antwort ist alles in Ordnung. Scheint zunächst so, also ob das Makro %CURSOR bei neuen Nachrichten ignoriert wird.

    Aber!

    Habe kurz getestet, wie das früher war. War früher bei einer neuen Nachricht das AN-Feld leer, blieb der Mauszeiger dort stehen. Insofern ist das Verhalten identisch. War das AN-Feld bereits gefüllt, blieb der Mauszeiger im Betreff stehen. Jetzt bleibt er trotzdem im AN-Feld stecken. War früher sowohl AN als auch Betreff voll, landete der Mauszeiger im Text-Feld an der richtigen Stelle. Und jetzt ebenfalls.

    Das bedeutet, dass auch früher erst, wenn bei einer neuen Nachricht die o.g. beiden Kopfzeilen gefüllt waren, z.B. durch Makros in der Vorlage, blieb der Mauszeiger an der richtigen %CURSOR-Stelle im Nachrichtentext stehen, sonst immer im Header.

    Stand bei dir im AN und Betreff schon etwas?

    Edit:

    Ich hab's von "Text-Macros" abgekoppelt, da ein anderes Problem.

  • Ja, ich fülle immer erst die Felder oben aus und springe mit der Tab-Taste von Feld zu Feld und schließlich in den Textbereich. Früher landete der Cursor dann an der Stelle, an der %CURSOR steht. Bei Antworten sind die Felder oben ja sowieso bereits ausgefüllt.

    Jedoch scheint es mir bei genauem Hinsehen, dass der Cursor erst an die richtige Position springt um dann blitzschnell, kaum wahrnehmbar, seine Position zu wechseln und oben links als erstes Zeichen zu landen.

    Dann geht es weiter: Ich kann den Cursor erst gar nicht (mit den Cursortasten) bewegen. Ich muss dazu entweder POS1 oder STRG-POS1 drücken und kann dann weitermachen. Und wenn ich die angeredete Person ändern will (zum Beispiel, weil oben eine Firma steht, ich aber den Sachbearbeiter direkt ansprechen will, dann habe ich normalerweise ab der entsprechenden Cursorposition STRG-SHIFT-Cursor rechts zum Markieren des Wortes gedrückt (wie in einer Textverarbeitung) und dann wieder ein Zeichen zurück, damit das Komma oder Ausrufezeichen nicht mit markiert wird und ich den Namen ersetzen kann. Wenn ich das jetzt mache, dann springt bei dieser Tastenfolge der Cursor eine Zeile tiefer, wobei der markierte Teil immer noch markiert bleibt. Musst Du mal ausprobieren, in der Beschreibung klingt es vielleicht ein wenig kompliziert. Einfach so, wie man es in einer Textverarbeitung machen würde, um ein Wort ohne das nachfolgende Satzzeichen zu markieren.

    TheBat! Pro 10.x (64 Bit) NAU • Win 11x64 Pro • keine PlugIns

  • und springe mit der Tab-Taste von Feld zu Feld

    OK. Ich dachte, es geht darum, den Mauszeiger unmittelbar nach dem Öffnen des Editors zu finden, ohne dass man eine einzige Taste geklickt hat. Man öffnet also den Editor - wo ist der Mauszeiger?

    Das habe ich oben getestet und das Verhalten ist fast wie früher. Wenn also die betreffenden Felder bereits beim Öffnen des Editors nicht leer sind, dann steht der Mauszeiger an der richtigen Stelle. Und das sowohl im Nur-Text- als auch HTML-Editor.

    Wenn aber die Felder leer sind, man sie nachträglich füllt und immer mit Tab jeweils zum nächsten Feld springt, dann landet der Mauszeiger bei mir ebenfalls an der richtigen Stelle im Nachrichtentext. Und ebenfalls sowohl im Nur-Text- als auch HTML-Editor.

    Getestet mit TB! v10.1 x64 NAU unter Windows 10 x64. Habe das jetzt extra auch mit deiner Vorlage getestet. Ich kann also dein Problem mit dem Hängenbleiben in der ersten Zeile nicht nachvollziehen.


    dann springt bei dieser Tastenfolge der Cursor eine Zeile tiefer, wobei der markierte Teil immer noch markiert bleibt.

    Das wiederum kann ich bestätigen und ich meine, dass es schon mal irgendwo (hier oder in TBBETA oder in BT oder an verschiedenen Orten) angesprochen wurde. Man muss nicht mal ein Zeichen zurückgehen, da der Mauszeiger sofort nach dem Markieren der Anrede nach unten springt. Betrifft aber nur den HTML-Editor. Im Nur-Text-Editor ist alles in Ordnung.

    Das muss jedenfalls ein Bug sein, denn die Markierung geht in wohl jedem Textverarbeitungsprogramm verloren, wenn man den Mauszeiger an eine andere Stelle bewegt.


    Edit:

    Habe jetzt etwas gefunden. Der Benutzer tombkk z.B. hat im BT bereits mindestens drei Einträge zum Thema "jumping cursor" verfasst. Einer davon:

    #0002125: Jumping cursor

    So wie es aussieht, tritt das Problem seit der Einführung des neuen HTML-Editors auf.

  • Wenn ich eine neue Mail öffne, dann erwartet der Editor ja bestimmte Eingaben und es es für mich nachvollziehbar, dass ich dann erst die Felder oben ausfüllen soll. Mit dem nächsten TAB sollte der Cursor aber an die richtige Position springen.

    Bei einer Antwort brauche ich keine weitere Taste drücken und der Cursor sollte sofort an der richtigen Eingabestelle zu finden sein. In beiden Fällen landet der Cursor aber bei mir an allererster Stelle vor der Anrede und oberhalb der %CURSOR-Position. Und dies seit der Umstellung auf den neuen HTML-Editor, also seit 9.x. Ich benutze gerade die 9.5.1, weil ich bei der 10.x nicht mit dem Einhandlesen (Leertaste) klar kam.

    Seltsam, dass das bei Dir anders ist. Ich wüsste nicht, was ich hier geändert haben sollte, das dieses Verhalten hervorrufen könnte. An den Vorlagen habe ich praktisch nie etwas geändert.

    Den Eintrag von tombk habe ich gefunden. Ich überlege, ob ich da noch etwas ergänze. Vorher will ich aber noch abchecken, ob es vielleicht an einer bestimmten Einstellung bei mir liegt.

    TheBat! Pro 10.x (64 Bit) NAU • Win 11x64 Pro • keine PlugIns

  • für mich nachvollziehbar, dass ich dann erst die Felder oben ausfüllen soll.

    So war das zumindest auch in den alten Programmversionen und ist daher wohl das Standardverhalten, selbst wenn das Makro %CURSOR woanders ist. Ohne AN und oft auch ohne Betreff wird die Nachricht ja nicht abgeschickt.

    Mit dem nächsten TAB sollte der Cursor aber an die richtige Position springen.

    Tut er bei mir. Sobald ich die Betreffzeile ausgefüllt habe und auf Tab klicke, springt der Mauszeiger zur Position des %CURSOR-Makros.

    Bei einer Antwort brauche ich keine weitere Taste drücken und der Cursor sollte sofort an der richtigen Eingabestelle zu finden sein.

    Bei einer Antwort hier dasselbe Verhalten wie in den alten Programmversionen. Der Mauszeiger landet dann sofort an der Position des %CURSOR-Makros.

    Ich wüsste nicht, was ich hier geändert haben sollte

    Soweit ich weiß, kann man den Mauszeiger außer mit dem o.g. Makro nicht beeinflussen.

    Ich überlege, ob ich da noch etwas ergänze.

    Ich meinerseits habe ihn bereits ergänzt. Für mich ist es ein Bug, denn das Verhalten soll eigentlich bereits physisch nicht möglich sein. Außerdem tritt es nicht auf, wenn man z.B. mit der Maus markiert oder von rechts nach links, also mit Strg+Shift+◄▬, oder nur das Wort ohne Komma. Es stimmt da also definitiv etwas nicht.

  • Ist daran etwas ungewöhnlich?

    Nein.

    Hast du es auch schon mit der Standard-Vorlage versucht? Vielleicht hast du in deiner irgendwo ein unsichtbares Zeichen o.ä. Und vielleicht solltest du das Forma der Vorlage auf HTML umstellen.

    Notfalls könntest du ACCOUNT.CFN löschen, aber dann müsstest du auch andere Kontoeigenschaften erneut anpassen.

  • Ich wollte Dich erst fragen, was denn genau die Standardvorlage ist und wo ich die (nach der Installation und Veränderung) herbekomme, aber dann habe ich den Menüpunkt "Standardvorlage wiederherstellen" unter den Vorlagen in den Kontoeigenschaften gefunden. Kann ich mal ausprobieren, obwohl ich glaube, dass ich da kaum etwas verändert hatte.

    HTML müsste aber doch bei mir dem Bild nach eingestellt sein, oder?

    TheBat! Pro 10.x (64 Bit) NAU • Win 11x64 Pro • keine PlugIns

  • Ich wollte Dich erst fragen, was denn genau die Standardvorlage ist

    Ich hab's nicht erwähnt, weil's eigentlich kaum zu übersehen ist. Eine Übersicht der Standardvorlagen findet man übrigens auch bei uns unter "Wiederherstellung der Standardvorlagen".

    HTML müsste aber doch bei mir dem Bild nach eingestellt sein, oder?

    Ja, wobei es bei mir auch mit dem Nur-Text-Format keine Probleme gibt. Aber, wie gesagt, ich hab's mit der letzten Programmversion getestet. Du nutzt doch noch v9.

    Wenn jedenfalls nichts hilft, dann musst du dich an Ritlabs wenden. Und ergänze mal bei Gelegenheit den o.g. BT-Eintrag, denn dort gilt - je mehr desto eventuell schneller.

  • Ich habe es jetzt extra nochmal mit der aktuellen 10.1.0 getestet und das Verhalten ist genau das selbe. Der Cursor springt zuerst an %CURSOR und saust dann blitzschnell, für das Auge kaum wahrnehmbar, an die erste Position links oben.


    Ich werde mich dann mal in einer ruhigen Minute hinsetzen und den BT-Eintrag ausführlich ergänzen.

    TheBat! Pro 10.x (64 Bit) NAU • Win 11x64 Pro • keine PlugIns

    Einmal editiert, zuletzt von Ralf Brinkmann (21. Juli 2022 um 19:15)