LabVIEW
Why do very few programmers use LabVIEW unit labels
Dropping these links here in case anyone finds them useful. I also did an NI Connect presentation on Units yesterday. It was filmed and the video will be on YouTube at some point. It will also be linked from the LabVIEW Wiki.
https://stravaro.com/2021/07/labview-units-part-1/
https://stravaro.com/2021/07/labview-units-part-2/
@rolfk wrote:
Try %.6pA for lolz. The p format specifier is a special format specifier like f, e, d and others and means to use the SI Notation format
My internal perfectionist would always like to have a space (more precisely, from a typographic point of view a thin non-breaking space which is U+202F) between digits and units, as well as the 'µ' symbol instead of 'u':
Just curious — is there no way to achieve this in the simplest form with numeric except by string indicator?
@Andrey_Dmitriev wrote:
Just curious — is there no way to achieve this in the simplest form with numeric except by string indicato
I very much doubt it. The whole string formatting is programmed in C. The C runtime library only knows ASCII as normal character set. It also mostly supports the locale concept that adds additional characters based on codepages. And theoretically it could be used with UTF-8 as locale. In practice that only works on Linux pretty well and not yet that long really, since they had not almost finished a complete UTF-16 API at the time the Unicode dust sort of settled down. Under Windows, Microsoft had already completely settled on UTF-16 in the kernel, based on an early Unicode standard that only had specified characters fitting easily in the 16 bit encoding, and according translation APIs to the old ANSI APIs and very little interest in creating an even bigger construction site by trying to add UTF-8 support to their standard C library. they eventually had to add variable length encoding to their UTF-16 implementation because the Unicode consortium kept adding new glyphs to the standard that eventually exceeded the 16 bit space that UTF-16 could provide.
Also programming with the standard C library to fully support UTF-8 is an exercise in itself. It's not as simple as just adding a function call to change the current locale at the start of your program. Many things have to be considered in your code such as that the encoding is not single byte anymore but has a variable byte size per glyph. Also you almost always in-evidently run into the problem that not all components that your program may call, will like your choice of the C locale and will run into all kinds of trouble.
Since the LabVIEW formatting functions are ultimately all programmed on the C level, most of them even before the time any new LabVIEW code was written in C++, it's a pretty much idle hope that you could do anything involving Unicode characters on that level. Also much of the formatting functions are completely written for LabVIEW and not just use standard C formatting functions, as evidenced by the similar but not fully equivalent formatting codes and rules.
@rolfk wrote:
I very much doubt it. The whole string formatting is programmed in C. The C runtime library only knows ASCII as normal character set. It also mostly supports the locale concept that adds additional characters based on codepages. And theoretically it could be used with UTF-8 as locale...
Well, Unicode support in our dreams (but copypasting thin space into string works), but even If I try to put single ASCII space into format string in attempt to get some empty distance, I have this:
So, the question is — how to insert "normal" space between digits and unit in numeric indicator use case shown above (the difference between thin space and regular space is just one pixel at this font size). And this mission seems to be impossible for me.
@Andrey_Dmitriev wrote:
So, the question is — how to insert "normal" space between digits and unit in numeric indicator use case shown above (the difference between thin space and regular space is just one pixel at this font size). And this mission seems to be impossible for me.
You can't! The SI indicator for sub standard quantities such as kilo, milli, nano etc is part of the %p format specifier. There is no way as far as I know of to add an extra qualifier like the #. or similar to that format specifier to indicate that you want a space between the digits and that quantity indicator. Adding it to the string format doesn't help either as you end up with a display like 1.234m A. The format specifier for string formatting is a very powerful feature, but you can't make it do anything you like. The LabVIEW version leans very much on what the Standard C library defines and implements things beyond that but this is an endless resource sink to add more and more of such features and makes the already extremely complicated format string parsing only even more complicated.
In fact the LabVIEW implementation deviates in certain areas from the current Standard C definition mainly because when it was implemented (~1988) they choose to use unused format specifiers for LabVIEW specific things that later got used by the Standard C definition for other things.
