Front panel elements misaligned on target PC (same window size and display resolution)

[Bandit]

Hi,

I’m looking to improve my understanding of how LabVIEW front panels may show scaling errors when moved from one computer to another. 

I recently had an application with several arrays neatly aligned to form a table-like arrangement. When the application was turned into an executable and installed on the development PC the arrays were aligned as expected. When installed on the target PC (still 1920 x 1080) the arrays were misaligned vertically.

I’m already familiar with the way the graphics may scale badly if for example you resize the window, or if you change the display resolution.  However my issue is with fixed window sizes on screens of the same resolution (1920 x 1080). 

One difference between development and target PC’s was a 27” screen on the development PC and a 24” screen on the target PC, another was the use of motherboard graphics on the dev PC and separate graphics card on the target. I tried swapping the monitors – the misalignment persisted on the target PC with the dev PC monitor. The dev PC with target PC monitor remained well aligned. So it was unrelated to the monitor in use.

I tried other target PC’s, both desktop and laptop, and experienced the same misalignment.

A quick fix was to install the LabVIEW development environment on the target PC and align the graphics correctly on that machine, then rebuild and install the executable. This solved the immediate issue.

A better fix may have been to change the on screen display of data to an array of clusters, with one cluster representing one row. Each row includes strings, numerics, and a boolean (LED) so a 2D array wouldn’t work. But I'm sure some other visual scaling issues would have persisted.

Please see images for a simplified example .vi showing alignment (on dev PC) ad misalignment (target PC). Both screenshots were taken as the application was running. 

My question is how should I be proceeding to avoid scaling errors if the window is not resized and the display resolution is the same as the development PC?

Many thanks for reading,

Bandit

1. Arrays aligned on Development PC

2. Arrays unaligned on Target PC

[altenbach]

• Use defined fonts instead of symbolic fonts. (there is now even a VI analyzer test for that)
• Make sure all PCs have the same font scaling, i.e. 100%..
• Don't use any front panel features that scale with the panel/pane size.

[GerdW]

Hi Bandit,

---

@Bandit wrote:

My question is how should I be proceeding to avoid scaling errors if the window is not resized and the display resolution is the same as the development PC?

---

• Don't use "Application Font", but use a defined font (like "Tahoma 15") for your FP elements. You can enforce that by using some INI file keys…
• Check the display scaling on both computers! Are both set to the same value (scaling value 100% preferred!)?

[Bandit]

Altenbach,

Thanks for your very prompt reply. I'd already made sure all PC's had 100% font scaling, and haven't used features that scale with panel size to the best of my knowledge.

After following your link I'm upgrading to LV 2020 SP1 to access the VI analyzer test described there - I'm currently on LV 2019 SP1.

Thanks again for your help,

Bandit

[Bandit]

GerdW,

Thanks for your prompt reply. Display scaling is already set to 100% on all PCs.

I'm going to switch to defined fonts, but attempt to enforce that with the tool Altenbach describes rather than by editing ini files. Editing the ini files is something I'd rather avoid if I can, but I will go there if I have to.

Thanks again for your help,

Bandit

[GerdW]

Hi Bandit,

---

@Bandit wrote:

I'm going to switch to defined fonts, but attempt to enforce that with the tool Altenbach describes rather than by editing ini files. Editing the ini files is something I'd rather avoid if I can, but I will go there if I have to.

---

When you deploy executables to other computers then you should supply an INI file anyway. So don't hesitate to edit them before deploying…

[Bandit]

Hi GerdW,

Would you mind expanding on the need for the ini file in the distribution please?

For context my LabVIEW applications tend to be for data acquisition and rig control on one-off experimental systems, deploying a single instance to the target PC where we then test operation as part of the commissioning process.

Generally I explicitly include:

• A config file exported from MAX, with hardware configuration and NI-DAQ mx global virtual channels.
• A config file for the application with other user adjustable settings such as data acquisition rates, sensor calibration etc.

At the moment any ini file that may be created as part of the distribution is happening automatically in the background, perhaps as part of the LabVIEW runtime engine distribution, and will be filled with default values.

Aside from the current discussion of  scaling issues on the screen, what's the benefit of a custom ini file?

Best Regards,

Bandit 

[JÞB]

---

@Bandit wrote:

Hi GerdW,

Would you mind expanding on the need for the ini file in the distribution please?

For context my LabVIEW applications tend to be for data acquisition and rig control on one-off experimental systems, deploying a single instance to the target PC where we then test operation as part of the commissioning process.

Generally I explicitly include:

• A config file exported from MAX, with hardware configuration and NI-DAQ mx global virtual channels.
• A config file for the application with other user adjustable settings such as data acquisition rates, sensor calibration etc.

Best Regards,

Bandit 

---

Use project DAQmx channels Tasks and Scales instead of MAX.  Then in your code just call the defined Tasks.  Tasks seldom need to be created at runtime. 

When you build the application those project items are exported magically to a DAQmx ini configuration file next to the exe in the NI DAQ folder.   And yes, those human readable configuration settings can be edited without rebuilding the application. 

The MAX nce file should only contain Aliases, VISA passport options and ivi driver custom settings. 

[GerdW · Accepted solution]

Hi Bandit,

when you create an executable the AppBuilder automatically places an .alias and an .ini file next to your .exe. You can include that ini file into your project (and use it the next time you build your exe) and you can edit this ini file according to your own requirements…

That being said:

---

@Bandit wrote:

Aside from the current discussion of  scaling issues on the screen, what's the benefit of a custom ini file?

---

When you set some fonts in your IDE they will not be used automatically in the executable. You need to set some keys in your ini file so your exe also uses those fonts!

When you want to have the same UI look on all computers then you need to define those keys in the ini file…

[Bandit]

Hi,

Just popped back to mark this post as solved. Switching to defined fonts and editing the ini file with ini file keys as described above solved my issue, and the application installed on the target system with front panels displayed just as I created them. I've credited GerdW with the solution as they were the major contributor, but I've also made use of the vi analyser tool as described by altenbach and found it useful in tracking down a few rogue bits of display text.

Thanks to all who contributed. 

Bandit.