I nearly draw any of my text using GlyphArrangement::addCurtailedLineOfText because the text gets displayed inside
a LCD display (sort of) where I create a path using GlyphArrangement::createPath with setUsingNonZeroWinding(false) to get this
inverse font style.
That works quite well as long as the text to display does not contain " & ". This set of characters (space & space) causes
the application to hang. I noticed that with my Filelistcomponent that shows of course the content of my disc.
The crash actually happens when executing GlyphArrangement::createPath! As soon as I remove the two space bars
from the Folder Alias name, then it works fine.
Folder Alias named: “Handbuecher & Informationen” -> hangs
Folder Alias named: “Handbuecher&Informationen” -> works
This folder alias was created by the system, not manually.
I’ve attached a screen print of the debugging window if that helps…
…but GlyphArrangement is used in all text drawing - even if you don’t call it directly, the other functions use it internally. So if it fails on a seqeunce containing “space-ampersand-space”, then it’d be impossible to use draw that text anywhere. And I can’t reproduce the problem - can you provide some code that fails?
Yes, I can but I think the following info are more important to isolate
the problem. It seems to hang the application if there is an umlaut before
space-ambersand-space in a String.
Did some test with different names for folder, tested with the FileListComponent- that is the result:
File name to draw “Jörg & Paul” -> hangs
File name to draw “Joerg & Paul” -> works
File name to draw “Jörg” -> works
You can put the code into the ListBox::paintListBoxItem method and comment out
the addFittedText you don’t want to debug.
It is not my final code! I didn’t pay attention to any float conversions and stuff here, just for testing!
Before I even try that, you’re creating a unicode string from an 8-bit ascii literal (didn’t it throw an assertion?). What happens if you use L"Jörg & Paul" instead?
You are right but as I said, it is actually used to paint listbox items of the FileListComponent
and it doesn’t even work with File::getFileName() because it returns a String!
If there is a conversion in between from unicode to whatsoever, you should then rename
addCurtailedLineOfText to something else w/o “Text” at the end because g.drawText works
and GlyphArrangement::addCurtailedLineOfText doesn’t!
Yeap, that is what I almost always do except this time but to be perfectly honest,
I didn’t expect, that updating from 1.53.91 to 1.53.93 has such an impact especially if
there is nothing descibed in the change log that point me to a bug fix for this
particular issue and you probably would instantly tell me that there were some changes.
The only difference I can think of is that the last time when I updated
to the latest GIT using Introjucer, I did “add and overwrite existing files” but today,
I replaced the entire juce folder instead. Maybe there went something wrong during
the last udate…
Anyway, it works now (okay, it doesn’t show the affected file name a propper way
as it just replaces the ambersand by a space) but that is also if I use the original
FileListComponent, so it just a minor issue for me…