Die Runde vom 07.09.2026 hat neben den zwei echten Fehlern eine Reihe
Wiederholungen und stumme Stellen gemeldet. Abgearbeitet in Etappen, jede fuer
sich pruefbar - nach jeder liefen beide Pruefketten gruen.
* Menueleiste: der Wechsel von einem Titel zum anderen brauchte ZWEI Klicks.
Der grab_set der offenen Liste schluckt den ersten, die <Button-1>-Bindung
des Titels feuert gar nicht. Das native tk.Menu, das diese Leiste ersetzt
hat, wechselte schon beim blossen Ueberfahren - zwei Klicks waren also eine
Verschlechterung gegenueber dem, was vorher da war. Die Klappliste wird
ausserdem jetzt wie jede andere Position ueber theme.auf_bildschirm()
begrenzt; am unteren Fensterrand lief sie vorher hinaus.
Neu: pruef_menueleiste.py misst beides ueber echte Klickereignisse.
* %LOCALAPPDATA%/ravokk wurde an drei Stellen einzeln ausgerechnet. Jetzt
fragen alle gemeinsam.standard_ordner(). Laufen die je auseinander, fuehren
die beiden Programme zwei Nummernbuecher - und das faellt erst auf, wenn
eine Rechnungsnummer zum zweiten Mal vergeben ist (§ 14 Abs. 4 Nr. 4 UStG).
* pruefe() stand 35-mal im Quelltext, in sechs Fassungen -> pruefhelfer.py.
Die zwei Ausreisser sind mitgezogen: pruef_bilder.py schrieb ein eigenes
Format, pruef_storno_verrechnet.py zaehlte in einer Zahl und konnte am Ende
nicht sagen, WAS fehlschlug.
* dlg_darstellung() und die drei Handgriffe des Umschaltens standen in beiden
app.py fast wortgleich -> ThemeMixin in theme.py. Beide trugen inzwischen
denselben langen Kommentar zu demselben Fehler; das war der Beweis, dass es
eine Sache ist. Programmspezifisch bleiben der Hinweistext im Dialog (R31)
und die Frage, ob die Einstellungen ausdruecklich gespeichert werden muessen.
* pruef_gemeinsam_automatisch.py sagte im Text "genau ein Buch" und prueft
">= 1" mit einem any() - eine Pruefung, die nicht rot werden kann. Jetzt
== 1, und der Dateiname wird mitgeprueft.
Dazu neu: die neun Dateien, die im Kopf zusagen, sie laegen in beiden
Programmen gleich, werden byteweise verglichen. Bei hinweis.py stimmte die
Zusage seit dem 06.09. nicht mehr - gleicher Inhalt, CRLF gegen LF.
* .gitattributes, damit die Zeilenenden nicht von der Maschine abhaengen.
Ohne das meldet genau diese Pruefung nach einem frischen Checkout einen
Unterschied, den es im Repository gar nicht gibt.
* Sechs stumme "except OSError" sagen jetzt, warum sie schweigen duerfen, und
einer meldet statt zu schweigen: schlaegt die Uebernahme einer alten
config.json fehl, faengt das Programm ohne Firmendaten, Katalog und Zaehler
neu an - und der Erfolgsfall schrieb eine Zeile, der Fehlerfall nicht. Die
24 stummen tk.TclError bleiben: dort wird ein Widget angefasst, das gerade
zerstoert wurde, und eine Meldung waere Rauschen.
* Tote Parameter und Variablen aus dem Umbau des Vortags: symbol_setzen(dunkel=),
kachel(grund=, radius=), mit_trennlinie, sechs x/y-Berechnungen, die von
theme.mittig() sofort ueberschrieben wurden, vier lokale "import ctypes".
39 Pruefstaende, 0 rot.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V4t48uxDok5rJXhC9bX1Ax
Sein Befund
"die namen und datums bloecke koennen schmaler werden sind zu breit und
verdrengen die posten block"
Gemessen stimmte das genau: die sieben Spalten der Leistungstabelle
brauchten 743 Pixel, sichtbar waren 618 - "E.-Preis" und "Gesamt" standen
ausserhalb des Bildes.
Wo die Breite wirklich herkam
An den Feldbreiten zu drehen half NICHTS. Die Arbeitsflaeche verteilte
ueber eine uniform-Gruppe streng im Verhaeltnis 4:3; die Formularspalte war
so breit, weil das Gewicht es vorschrieb, nicht weil der Inhalt es
brauchte - 433 Pixel, ob die Felder nun 38 oder 22 Zeichen breit waren.
Jetzt bekommt die Formularseite eine feste Mindestbreite und kein Gewicht,
die Liste allen uebrigen Platz. Wird das Fenster groesser, waechst allein
die Tabelle - genau dort nuetzt Breite, waehrend ein 600 Pixel breites Feld
fuer eine Postleitzahl nichts besser macht. 433 -> 329.
Dazu passend
- Startbreite 1060 -> 1180 und Mindestbreite 900 -> 1080. Unterhalb von
1080 passen die sieben Spalten selbst dann nicht nebeneinander, wenn die
Textspalte auf ihrer Mindestbreite steht.
- Die Eingabefelder links auf das Mass gekuerzt, das sie wirklich brauchen
(22 statt 38 Zeichen; Datum 12 statt 18). Das senkt die Mindestbreite der
Formularseite - erst dadurch ist sie so klein moeglich.
- "Anreise (TT.MM.JJJJ)" -> "Anreise". Die Form steht jetzt einmal als
graue Zeile unter dem Block. Als Platzhalter IM Feld waere sie
gefaehrlich: ein nicht geloeschter Platzhalter stuende als Anreisedatum
auf der Rechnung.
- Der Textumbruch der Leistungsspalte folgt jetzt ihrer echten Breite. Fest
eingetragen schnitt er den Text ab, sobald die Spalte schmaler wurde.
pruef_spaltenbreiten.py
Prueft ueber die ganze erlaubte Spanne, dass alle Spalten hineinpassen, die
Formularseite lesbar bleibt und NICHT mitwaechst, und der Umbruch zur
Spalte passt. Kein anderer Pruefstand haette das gefunden: es stuerzt
nichts ab und rechnet nichts falsch - man sieht die Preise nur nicht.
Er hat sofort einen zweiten Fehler gefunden: beim Aendern der
Fenstergroesse lief der Umbruch nicht hinterher, weil ich abgebrochen
hatte, sobald sich mein eigener Wert nicht mehr aenderte. Die Spalte kann
aber breiter werden, ohne dass ich etwas aendere. Abbruch jetzt, wenn zwei
Messungen dieselbe Spaltenbreite ergeben.
Fassung 1.7.1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V4t48uxDok5rJXhC9bX1Ax
TheMockTv