LabVIEW Idea Exchange

While debugging there's no way to easily have informations about the settings of a Call Library Function node.

Why not adding some infos on the Context Help?

Dealing with fonts in LabVIEW can be a nightmare due to the variations in fonts, types of fonts, rendering variations, resizing, etc.  If you are deploying a LabVIEW application on another machine, frequently the fonts or settings on the target machine don't match; creating a very ugly looking panel.

When developing for Windows in the past I have always edited my LabVIEW.ini file  to include the following:

appFont="MS Sans Serif" 13
dialogFont="MS Sans Serif" 13
systemFont="MS Sans Serif" 13

And when deploying an application; I include these in the app's ini file also.

This seems to work for most windows targets since MS Sans Serif appears to be a common font.  I suspect this will produce unpredictable results in OSX or Vista for that matter.

What I expect as a developer is not having to deal with these font issues.  I expect that when I develop an application that it has the same look and functionality; regardless of where it is deployed; even as a VI being edited on another machine with different font settings.  This means that the font information must be encoded and stored with the VI itself.  I would expect that both the LabVIEW editor and run-time engine would be able to recognize detailed font encoding within the VI and adjust the display accordingly based on the local machines font capabilities.  This is what one expects when printing or viewing an Adobe Acrobat PDF file; and the behavior of LabVIEW code; particularly since it is so graphical in nature; should also be similar.  I wouldn't expect that the actual font bitmaps be stored within the VI itself; but some detailed metrics about the font should be; height, width, kerning, etc.  Thus if a font substitution takes place when being deployed on another machine; at least the text will occupy the exact same extents as the original.

Though I don't know exactly what the detailed implementation would be; it does need to be transparent to the LabVIEW programmer, i.e. zero code; zero hassle; zero worries.  It should just work.  I hope we can all agree on this.

Right now, you can add one group by which to filter the files you can select in a file dialog (e.g. when clicking the button next to a path control). You  can add extensions by opening the "Browse options" and adding the extensions. You can separate the extensions by semikolon to filter by multiple extensions. However, you cannot add multiple groups.

Here's how it looks now:

In this setting you get to see all *.txt, *.doc and *.pdf files at once.

But what if you want more than one group to filter?

You could use .Net to call a standard windows File dialog. This dialog supports multiple groups separated by |

So, you can achieve something like this:

This feature should be available for the standard path control in LabVIEW, too.