Ja das Problem ist bekannt und bereits behoben. Im SingleLine Modus habe ich stumpf vergessen den Rückgabewert zu setzen.

Als Fix geh mal in der unit TextSuite.pas und ersetze die Zeile 2495

durch diese



Für die Höhe der Zeile benutze ich (und eigentlich alle anderen auch) das LineSkip was direkt aus dem Font kommt. Es wäre sicherlich möglich von alle Zeichen die passenden Werte herauszusuchen. Allerdings macht es wohl optisch normal kaum einen Sinn. Wozu benötigst du denn das? Weil oberhalb mehr Luft ist als unterhalb?

Ah, vielen Dank das geht supi.

Ich benutze das weil ich den Text damit in die Mitte des Buttons bringen will. Aber eigentlich sollte das auch nicht so wichtig sein weil eine einheitliche Größe warscheinlich eh am sinnvollsten ist.

Das Problem ist wenn du mit der tatsächlichen Höhe der Buchstaben arbeitest hast du immer unterschiedliche Größen und dann sieht es aus wie Kraut und Rüben, da die Grundlinie der Buchstaben immer anders ist.

Für den Single Line Modus wird per Default die Baseline des Textes an der aktuellen Stelle gesetzt. Du kannst das auch so einstellen, dass die obere Kante die aktuelle Ausgabeposition ist. Also mit anderen Worten wenn du von dem Button die halbe höhe nimmst und die halbe Texthöhe davon abziehst erhältst du normal die Position an der der Text ausgegeben werden müsste um Zentriert zu sein. Allerdings müsstest davor noch etwas an der Ausgabe anpassen.

tsSetParameteri(TS_SINGLE_LINE, TS_SINGLE_LINE_TOP);


tsSetParameteri(TS_SINGLE_LINE, TS_SINGLE_LINE_BASELINE);



PS: Die Bilder gehören zur Hilfe. Die sollte es eigentlich erst später geben.

Auf die Hilfe freue ich mich schon

Im moment suche ich in der uses nach Funktionen die so klingen als wenn ich sie brauchen könnte. Du gibst dir aber echt Mühe mit deinem Projekt und scheint ja gut zu funktionieren.

Hm ich bin jetzt nicht ganz sicher aber ich kann mir vorstellen das es an der TextSuite liegt:

Also wenn ich die Szene rendere und KEINE Textur geladen habe wird meine gesammte Szene so hellgrün. Wenn ich "tsTextOutA(ButtonGroup[e].buttons[i].name);" auskommentiere wird sie richtig (allerdings ohne Schrift) angezeigt.

Komischerweise wird aber auch wenn ich eine Textur geladen hatte alles das NACH dem dem TextOut zeichne grün. Die Elemente die grün werden sollten eigentlich grau werden was ich mit glColor3f gesetzt hab.

Möglicherweise. Das ist aya vor einer weile schon mal passiert. Die TextSuite arbeitet natürlich mit Texturen (wie auch sonst) und die werden nach dem Zeichnen nicht zurückgesetzt. Es ist nicht ganz so einfach zu entscheiden wann wirklich Schluss ist, deswegen setzte ich vorsichtshalber nichts zurück. Eine Möglichkeit wäre wie glPushAttrib und glPopAttrib. Dafür habe ich mir schon eine Aufgabe erstellt. Da sind mir aber ein paar Details noch nicht ganz klar. Das wird aber in die aktuelle Version sowieso nicht mehr einfließen. Sondern nur erst mal in der Hilfe vermerkt werden.

Folgende States werden derzeit verändert:
- Textur (glBindTexture, glTexCoord, glEnable(GL_TEXTURE_2D))
- Farbe (glColor)
- Position (glTranslate)

Okay ich habs nu mit glPushAtrib gemacht und hau da einfach alles rein, solange ich keine Performance Probleme bekomme ist das ne gute Lösung.

tsPushStates hat irgendwie nicht geklappt, ist das noch nicht implimentiert oder muss ich da was bestimmtes beachten?

*hust* Habe ich doch geschrieben. tsPushStates/tsPopStates gibt es noch nicht. Lediglich eine Aufgabe dazu.
Und ich hatte auch geschrieben wie glPushStates/glPopStates. Das glPushStates/glPopStates mit allen states ist ziemlich langsam. Also wenn möglich solltest du das das eher nicht machen, da es durchaus schon einiges kosten kann. Wie geschrieben sind die Befehle glBindTexture, glTexCoord, glEnable(GL_TEXTURE_2D), glColor, glTranslate die Einzigen die ich derzeit benutze.

Hi!

Ich glaube ich hab einen kleinen Bug gefunden:

In der Unit TextSuite fehlt in der Zeile 2495 ein "result :=". Sonst hat mir die Funktion tsTextGetWidthW immer 0 zurückgeliefert.

Das Projekt gefällt mir sehr gut. Das erleichtert die Texthandhabung enorm!

Hallo Stefan willkommen im Forum.

Ja du hast Recht. Es handelt sich dabei um einen Fehler. Den habe ich aber schon gefixt. Ich habe die Version nur noch veröffentlicht, weil ich derzeit an der Doku zu Gange bin. Kommt dann beides gleichzeitig. Dauert hoffentlich nicht mehr all zulange.


Das hört man gern. Bedeutet ich habe doch irgendwas richtig gemacht.

Ich glaube ich hab in der aktuell verfügbaren Version einen Überlauf gefunden...

Und zwar in den TTFUtils, funktion GetTTString, in der Unicode-Konvertierung.

Ist eventuell zu wenig Platz. Ich hab hier einen Font (Mathematica3Mono), dessen Name 16 Zeichen lang ist und der in uStringLength 32 stehen hat. Das fehlende #0 am Ende führt hier zu Stack-Überläufen in WideCharLenToStrVar.

löst das Problem.

Inwieweit das jetzt ein Bug von der TS oder eher vom Font ist, weiß ich nicht. Ein Crash ist aber immer schlecht

_________________
Gott sei Dank bin ich Atheist!

Ja ein Crash ist in der Tat etwas ungünstig. Ich gehe mal davon aus, dass deine Quellen aktuell sind. Da ich aber noch keine Versionsnummer habe lässt sich das nur sehr schwer nachvollziehen. Aber die Quellen habe ich seit 3 Monaten auch nicht verändert.

Was benutzt du denn für ein Windows und Kompiler? Hast du auch mal die DLL ausprobiert? Einfach das Symbol TS_EXTERN_STATIC definieren.

Mir sind aber noch ein paar Sachen etwas unklar. tsStrAlloc erstellt automatisch einen Puffer der bereits ein WideChar (2Byte) größer ist als angegeben. Also wenn dort original als Größe eine 32 drin steht dann erstellt er einen Speicherbereich der 34 Bytes groß ist. Den Speicherbereich initialisiere ich auch vollständig mit 0. WideCharLenToStrVar arbeitet im übrigen auch noch mit einer Größenangabe. Und die Größe die ich an WideCharLenToStrVar übergebe ist die aus uStringLength. Da kommt dann ja noch ein WideChar oben drauf. Weswegen mich das etwas irritiert. Ich hoffe du verstehst was ich meine.

Was ich mir vorstellen kann ist das da evtl. eine 33 als Größe drin stehen könnte. Denn beim Move benutze ich wieder die angegebene Größe. Was also unter Umständen dazu führen kann, dass das letzte WideChar nicht #0 ist, da ein Byte zu viel kopiert wurde. Damit ist der String dann wirklich nicht abgeschlossen. Aber bei WideCharLenToStrVar arbeite ich wieder mit einer Länge. Und da sollte man sich eigentlich drauf verlassen können. Hoffe ich einfach mal so blauäugig und naiv wie ich bin.

Aber das was du da beschreibst sieht wirklich so aus als würde da eine Puffergrenze überschritten werden. Inklusive des Fehlers. Nur verstehe ich nicht ganz warum das passiert und auf Verdacht den Puffer zu vergrößern erscheint mir nicht so optimal. Aktuell habe ich mir das Font auch mal installiert und da läuft es. Aber ich meine ich hatte auf einem anderen System auch schon mal Probleme damit. Aber ich glaube da hatte ich die Probleme beseitigt. Werde das aber noch mal testen. Im Zweifel schick mir bitte die einzelne Fontdatei mal per Mail zu.

Wenn du aber noch mehr in Erfahrung bringen könntest wäre ich dir dankbar. Also tsStrAlloc auch einen größeren Puffer erstellt. Und die Größe ist wirklich genau 32? Schon mal danke für Hinweis und eventuelle Mühen.

Lossy

Also, compiliert ist das ganze mit D7 auf Win2000. Die Version ist die aus dem Zip-Archiv im anderen Thread. Ich muss allerdings zugeben, dass für meine Anwendung die Quellen etwas zerlegen musste. Inhaltlich ist aber genau keine Änderung. Das führt aber dazu dass ich mit der DLL nicht testen kann.

In dem Record-Feld steht exakt 32. Der Debugger-Hint zeigt auch genau 'Mathematica3Mono' an. Das sind 16 Zeichen, deswegen hab ich angenommen dass da die Nullen fehlen, die der Debugger oft nicht so genau zu nehmen scheint.
Klar, auf Verdacht Puffer vergrößern ist auch nix, aber ich könnte mir den Überlauf nur damit erklären dass hier irgendwie der seltene Fall eines Delphi-BufferOverflow auftritt... was auch dadurch bekräftigt wird, dass das Stack-Fenster nur eine Hand voll Aufrufe anzeigt, bei anderen Überläufen stehen dann ja echt die Rekursionen (z.B.) drin.

_________________
Gott sei Dank bin ich Atheist!

Stack Überläufe können auch entstehen, wenn eine Methode Parameter/Variablen auf den Stack packt und sie nicht wieder entfernt. Das kann zum Beispiel passieren, wenn man cdecl Methoden mit stdcall aufruft. Bzw massiv Records oder statische Arrays in dem Var Teil einer Methode gehen auch alles zu lasten des Stacks. Aber die werden normal wieder entfernt, wenn man nicht zu stark in die Delphiquellen eingegriffen hat (Assembler). _LStrFromPWCharLen hat zum Beispiel einen 4k großen Buffer. Die Methode wird von WideCharLenToStrVar aufgerufen. Allerdings erklärt das nicht warum es geht, wenn der Buffer 1 Byte größer ist. Denn der Speicher wird per Hand erstellt und liegt somit auf dem Heap. Für den Stack ändert sich dabei meines Wissens nach gar nichts.

Kurioserweise habe ich auch genau diese Konstellation getestet. Also Delphi 7 auf Windows 2000 mit den Fonts. Und hier gings. Ich weiß allerdings nicht was du sonst noch in deinem Programm tust. Evtl versuch mal bitte die maximal Stackgröße zu verdoppeln und mal zu schauen ob es dann geht. Obwohl das sicherlich auch nicht der schönste Weg wäre. Wobei das +1 ja eigentlich nichts mit dem Stack zu tun hat. Sondern halt mit dem Heap. Oder auch mal die StackFrames im Delphi aktivieren.

Ich hatte auch mal mit WideCharLenToStrVar experimentiert und einen Buffer angegeben der genau die gleiche Größe hatte und es ging. Das hatte ich auch direkt in der TextSuiteTTFUtils.pas gemacht + Umstellung von SwapText, denn der geht wirklich nach #0. Aber auch das ging ohne Probleme. Obwohl Delphi allerings einen falschen Text angezeigt hat. Denn der geht ja auch nach #0. Aber kein Fehler.

Sonst wüsste ich nicht was es noch sein könnte. Ich werde aber in meinem Bugtracker dafür einen Eintrag erstellen, damit es nicht verlohren geht. Evtl meldet sich ja noch der ein oder andere der so etwas auch hat.


Aber noch etwas am Rande. Mich würde interessieren was du verändert hast? Das aber nur aus reinem Interesse, denn evtl. ist es ja etwas, was auch Anderen etwas nützen würde.

Wobei das natürlich potentiell gefährlich ist, da ich noch einige Fehler gefunden habe bzw ich auch noch plane es weiter zu entwickeln, zu optimieren und intern umzustellen. Was ja auch teilweise schon passiert ist. Das wurde eben nur noch nicht veröffentlicht. Aber das dann zu mergen ist nicht mein Problem. Bzw kann ich bei veränderte Versionen auch nur bedingt helfen. Und es dürfte wohl auch verständlich sein, dass meine Priorität ganz klar auf der Originalversion liegt.

Das ist mir natürlich klar. Meine Veränderungen belaufen sich auch nicht auf die Funktion, ich habe lediglich die Funktionen die ich gebraucht habe in eine Klasse verpackt und die Abhängigkeiten zu den anderen TS* -Units aufgelöst.

Ich werde mal ein Testprojekt machen und deine Vorschläge testen. Wenn das nichts bringen sollte, kann ich dir das dann ja auch zukommen lassen.

Weitere Ergebnisse editiere ich hier rein.

EDIT1: im Testprojekt kriege ich keinen Stack-Überlauf mehr, sondern eine gewöhnliche AV. Die allerdings in Endlosschleife. Evtl hat der ExceptionHandler ja einen Überlauf provoziert?

EDIT2: die Exception tritt auch nicht in der Text-Tabelle auf wo Mathematica3Mono drin steht, sondern in einer vorher. Da hat ttRecord.uStringLength den Wert 9... Den hatte ich im anderen Projekt allerdings nicht, zumindest nicht mit Fehler. Ich werde mal testen ob der Systemabhängig ist, also neu starten.

EDIT3: es ist unabhängig. Dafür habe ich was anderes festgestellt: wenn ich die JCL (über die Unit JclDebug) oder FastMM einbinde ist der Fehler weg (bzw. bei FastMM entsteht ein anderer). Ich glaube mittlerweile eher an einen Fehler im Speichermanager, als bei dir.

_________________
Gott sei Dank bin ich Atheist!