02-19-2013 04:49 AM
@Norbert_B wrote:
The three default font types (application, system, dialog) are a lookup for fonts, not specific fonts. LV uses this to make VIs portable between different OSes (e.g. Windows => Linux) since not every OS is working with "true type font" (ttf).
If NI wants to be really cross-platform they should just create a font or license a font available on all OS and make that the default font for LabVIEW and ship it with LabVIEW. They should also set the font size default to a specific size as scaling is only leading to problems... The current way LabVIEW handles UI fonts is a mess. What is cross-platform if the whole UI falls apart if we move a VI from WinXP to Win7???
02-19-2013 05:51 AM
I understand your irritation, but esp. fonts are a difficult topic.
Following your suggestion:
What happens if someone requires large fonts (150%, maybe even magnifying tool)?
You see, while you dislike scaling of fonts for your UI (i dislike it too!), there are some situations where this is mandatory. So it makes perfect sense to hook up to delivered functionality from the OS rather than to re-invent the wheel. Don't you agree?
OK, maybe there is room for improvement, i don't think switching to a proprietary solution (font supplied by NI) will be the solution....
Norbert
02-19-2013 07:35 AM
If scaling is done properly this would be fine. But it is not done properly in LV. FP objects do not scale correctly whith the font. So the important question is to select the most appropriate tradeoff and set it as the default. I do not know any developer who really likes the way LV handles fonts and sizes at the moment. LV user interfaces brake when ported to another OS or even Windows. The customer thinks that the developer is stupid and this destroys the developer's image. Actually it is not obvious for a new developer that such problems even may occur, because LV is advertised as cross-platform and noone expects that you are using a font that is not the font you really see. How can we design a UI without WYSIWYG? Why does Adobe Reader not have such problems? Because it nowadays includes all required fonts INSIDE the PDF. And it additionally also does the scaling properly.
06-12-2013 08:53 PM
This topic solved most of my display problems in Windows 7. Thanks.
One more thing you can see in HDRM's JPG's - the menu bar is a different color on the windows 7 machine. I'm seeing this too, and I'd like to fix it since I matched the front panel color with the menu bar. And when I run in windows 7, the front panel uses my selected color, and the menu bar is lighter. Any thoughts? Apologies if this should have been a new topic.
08-24-2016 03:20 PM
Just for completeness: Backport from Windows 7 to XP
Some people will have also the same problem, but in the opposite direction. E.g. my situation is, I'm developing on Windows 7, but the computers in the lab, where the executables are running on, are still XP. The result is a user interface with overlapping or partially invisible text because Tahoma (XP default) is too wide compared to Segoe UI (default on Win7).
So, what to do?
It's almost the same procedure as posted in the accepted answer, but with one more step:
FPFont="Segoe UI" 13 BDFont="Segoe UI" 13 appFont="Segoe UI" 13 dialogFont="Segoe UI" 13 systemFont="Segoe UI" 13
... and voilla, the front panel is pretty again. The nice thing on this solution is, it works, even if You used different font sizes.
I know, I'm warming up an old thread, but anyway, this seems to be a long term question, since the answer has been accepted 3 years after it was posted 🙂
08-24-2016 03:32 PM
@Bryan24 wrote:Gerd, how do I fix this so that I do not have to copy these keys on every application I compile?
Change your Windows 7 font to Tahoma rather than the default Segoui.
08-24-2016 04:26 PM
@pwalsh2 wrote:One more thing you can see in HDRM's JPG's - the menu bar is a different color on the windows 7 machine. ... And when I run in windows 7, the front panel uses my selected color, and the menu bar is lighter. Any thoughts? Apologies if this should have been a new topic.
Indeed, it's a new topic, the answer is right here: http://forums.ni.com/t5/LabVIEW/LabView-and-System-Colors/td-p/388942
It should be sufficient, if You select the Panel & Object color form the system section in the color chooser (at the bottom to the right). The color code is 0x1000016 (the leeding 1 selects the system colors).
08-24-2016 05:47 PM
@RTSLVU wrote:
@Bryan24 wrote:Gerd, how do I fix this so that I do not have to copy these keys on every application I compile?
Change your Windows 7 font to Tahoma rather than the default Segoui.
Please don't mix up the users, GerdW isn't me. Anyway, I've experimented around, here is, what I've found out in the short:
One approach would be, to set up a template INI. Check Use custom configuration file in the Advanced tab of the build specifications for the .EXE and insert the path to the template.
Another approach is, to set the font to Tahoma, before coding. But then, the font is fixed and the above solution to override won't work (if that should become necessary).
These settings are stored in the LabVIEW.ini (FPFont, BDFont), which is in the installation folder of LabVIEW. Also, it is possible to override the defaults of the development environment with the keys appFont, dialogFont and systemFont - here the issue is, these settings aren't forwarded to a .EXE, so it changes back to Segoe UI after the build.
Obviously, all these solutions have their pro's and con's, so there is no general way, how to do it - It depends on the developer's situation.
To answer the question about Tahoma as default: It's no option for me, because Windows XP is a deprecated OS running on a declining number of PC's.
So, I recommend to step forward to the actual standard and occasionally port back, if necessary.
08-25-2016 01:48 AM
Hi gerh,
One approach would be, to set up a template INI. Check Use custom configuration file in the Advanced tab of the build specifications for the .EXE and insert the path to the template.
IMHO this should be "the" approach!
When you create an EXE you need to create a BuildSpec in the project. You need to (or "should") provide an icon for your EXE. And you need to (or "should") provide an EXE.ini too and apply it in the build process. You can even create multpiple BuildSpecs for different targets (read: WinXP, Win8+) and provide different EXE.in for them…
02-01-2018 01:33 PM
I have a remote real time application running on cRIO and providing user interface via remote front panels. The front panel looks fine (Set to "15pt Dialog Font") on my Windows 7 development computer, both in LabVIEW and in Internet Explorer, but the fonts are too big on my customer's Windows 10 computer. Looking for a solution, I ran into this discussion. I've tried to follow it and have some questions:
1. Does a custom configuration file (.INI) override the setting at the top of the VI front panel in the executable? Will it also set the fonts for the remote front panel?
2. The consensus here seems to be to set a font to something other than the default (Application, System, and Dialog). Why then does the LabVIEW help suggest the opposite "When you design VIs, keep in mind the three fonts that map best among platforms: the Application font, the System font, and the Dialog font."
3. What do you suggest for consistent font sizes across platforms for remote front panels?
4. How does "Project Explorer->Tools->Options...->Environment->Fonts" play into this? Help says to "Use this section to configure three categories of predefined fonts: the Application Font, Dialog Font, and System Font." I thought these were predefined?