LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to program the front panel size to fit different monitor resolution?

Here is a similar thread.

http://forums.ni.com/ni/board/message?board.id=170&thread.id=291198&view=by_date_ascending&page=1

I have not found a solution to the problem.
I'm convinced there is no solution other than to plan your development on the lowest resolution monitor the program will be run on.

I have one program that the GUI has grown quite large and it was easier to get a new monitor to make it fit.
Message 11 of 17
(6,199 Views)

Hello,

 

   Thanks for getting back to me.  I am creating software for automated test station where everything is in a roll around 19 inch rack. The monitors in the reacks are small, so I have to work with what I have. If I find something out I will let you know.

 

Regards,

 

Kaspar

Regards,


Kaspar
0 Kudos
Message 12 of 17
(6,191 Views)
Hello,
 
    I talked to one of my co-workers about determing the screen resolution size and he told me how to do it. So the credit goes to my co-worker but I will put it on this forum for all of us to understand how to do it. So here goes, this is how I did it with Labview 8.2
 
  1. Go to the block diagram of the vi
  2. Right click and find the Application control Pallette
  3. Drag and drop the Application Property node onto the block diagram
  4. DO NOT connect anything to the reference input so that the Property node thinks that it is getting info from the system
  5. Right click on the Property and select Display ---> Primary Workspace
  6. Right click on the property and create and indicator. (which is a cluster that contain the screen resolution)

  I have tried this on my development enviornment and the actual test system and I can see that the display resolution does change. So please (I have used the magic word) try it out and let me know if it works for you!

Regards,

Kaspar

 

 

 
Regards,


Kaspar
Message 13 of 17
(6,181 Views)
I have made several applications with resizeable windows, and what Ed said earlier holds true.  Design for the smallest and allow that to be stretched.  Fonts are definitely one of the major issues, but one you have a bit of control over, depending on how high your pain threshold is.  You can programmatically change the font size/family/style in most text strings by using the various Font properties.  You can also change it globally to something other than the system font by putting INI file tokens in your labview.ini file.  I usually use these to keep my LabVIEW font larger than normal to ensure I have space for such things as localization and system font changes.  The tokens look like this:

appFont="Verdana" 13
dialogFont="Verdana" 13
systemFont="Verdana" 13

You can change the font family and size to anything you want.  Note that you can change these in the options menu, as well.  Uncheck the "use defaults" button first.

There is no easy answer to this problem in any programming language.  Even Microsoft Office behaves somewhat poorly when subjected to large changes in font size.  It can be done, but depends on how much time and effort you are willing to spend.
Message 14 of 17
(6,148 Views)

Hello,

   You are correct, you can do alot of stuff if you are willing to spend the time to do it. I just wanted to be able to determine the screen resolution and programmatically determined the size and location of the window so that the user can always see the window. My development enviornment is a dual screen high res monitors, so at time I get carried away with writing code. Maybe I am having to much fun and/or to much Mountain Dew, probably both. However the actual enviornment where my code is used is in a 19 inch roll around rack with postage stamp size monitors, so I have to be careful over what I do. I hoped I helped someone out with sharing the info on how to determine the screen resolution. 

Regards,

Kaspar

 

Regards,


Kaspar
0 Kudos
Message 15 of 17
(6,143 Views)


Kaspar wrote:

Drag and drop the Application Property node onto the block diagram

DO NOT connect anything to the reference input so that the Property node thinks that it is getting info from the system


Just a minor point. There is no "Application property node". When you drop a property node (from that palette) in the diagram, it defaults to the Application class. The Application class is the one that has the property you are using, so that's the reason not to connect anything to the node. When you connect a reference to the node, the node will expose the properties available in the class of the reference, but you can also change the class manually by right clicking the control.
 
Note that most classes require you to wire a reference in, because there is no default object to get the property from. You can see a good tutorial on part of this here.

___________________
Try to take over the world!
Message 16 of 17
(6,126 Views)

Ed Dickens wrote:
Another option, though it's a bit more work, is to design a separate GUI for each resolution. You can read the monitor resolution and load the corresponding GUI, which would then call the real VI that does all the work.

Hi there,

I have made a sample application with this approach. The attached ZIP file has all the three VIs, plus the executable which includes all ofthem.

 

Can you have a look at them and tell me if this is what you meant?

 

@ Kaspar

Can you also tell me please if you have had any issues since you seem to have implemented this method already?

 

Thanks ahead!

Vaibhav
Message 17 of 17
(5,637 Views)