Label with numeric values

[ForTest]

Hi

I've seen a lot of project examples showing numberic values changes in real time

I'm trying to do the same with a label widget but i have some issues:

 

a. Using gwinSetText i get a refresh of the whole string so i get an annoying effect because all the area is turned black and redrawed character by character.

b. Every digit can have a different width from each other so if i refresh them is it possible to see each character move left or right. Although this effect is annoying.

c. The label widget doesnt have a left alignment. For example if i want to put a counter in the top-right of the corner it should see the number increasing its digits from the right to the left.

 

So i ve made an array of label. Every label contain a single digit or a  "." , so the width is fixed to the maximum width of a digit or the width of a "." and this solve the b.  and also a. because using array i can refresh only digits that are changed

I'm working on c. because it is necessary to reverse the original string and do some stuff

 

I wonder if anyone has already had to deal with these problems and how he dealt

I'd like to know if there are ways more 'effective and maybe already made that resolve the problems I have described

 

Edited April 21, 2016 by ForTest

[Joel Bodenmann]

The proper way of doing something like this is having to separate labels: One for the text and one for the numeric value. This helps with a.
If you want to further decrease flickering (and improve the overall FPS performance) you might want to consider using pixmaps: http://wiki.ugfx.org/index.php/Pixmap

The way you solve b. might be a bit over complicated for no reason: Simply use a mono-spaced font. You can apply a font to just one individual widgets. Therefore, you can have a monospaced font that you just apply to the labels that contain numeric values and you can use a different font for all the other widgets. You apply a font by using gwinSetFont().
Note that having one label per digit is a very bad idea in terms of flexibility and especially memory and CPU requirements.

Regarding c.: I'm not sure what you mean. The label widget comes with three built-in rendering routines: Align right, align center and align left: https://bitbucket.org/Tectu/ugfx/src/25802124fb64a949971a89dd2ef34b749d949494/src/gwin/gwin_label.h?at=master&fileviewer=file-view-default#gwin_label.h-112

Please do not hesitate to ask if you have any further questions or if we need to clarify something.

[ForTest]

Thank you for the suggests Joel

a.  I will try

b. I've tryed but is not working.. the TTF file is ok and the characters have all the same width, but when i export them and check the size (gdispGetStringWidth) i get different width values

for example:

"0" --> 43 pixels

"1" --> 44 pixels

"2" --> 43 pixels

etc..

in your opinion on what you can depend this additional pixels?

c. ok it works! i've made a mistake in the settings property of a label

Isonorm Monospaced RegularTTF.ttf

Isonorm Monospaced RegularTTF80.c

[ForTest]

About a.

I've enabled PIXELMAP in the configuration and i get some compilation errors

This topic has already discussed here:

I'm using SD1963 driver with KDS 3.2.0 on a K64F by freescale (nxp)

 

[Joel Bodenmann]

On 4/22/2016 at 11:20, ForTest said:

I've tryed but is not working.. the TTF file is ok and the characters have all the same width, but when i export them and check the size (gdispGetStringWidth) i get different width values

That might be related to a rounding issue. Thank you for providing the corresponding font files - we'll have a look at it during the next week.

 

21 hours ago, ForTest said:

I've enabled PIXELMAP in the configuration and i get some compilation errors

Well, as you mentioned this topic has been discussed already multiple times. Please follow the advice/guide in the corresponding forum thread. Note that you will find other similar forum threads using the forum search. Especially note the known issue where pixmaps can't be used in single-file-compilation mode as the documentation mentions. We (inmarket) is currently working on resolving this issue.
If you are not able to track down and resolve the issue with the existing information, please let us know what compilation errors you get. We can't help you if you don't provide all the available information.

[Joel Bodenmann]

We took a look at the issue with the monospaced font. The problem is that the font that you're using is already broken. It seems like all characters use a width of 547 but the space character is only 500 wide. Therefore the font engine encoder doesn't recognize the font as a monospace font and the width calculations won't be correct. According to FontForge the font has some other issues as well.

I'm sorry but there's nothing we can do if the font itself is broken.