Text-Anzeige im html-Betrachter unscharf

  • Da ich noch aus diversen Gründen v8.5.2 nutze, heute aber die Rabatt-Aktion endet, bin ich mal sämtliche changelog-Einträge auf der Ritlabs-Webseite durchgegangen, um zu sehen, ob sich ggf. ein Upgrade doch lohnt (trotz hässlicherem GUI).

    Da waren ja doch einige TLS-Updates, v.a. noch in v8 und v9, die irgendwann eventuell mal relevant werden könnten in dem Sinne, daß Email-Anbieter sie zur Voraussetzung machen (wie es ja in diesem Jahr mit TLS 1.2 u.a. bei der Strato-Familie der Fall war).

    Daher habe ich wieder mal v10 getestet, um zu sehen, ob ich damit arbeiten könnte.

    Leider mußte ich feststellen, daß der html-Betrachter für die Email-Anzeige relative unscharfe Schriften anzeigt, sowohl unter wine als auch unter Windows (7, VM), wenn auch in unterschiedlicher Weise. Unter Windows ist Cleartype deaktiviert, welches aber auf die Textanzeige im html-Betrachter sowieso keinen Einfluß zu haben scheint, wie Wechseln zwischen Aktivierung und Deaktivierung zeigt.

    Unter wine kommt noch hinzu, daß die Anzeige Sekunden braucht, z.B. beim Wechsel von einer Email zu einer anderen. Da kann dann zwar TB nichts dafür, ist aber für mich dann doch ein Punkt auf der Negativ-Liste was einen möglichen Wechsel anbelangt.

    Aber die unscharfe Textanzeige (im Vergleich zum (alten) html-Betrachter von v8 und zur nur-Text-Anzeige) ist schon ein Grund, nicht zu wechseln. Es sei denn, es gibt eine Möglichkeit, das abzustellen. Immerhin kann ich mir nicht vorstellen, daß andere Nutzer eine solche Textanzeige tolerieren würden.

    Allerdings konnte ich auch keine "Beschwerden" in Form von Foreneinträgen bzw. Einträgen im bugtracker finden, was mir dann auch wieder komisch vorkommt.

    Daher wäre ich für Tips oder Hinweise was eine unscharfe Textanzeige im html-Betrachter anbelangt dankbar.

  • tb-user 28. November 2022 um 13:17

    Hat den Titel des Themas von „Email-Ansicht mit html-Betrachter unscharf“ zu „Text-Anzeige im html-Betrachter unscharf“ geändert.
  • Da waren ja doch einige TLS-Updates

    Hinzu kommt, dass v8 nicht mehr mit Mailanbietern nutzbar ist, die teils zwangsweise auf OAuth 2.0 setzen, wie z.B. GMail. Dafür braucht man mindestens v9.4/v9.5. Dort wurde nämlich das integrierte Tokenerstellungsverfahren aktualisiert.

    sowohl unter wine als auch unter Windows (7, VM)

    Unter Windows 10 konnte bisher nichts Derartiges beobachtet werden. Die Emulatoren und VMs könnten zumindest mitschuldig sein. Es empfiehlt sich daher, das nach Möglichkeit direkt zu testen.

    Zu wine kann dir vielleicht sotel etwas mitteilen. Unter "The Bat!@wine - Ein aktueller Bericht" verfasst er regelmäßig Erfahrungsberichte.

  • bei der Strato-Familie der Fall war

    Da du United Internet erwähnst, muss man noch anmerken, dass es im Januar damit plötzlich Verbindungsprobleme gab, die erst in v9.5.1 beseitigt wurden. Offensichtlich wurde auf den Mailservern etwas umgestellt, was auch Ritlabs erstaunt hat, weil es wohl unüblich war. Jedenfalls haben sie extra diesen Hotfix in Form von v9.5.1 erstellt, obwohl schon längst an v10 gearbeitet wurde.

    Es kann sein, dass das, was damals auf den Servern umgestellt wurde, später wieder rückgängig gemacht wurde, so dass jetzt auch wieder die alten Versionen damit funktionieren oder zumindest v8, aber es heißt nicht, dass das oder Ähnliches nicht wieder und plötzlich geschehen könnte. Für ältere Versionen wird es aber keine Updates mehr geben.

    heute aber die Rabatt-Aktion endet

    In einem Monat wird es sicherlich wieder Rabatt geben, jedoch kann es sehr wohl sein, dass es keine 40% sein werden. Letztes Jahr waren es IMO nur 25%. Aber man weiß ja nie...

  • Vielen Dank für die Rückmeldungen.

    Da ich "glücklicherweise" alle Mailanbieter, die (laut Ritlabs changelogs) auf OAuth setzen aus anderen Gründen gar nicht erst nutze, ist das jetzt mal kein Upgrade-Grund für mich.

    Die Probleme mit UI im Januar sind mir nicht mehr im Detail in Erinnerung, daher kann ich nicht sagen, ob mein TB davon betroffen war oder nur ein anderes Programm, das ich zur Spam-Entfernung verwende.

    Leider haben sich heute bei meinen Alternativen-Tests (Claws Mail, Mail-Funktion in Vivaldi) herausgestellt, daß sie bei genauerer Betrachtung nicht als Alternative taugen...

    Andere Clients hatte ich schon im Vorfeld vor Wochen mal ausgeschlossen. Die Vivaldi-"Idee" kam mir erst heute in den Sinn. Und auch gleich wieder verworfen, da man keine Emails importieren (oder exportieren) kann.

    Zur Not besorge ich mir halt eine v10-Lizenz und steige um, wenn v8 nicht mehr mag (oder darf)... :)

  • Die Probleme mit UI im Januar sind mir nicht mehr im Detail in Erinnerung

    Den Thread dazu findet man unter "BYE out-of-sync data before server greeting". Du hast dort übrigens auch gepostet. Das Problem hatte jeder TB!-Nutzer, da GMX & Co. plötzlich nicht mehr über TLS funktionierten. StartTLS ging noch.

    wenn v8 nicht mehr mag

    Wenn du bei der v8 bleibst, dann aktualisiere sie wenigstens auf die letzte v8.8.9, die auf der offiziellen Webseite noch vorhanden ist.

  • Wenn du bei der v8 bleibst, dann aktualisiere sie wenigstens auf die letzte v8.8.9, die auf der offiziellen Webseite noch vorhanden ist.

    V8.5.4 ist die letzte tolerierbare Version für mich, da danach Strg+S nicht mehr funktioniert. Sie wollten es nicht mehr reparieren (der Fehler war vorher schon mal eingeschleust und später wieder behoben worden). Ich tippe auf schlechten Code, den sie für neue Funktionen brauchten und ihnen nur die Wahl zwischen den neuen Funktionen oder der Behebung des Fehlers gelassen hat. Jedenfalls wurde die Fehlermeldung nach mehrmaligen Nachhaken dann auf "won't be fixed" gesetzt.

    Den Thread dazu findet man unter "BYE out-of-sync data before server greeting". Du hast dort übrigens auch gepostet. Das Problem hatte jeder TB!-Nutzer, da GMX & Co. plötzlich nicht mehr über TLS funktionierten. StartTLS ging noch.

    Danke für die Erinnerung! :)

    Der Ritlabs-Support meint, daß eine (1) weitere Meldung dieser Art vorliegt (CEF-basierter Viewer ignoriert ClearType-Einstellung). Da bezweifle ich mal stark, daß Ritlabs daran etwas ändern kann.

    Im Übrigen bin ich der "VM vs nativ"-Vermutung mal nachgegangen. Für mich wenig überraschend gibt es keinen Unterschied zwischen W7 VM und W7 nativ. Wohl aber zwischen W7 und W10 (VM, habe ich nie nativ installiert). Auf W10 ist es weniger "schlimm".

    Das die leichte Unschärfe (im Vergleich zu nur-text) nicht jeden stört ist in sofern nicht unbedingt überraschend, da es ja auch Nutzer gibt, die ClearType nutzen... Und dann fällt es vermutlich gar nicht auf bzw. gibt es ggf. keinen Unterschied.

    Ich kann ja mal eine v10-Lizenz nehmen für den Fall, daß v8 irgendwann nicht mehr kompatibel mit den Anforderungen meiner Email-Anbieter ist. Und vielleicht finde ich noch eine Möglichkeit, die Darstellungsprobleme unter wine zu reduzieren (z.B. eine weniger "empfindliche" Schriftart), so daß ich v10 schon vorher nutzen möchte.... :)

  • V8.5.4 ist die letzte tolerierbare Version für mich, da danach Strg+S nicht mehr funktioniert.

    Strg+S für was, Nachricht speichern? Man kann ja seit langem die Shortcuts selbst vergeben und ändern.

    Nachricht speichern klappt hier jedenfalls über diese Tastenkombi in v8.8.9 64bit problemlos.

    Ich kann ja mal eine v10-Lizenz nehmen für den Fall...

    Die Erfahrungen bisher zeigen, dass Ritlabs nur einmal im Jahr die 40% anbietet und zwar zum Cyber-Weekend. Wenn du also viel sparen willst, solltest du wahrscheinlich jetzt zugreifen, denn sonst wirst du bis zum nächsten Black Friday warten müssen. Vielleicht kommt aber auch schon v11 im nächsten Jahr. MS haben ja auch zuerst behauptet, dass Version 10 die letzte sein wird. ;)

  • Strg+S für was, Nachricht speichern? Man kann ja seit langem die Shortcuts selbst vergeben und ändern.


    Nachricht speichern klappt hier jedenfalls über diese Tastenkombi in v8.8.9 64bit problemlos.

    Mhhh. Hatte ich vorhin extra noch einmal getestet. Wenn ich damit speichere und dann die Nachricht schließen will, fragt er nach, ob ich speichern will.

    Vielleicht hätte ich es anders formulieren sollen: Strg+S funktioniert zwar zum Speichern, er fragt aber trotzdem noch einmal nach Speichern, wenn man das Editor-Fenster schließen möchte.

    Nun habe ich noch einmal getestet: Noch genauer müßte es heißen: Der Fehler tritt auf, wenn man in den Nachricht-Teil etwas schreibt. Wenn man nur eine Email-Adresse und / oder den Betreff ausfüllt / ändert (und dann per Strg+S speichert), fragt er beim Schließen nicht nach.

    Vielleicht kommt aber auch schon v11 im nächsten Jahr.

    Ich hoffe mal, es dauert wieder 2 Jahre+ bis zur nächsten Hauptversion... :)

  • Vielleicht hätte ich es anders formulieren sollen

    OK. Ich dachte, dass es ums Speichern bzw. Exportieren von bereits empfangenen Nachrichten geht, denn es funktioniert ja ebenfalls über Strg+S. Dir geht's aber ums Speichern als Entwurf der selbst erstellten Nachrichten.

    Der Fehler wurde jedenfalls noch in v9.3.3.6 (s. Changelog dort) behoben und tritt natürlich auch in v10 nicht mehr auf. Jetzt wird nur nachgefragt, wenn tatsächlich noch nicht gespeichert wurde.

  • Auf der Ritlab-Webseite sind die changelogs ja etwas lückenhaft, weil nicht jede (Zwischen-) Version aufgeführt ist.

    Ich bin trotzdem nach diesen gegangen:

    The Bat! v9.4

    New features

    • New HTML Editor

    Von daher meine Meinung, daß der Fehler (im ursprünglichen Editor) nie behoben wurde, da ein neuer Editor implementiert wurde (in dem der Fehler ggf. gar nicht aufgetreten ist, aber das dann als "Fehler behoben" verkauft wurde).

    In den Fehlermeldungen (1366) ist vermerkt, daß der Fehler erstmals in ~v8.0.14.2 (2017) aufgetreten ist und in v8.0.14.3 behoben wurde - oder auch erst in v8.2.8.5. Beide Versionen werden im selben Vorgang angegeben.

    Dann ist der Fehler (1538) wieder in ~v8.5.8.3 (2018) aufgetreten und angeblich in v9.3.3.4 (2021) behoben worden. Letztere Version taucht nicht einmal in der Beta-Mailgruppe auf. Vielleicht ist es nur eine interne Version - oder ein Tippfehler (statt 9.3.3.2 oder 9.3.3.6).

    Jedenfalls wollte ich nicht nur wegen dieses Fehlers eine neue Version kaufen müssen - zumal er ja schon mal behoben worden war.

    Hier noch ein Hinweis darauf, daß der Editor neu aufgesetzt wurde und der Fehler im ursprünglichen Editor (MicroEd) nie behoben wurde:

    Where is MicroEd? (The Bat 9.4.1)
    Zitat

    - Where is MicroEd? (The Bat 9.4.1)

    - It is gone.

    Leider kann man die alten Versionen kaum noch herunterladen - und ich behalte auch nicht jede Version. Ich würde meine Behauptungen gerne testen können... :) (s.u.)

    Hier eine Bestätigung, daß in v9.3.3.6 ein neuer Editor implementiert ist:

    Zitat

    Zitat von Stefan Tanurkov via TBBETA

    While we are working on new HTML editor, we've prepared an update to the official release with recent changes to other parts. So, version 9.3.4 is very much like to 9.3.3.6, but without new HTML editor.


    Nun habe ich doch noch v9.3.4 gefunden. Die ist perfekt: Hat nicht den neuen Editor, der in der Testversion v9.3.3.6 implementiert ist und in der der Fehler wohl nicht auftritt.

    In v9.3.4 tritt er aber auf. D.h. wie vermutet wurde der Fehler im MicroEd nicht behoben.

    Allerdings müßte ich noch z.B. v9.3.3.2 testen (die erste Version mit dem neuen Editor, aber angeblich noch mit dem Fehler), um meine Vermutung belegen zu können, daß der Fehler im neuen Editor gar nicht aufgetreten ist.

    Ein Hinweis darauf, warum der Fehler für den neuen Editor als "behoben" aufgeführt sein könnte.

    Re: 9.3.3.3 - tracking issues in BT
    Zitat

    an idea for the bugtracker: To make tracking issues clearer, can we have a new category for New HTML editor?

    Or better: close all bugs for the current category "HTML-Editor" since the old editor is gone in 9.3.3.3 and its bugs went along with it.

    Same for the bugs of category "Windows Editor".

    Die Fehlermeldungen für alten und neuen Editor landeten in der selben Kategorie, so daß man Fehler, die im neuen nicht auftreten ggf. einfach auf "behoben" gesetzt hat, um etwas aufzuräumen und nur noch Fehler die den neuen Editor betreffen "offen" zu haben.

    Es ist halt auch eine Frage, ob und wie viel Code sie vom alten in den neuen Editor übernommen haben.


    Aber das ist alles sowieso nur Theorie und zum Spaß, weil v10 ja aktuell ist und diese nie etwas anderes als den neuen Editor hatte.

  • Auf der Ritlab-Webseite sind die changelogs ja etwas lückenhaft, weil nicht jede (Zwischen-) Version aufgeführt ist.

    Jeder Installationsdatei ist README.TXT mit einem Changelog beigefügt. Darin ist eventuell mehr enthalten. Allerdings beziehen sich die Changelogs darin sowie auf der offiziellen Webseite nur auf die finalen Versionen, weil ja nur solche dort veröffentlicht werden. Wir posten hier hingegen alle Versionen, inkl. Alphas, Betas und RCs, die je der Öffentlichkeit z.B. über die TBBETA-Mailingliste zugänglich gemacht wurden. Und dann natürlich auch mit entsprechenden Changelogs, soweit sie ebenfalls veröffentlicht wurden. Es lohnt sich also entweder öfters bei uns in "The Bat! - Beta" reinzuschauen oder die o.g. Mailingliste zu abonnieren, wenn man immer auf dem Laufenden sein möchte.

    Von daher meine Meinung, daß der Fehler (im ursprünglichen Editor) nie behoben wurde, da ein neuer Editor implementiert wurde (in dem der Fehler ggf. gar nicht aufgetreten ist, aber das dann als "Fehler behoben" verkauft wurde).

    Wenn du immer noch von dem Strg+S Fehler redest, so ist er doch unabhängig von Editor, weil er sowohl im HTML- als auch im Nur-Text-Editor auftrat. Die Implementierung des neuen und auf CEF basierenden HTML-Editors hat also damit nichts zu tun.

    Außerdem wurde der neue HTML-Editor noch in der v9.3.3.2 Alpha implementiert. Der Fehler wurde aber erst in v9.3.3.6 Alpha (endgültig) behoben. Damit bestand er zunächst auch im neuen HTML-Editor.

    Hier noch ein Hinweis darauf, daß der Editor neu aufgesetzt wurde und der Fehler im ursprünglichen Editor (MicroEd) nie behoben wurde:

    Da liegt wohl ein Missverständnis vor, denn nicht MicroEd, sondern der Windows Editor wurde entfernt. Außerdem sind das Nur-Text-Editoren und haben also nichts mit dem HTML-Editor zu tun.

    Man hatte ja früher zwei Nur-Text-Editoren - MicroEd und Windows Editor. Den Windows Editor hatte man eigentlich nur deshalb, weil er im Gegensatz zu MicroEd den sog. Soft Wrap (weicher Zeilenumbruch) unterstützte. Am Ende des Bildschirms wurde der Text also automatisch umgebrochen, während man bei MicroEd immer das Ende der Zeile für den Umbruch angeben musste, sonst wurde über den Bildschirmrand hinaus geschrieben und man immer hin und her horizontal scrollen musste.

    Nachdem man den Soft Wrap auch in MicroEd integriert hat, hat man den Windows Editor mangels Bedarfs entfernt, weil MicroEd im Übrigen all das kann, was der Windows Editor konnte. Man hat also den Nur-Text-Editor nicht ersetzt oder einen neuen eingebaut, sondern einfach einen von beiden alten entfernt.

    Das belegt ebenfalls, dass der o.g. Fehler nicht am Editor hängt.

    Leider kann man die alten Versionen kaum noch herunterladen

    Das wird dir aber nichts nützen, denn der genannte Fehler wurde ja erst in v9 endgültig beseitigt und für v9 kriegt man keine Lizenz mehr. Selbst in der allerletzten Alpha v8.8.9.12 ist er noch vorhanden. Entscheidend ist daher vielmehr, dass in der aktuellen v10 alles insoweit in Ordnung ist.

    Und seit v10.2 hat man jetzt auch den alten HTML-Editor als Alternative wieder. Damit hat man jetzt den alten Nur-Text-Editor (MicroEd) und auch den alten HTML-Editor (RichText Editor). Du hättest mal die neuste Version zumindest antesten sollen.

    ...weil v10 ja aktuell ist und diese nie etwas anderes als den neuen Editor hatte.

    Falsch, s.o.

    Windows (7, VM)

    Eine Gegenfrage. Welche Bildschirmauflösung hast du in der VM?

    In der letzten Programmversion hat man nämlich das Fenstrer mit den Programmeinstellungen vergrößert und bei mir passt es nicht mehr auf den Bildschirm der VM.

  • Außerdem wurde der neue HTML-Editor noch in der v9.3.3.2 Alpha implementiert. Der Fehler wurde aber erst in v9.3.3.6 Alpha (endgültig) behoben. Damit bestand er zunächst auch im neuen HTML-Editor.

    Wie schon geschrieben:

    Nun habe ich doch noch v9.3.4 gefunden. Die ist perfekt: Hat nicht den neuen Editor, der in der Testversion v9.3.3.6 implementiert ist und in der der Fehler wohl nicht auftritt.

    In v9.3.4 tritt er aber auf. D.h. wie vermutet wurde der Fehler im MicroEd nicht behoben.


    Allerdings müßte ich noch z.B. v9.3.3.2 testen (die erste Version mit dem neuen Editor, aber angeblich noch mit dem Fehler), um meine Vermutung belegen zu können, daß der Fehler im neuen Editor gar nicht aufgetreten ist.

    Zur Verdeutlichung:

    v9.3.3.2: Fehler angeblich vorhanden, mit neuem html Editor (s.u. zu Fehlermeldung 1639) <---- Diese Version hätte ich gerne zum Testen.

    v9.3.3.6: Fehler angeblich behoben, mit neuem html Editor

    v9.3.4: Wie 9.3.3.6, aber ohne neuen html Editor <----- In dieser Version sollte deiner Theorie nach der Fehler nicht mehr auftauchen. Der Fehler ist aber noch vorhanden.

    Es gibt eine Möglichkeit, die den Fehler "an den alten html Editor bindet" ohne in ihm selbst zu sein: Der Fehler konnte im "übergeordneten Editor" (den ich deiner Beschreibung entnehme) nicht behoben werden, weil der untergeordnete, alte html Editor das nicht zugelassen hat. Das würde ebenso erklären, warum der Fehler nach der ersten Behebung in v8 kurz darauf wieder eingeführt und danach (in v8, und nach meiner Theorie auch in v9 im / mit dem alten html Editor) nie behoben wurde, weil er nicht behoben werden konnte, weil sonst etwas anderes nicht mehr funktioniert hätte. Andernfalls wäre es ein leichtes gewesen, das Vorgehen bei der ersten Fehlerbehebung einfach noch einmal zu wiederholen. Einen Fehler zu finden, der schon einmal aufgetreten ist und der behoben wurde sollte wohl deutlich einfacher sein, als einen neuen, bisher nie aufgetretenen zu finden (d.h. seine Ursache im Code) und beheben.


    Daher auch:

    Zitat

    Leider kann man die alten Versionen kaum noch herunterladen

    ... alles im Kontext von v9, d.h. um die Versionen herum, in denen der Fehler noch vorhanden oder nicht mehr vorhanden sein sollte.

    Von daher würde es mir natürlich etwas nützen (da von v8 in diesem Zusammenhang ("alte Versionen herunterladen") nie die Rede war)...


    Und seit v10.2 hat man jetzt auch den alten HTML-Editor als Alternative wieder. Damit hat man jetzt den alten Nur-Text-Editor (MicroEd) und auch den alten HTML-Editor (RichText Editor).

    Das changelog auf der Webseite besagt dazu:

    New features

    • RichText editor as a simpler to use HTML editor

    Ich entnehme dem nicht, daß es sich dabei um den (- unveränderten - Code des) alten html Editor(s) handelt.


    Zitat

    Du hättest mal die neuste Version zumindest antesten sollen.

    Zu welchem Zweck genau?

    Generell angetestet habe ich sie ja. Nur nichts gespeichert, um nicht meine Datenbank(en) ggf. für v8 unlesbar zu machen. Ein Duplizieren der Datenbank war mir für die jeweils rel. kurzen Tests (bei denen ich auf andere Dinge geachtet habe, da der Fehler ja seit v9.3.3.6 angeblich nicht mehr auftritt) zu aufwändig.

    Der Fehler ist ja in v10 nie aufgetreten. Wobei: Wenn es schon in v8 und v9 "niemandem" aufgefallen ist, wäre es auch in v10 "niemandem" aufgefallen, wenn er vorhanden gewesen wäre. Jedenfalls habe ich außer den beiden erwähnten Fehlermeldungen keine weiteren gefunden.

    Bis auf 1639, die aber quasi eine neu eingetragene Kopie der 1366 ist, nur unter "HTML editor" einsortiert statt unter "MicroEd text editor".

    Interessanterweise steht dort als Bemerkung:

    Zitat

    Irrelevant since v9.3.3.3 with the new HTML editor.

    Wobei die Einträge in den Fehlermeldungen jetzt auch nicht die absolute Wahrheit darstellen müssen.

    Aber diese Bemerkung (auch wenn hier von v9.3.3.3 die Rede ist, laut Beta-Mailgruppe der neue html Editor aber in v9.3.3.2 eingeführt wurde) würde ja dafür sprechen, daß die angebliche "Behebung" des Fehlers in v9.3.3.6 nicht durch tatsächliche Fehleranalyse und Codeänderung zustande kam, sondern automatisch (und "zufällig") lediglich durch Umstellen auf einen neuen html Editor.

    Man kann Hinweise für beide Theorien finden und wird ja nach persönlicher Tendenz diejenigen für die nicht-bevorzugte Theorie eher ignorieren.

    Deshalb: Die v9.3.3.2 wäre ein optimales Testsubjekt, weil sie angeblich den Fehler noch enthält, aber schon den neuen Editor mitbringt. (s.o.)

    Leider ist es aber keine finale Version, weshalb sie außerhalb der Ritlabs-Server noch unwahrscheinlicher aufzufinden sein wird als finale Versionen, die auch nicht mehr für jede Version (so einfach) zu finden sind. Und Ritlabs löscht "sogar" veraltete finale Versionen, so daß auch Mitarbeiter keine Kopie mehr auftreiben können. Da wird es bei einer alpha/beta Version leider noch weniger wahrscheinlich sein. :(

    Die v9.3.4 habe ich ja bereits getestet. Die hat noch den Fehler, von dem man zwar annehmen sollte, daß er, wenn er nichts mit dem html Editor zu tun hat, in dieser Version behoben sein sollte, aber diese Version könnte auch von einer Version vor v9.3.3.6 (in der der Fehler angeblich behoben wurde) abstammen. Solange ich das nicht ausschließen kann (auch wenn es in der Beta-Gruppe heißt "So, version 9.3.4 is very much like to 9.3.3.6, but without new HTML editor."), kann v9.3.4 keinen abschließenden Beweis für meine Theorie erbringen. v9.3.3.2 könnte das sehr wahrscheinlich schon (für oder gegen meine Theorie).


    Wie auch immer.


    Eine Gegenfrage. Welche Bildschirmauflösung hast du in der VM?

    Die gleiche wie auf dem nativen System.

  • Es liegt daran, dass v9.3.4 Final unmittelbarer Nachfolger von v9.3.3 Final ist. Alle Editor-Änderungen aus den dazwischen liegenden Alphas/Betas sind nicht enthalten, daher auch der Fix aus v9.3.3.6. Das wurde erst in v9.4 Final gemacht und seitdem tritt der Fehler nicht mehr auf. Und das ist doch das Wichtigste, weil du für v9 keine Lizenz mehr erwerben kannst und die v10 Lizenz dafür auch nicht gültig ist. Von welcher Bedeutung ist es also heutzutage noch, ob es in irgendeiner v9 funktionierte oder nicht? Richtig, von gar keiner.

    Du konzentrierst dich außerdem ausschließlich nur auf den HTML-Editor und ignorierst dabei völlig die Tatsache, die ich bereits erwähnt habe, dass der alte Nur-Text-Editor MicroEd die ganzen Versionen über geblieben ist. Der Fehler trat aber früher auch in ihm auf, jetzt aber nicht mehr. Liegt es deiner Meinung nach auch am neuen HTML-Editor? Bestimmt nicht.

    Der Windows Editor war auch die ganze Zeit bis zur Entfernung unverändert und der Fehler trat in ihm bis zu irgendeiner v8 nicht auf. Dann aber plötzlich doch. Ritlabs haben einfach einen zusätzlichen Schutz in Form einer Nachfrage eingebaut, die aber plötzlich nicht mehr richtig funktionierte und daher immer erschien, wenn man auf Esc klickte. Mit Editoren hat es nichts zu tun, sondern ist vielmehr ein Fall von Benutzereinstellungen ▬► Weitere Einstellungen ▬► Bestätigungen, also lediglich ein Warnhinweis.

    Entscheidend ist, dass es in v10 richtig funktioniert. Ende!