10-23-2015 03:52 PM
Solved! Go to Solution.
10-23-2015 04:30 PM
What I have done is to reposition front panel objects with their x and y positions programmatically depending on the display resolution. I've done this on programs in the old Visual Studio days, and it worked fine on the LabView program, but this was done from an ini file instead of reading in the display resolution. I just put a few resolutions with the constants for positions into a case structure, and then on program start the correct constants read out to the front panel objects positions. This was a program that would only go on three computers in the factory so I didn't bother reading in the resolution to set the case structure like it really should be.
I didn't like all of the property nodes on the block diagram. If I had to do it over it would be better to use x and y position arrays and then set the positions by reference in a loop.
I've also never been happy with the positioning when resizing my front panels.
One program I had one view with a graph that needed to be maximized and used the same basic approach for controls to make it look better, but this one didn't support multiple display resolutions.
10-25-2015 11:08 AM
I just plan my GUIs based on the smallest resolutions my program will see. If more information is needed than can fit onto that screen, tab controls or subpanels are typically the way to go.
10-25-2015 11:17 AM
10-25-2015 11:22 AM
@ijustlovemath wrote:
It's really only my main Vi that has resolution problems. The rest of my VIs are dialog boxes for the most part. How do you avoid the problems listed in the OP where buttons get warped/moved off the screen at lower resolutions?
I don't autoscale. I have not ran into any modern resolutions that cause warping. If I find time, I do some experiments with some.
10-26-2015 07:41 AM
You can add some splitter bars and have only certain parts scale. It might not be enough, if it's a "button section" and a graph e.g. that's a good way to only have the graph scale.
/Y