I am developing code on my laptop which has a resolution of 1360 x 768 ( aspect ratio 1.77)
The final monitor on the equipment is much larger at 1920 x 1080 ( aspect ratio 1.77 )
So when I code on my laptop i must make sure the FP image will fit the larger screen by setting the X-Y co-ordinates of the right lower corner.
How to go about this ?? Is there any way i can read the X-Y co-ordinates of the active FP ?? Or since the Aspect Ratio is same, can I simply enable the "Scale all objects as window resizes ? " in propeorties ? ( Have not tried it still )
Drop a property node and link it to the Pane. Use the Bounds property.
I would not mess with scaling objects. It just never works well and gets worse the more you resize the window.
>> I would not mess with scaling objects. It just never works well and gets worse the more you resize the window
So thats how it is ... I was wondering if i was the one who was seeing this happen. In any case labels dont resize as the font sizes are frozen. And added to this if the Aspect Ratio of the monitors differ then round gauges become egg shaped..
But actually i was wondering if there is anyway to know the right side lower corner pixel co-ordinates of a indicator - say a graph. ( When desiging the FP that is )
Font size is not one of the scalable items.
You can find the bounds and position of any front panel object using property nodes.
Right click on any front panel object, Create Property node, and browse the list of all the properties you can read, (and many write to).
More usefull links:
Property node for VI -> Front panel window -> Window bounds. Allows you to get (and set!) window position in screen coordinates, that includes title bar, menu bar, window border.
Property node for Pane -> Origin. All element positions are relative to this point, not pane corner. You need to subtract Pane -> Position (top left corner relative to Origin) from Control -> Position to get control position within window.
VI properties (ctrl+I) -> Window run-time position -> Position -> Maximized
Controls -> Containers -> Splitters. Allows you to split window into separate panes and set scaling in each one independently. Some elements scale not very bad (graphs), all others - worse, you place them in fixed regions that shift as a whole.
Thanks to all those who responded. Some things are clear based on interactions :
1) The FP does not have a invokable method where you can read the X-Y co-ordinates of the mouse cursor - something which is normal in drafting packages..
2). The Property node exposes many useful proporties to set and read the bounds of the FP .
3) Ideally try to develop the FP on the target monitor or on your PC set to match the taregt monitor resolution.
4) If you cannot do above, make sure the chosen resolution on your PC/Notebook has the same aspect ratio as the target monitor. Then use the VI Properties > Window Size > Minimum Panel Size to set the Width and Height to match the target monitor . After this you can create the FP objects and save. This will render correctly on the target monitor.
5) Do not use the "Scale all objects on FP...." in an effort to scale the FP when moving between different monitor resolutions. It messes up the FP view.
6) Having created an FP as above, you can revert back to your native PC / Notebook resolution to develop the BD and save it as long as you DO NOT alter any FP objects or resize them.
The mouse cursor is not really an attribute of the FP technically since only the active FP captures the mouse. Instead you need to either use the event structure where you can have a mouse move event captured on a specific control, a pane or the entire VI, with variations in the reported location of the mouse depending on where you capture that event. Alternatively there are VIs in Connectivity->InputDeviceControl which allows to query the global mouse position too, but I find that pretty unmaintainable in code, since it is global and you always have to recalculate those positions to more useful coordinates in your VI. Also if you start to clutter your libraries with this kind of global VIs, you can end up with troubles if you happen to use multiple libraries which make use of these VIs.
I do use automatic front panel scaling but never with the scale all objects to screen size. That simply doesn't work and I have yet to see a layout manager which can handle that for more complex UIs like what you can do in LabVIEW other than simple table based views. What I do is employing multiple panes which move towards a specific direction as the front panel resizes and usually one pane, which has a main object, like a graph or table which resizes with that pane, but everything else only moves relative to that object, never is set to resize too. That works fairly well.
Thanks Rolf. That was some interesting discussion on the way the mouse co-ordinates are handled.
But i must admit that today the variations in monitor aspect ratios are far and few as almost all of them conform to the 16:9 format suitable for viewing movies. The 4: 3 format is almost non existent. This makes life easier to develop code on a monitor that has a different resolution than the target monitor but the same aspect ratio of 16:9 - till the time you develop the FP, you change the resolution of your PC to match target and thats it.