Code and GUI Elements Altered When Working Between Windows 8, and = Windows 7

Question

This is not the usual "My fonts look different" problem we get when running application executables on different PCs.  The bug I am seeling (yes, I'm calling it a bug) is that when I bring up code to work on in Windows 8, several things change, both in the GUI and source panes.
1. Controls and indicators are scaled differently, moved, and frequently no longer aligned with the grid.
2. In structures like the timed loop, the parameter text is oversized, and only partially visible.  Changing font settings in Options has no effect.
3. Floating constants (not wired to anything) can show up in unpredictable places.  Even wired up code seems to move around.
4. Maybe unrelated, but WIndows 8 sucks.  Sorry, just had to get that out.
This is a serious problem which affects my productivity, as I cannot work on my code outside of my office, without creating more work for myself when I get back in.  The obvious solution would be to downgrade my laptop to Windows 7, but of course THAT OS no longer exists as far as Microsoft is concered.

Answer 1

Norbert_B wrote:
Hm, i have no experience with Windows 8 yet, so i cannot refer to your specific question/remarks.
But:
When switching my laptop to a newer one (the old running Win 7 32bit, the new Win7 64bit), i encountered some severe graphics issue with LV as well.
I found out, that my new laptop was configured to display "text and other items" with 125% (setting can be found in Control Panel>>Appearance and Personalization>>Display.
After changing this setting back to 100%, most things work fine now in LV.
Another point is (what i don't understand) that LV chose to preconfigure the three default font-collection (Application, Dialog, System) to be of size 20. My old machine had 15.
If you have VIs already displaying fonts at this size, you have to select all controls (Ctrl+a) and THEN change font size. Otherwise, it will not affect existing controls.
hope this helps,
Norbert
That is the Windows way of adjusting for displays with higher DPI, since the text can get very small with 150dpi displays rather than the standard 96dpi, Windows was originally designed for. Since the Windows graphic system is still mostly pixel based also for fonts, there is no other easy way to allow making text more readable. This scaling however messes with any graphic system that works on pixels rather than a virtual resolution and is one reason Retina style displays won't be a good option for Windows machines for some time to come.
The font size change is also because of that. LabVIEW detects at startup that the screen resolution is rather high and tries to correct for this. But together with the Windows screen scaling this makes things look even worse. Unfortunately there is no simple solution for this. Windows has over the time attempted to fix such issues in so many different and often incompatible ways, that there exist simply to many variables to make a program detect all possible  incarnations of user and system adjustable settings and account for them.
I'm sure there is room for LabVIEW to improve on this, but there is simply no way to make it work seemlessly for all possible configurations.
A long time ago someone designed a Next cube device that used Display Postscript as graphical output system. This Display Postscript had a true virtual resolution system and made the idea of having graphical output look the same on any kind of display or printer feasable. Unfortunately and despite working together with graphic chip manaufacturers it never made it as such into mainstream hardware. Supposedly partly because the performance was significantly less than other systems and therefore was never considered good enough for the main driving force in graphics developmen (games) but possibly also because the drivers were significantly more complex and there was not that much interest to dig that complexity.
MacOS X uses some of the concepts of the Next cube but abandoned Display Postscript for a somewhat more traditional approach. But Windows has still a lot to catch up in that area, if they ever do.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions