@Lindon That makes sense, thanks!

Loading fonts seems to have fixed the issue with g.getStringWidth() in 4.0.0 too.

It's weird that it worked correctly even on unloaded fonts in 3.6.2, but in 4.0.0 using it on unloaded fonts gives you an incorrect pixel width. It's like the Windows fonts were loaded by default in 3.6.2, but in 4.0.0 they're loaded wrong. Could that difference in behaviour between versions indicate some kind of problem?

And is it worth adding a warning to users (whether in the software or in the documentation) when they use g.setFont() on unloaded fonts if the intention is that fonts should always be loaded in code? To me, the font loading part in the documentation reads as an option for adding your own fonts rather than a necessary step. I think I just read the correct syntax for setting a font, tried it and it worked, so I never had an indication that anything was wrong until now.

Either way, it looks like neither method is bugged, they just misbehave when you don't load fonts properly, so problem solved!

Build HISE from source, use the develop branch.

@d-healey awesome, thank you

@cynthasiser Glad we solved it :)

@d-healey said in Change Key Width using code:

Link Preview Image Updating FloatingTile Content Data

Here's an example that sets the lowest key of the keyboard floating tile. First we get the Data property, which is a string. We convert this to an object usi...

favicon

Forum (forum.hise.audio)

Cheers man! Bit of hunting for that trace(data) technique, but that has helped!

Another way is to use a MarkdownRenderer and a panel, but it's not highly customisable.
So a simple panel with a neat paintRoutine is still a good choice

@Lindon Okay, thank you! That's kind of what I'm doing but I guess the problem is I actually need the giant numbers because I'm working with exact integer ratios. I think I've found a better way of approaching the problem though, as I got it working with the smaller approximations and the behaviour wasn't quite what I wanted anyway.