Hallo,
Zitat von
marabu:
Abgesehen davon, dass ein multiline edit window den Umbruch fast ohne dein Zutun erledigt, könntest du einen entgegengesetzten Ansatz wählen. Nicht einen langen Text zeichenweise kürzen, sondern den Ausgabetext wortweise aufbauen. Du greifst einfach Wort für Wort - Trenner kann white space sein - aus deinem Textpuffer ab und bestimmst über die
API Funktion GetCharWidth32() bzw. GetTextEntentPoint32() die benötigten Pixel. Das sollte deutlich schneller funktionieren als dein bisheriger Ansatz.
marabu
Ein Multiline-Edit kann aber keine Formatierungen darstellen, mein Edit schon.
Meine Vorgehensweise war natürlich vereinfacht ausgedrückt, ich springe beim Verkleinern immer zum nächsten Trennzeichen (Space, Interpunktionszeichen, Trennstrich...). Nur was mache ich, wenn mein Edit 30 Pixel breit ist und jemand "Donaudampfschifffahrtskapitän" eingibt? Da gibt es kein Trennzeichen. Also muss ich doch wieder nachmessen, bis es passt.
Ich hab mir schon überlegt ob ich einfach meinen Suchalgorithmus so optimiere:
1) Text messen
2) Text zu lang -> Textlänge halbieren -> Zurück zu 1)
3) Text zu kurz -> Textlänge um 50% vergrössern -> Zurück zu 1)
Da fehlt natürlich noch die Abbruchbedingung.
Das müsste die Textmessungen im Mittel drastisch verringern
Gruß
xaromz