LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

programmatically adjust object's position/size while resizing a labview window

Trevor's summary nails the graph re-sizing issues in LabVIEW.  In addition, if you have not shut off the Autoscales property for a Graph, and Graph Object may resize automatically at run time due to changes in the signals creating changes in the Y scale. For example, much larger signal values require more space for the Y axis scale text, hence the Graph Object will re-scale.

As far as I know, the Autoscales property cannot be set programmatically but only via the Front Panel of the object(Advanced )

 

As to applications for the desired behavior:  First of all, end users expect the application to be able to run on PCs with different screen sizes and still look good.  This is a standard expectation for Windows applications and is quite is not easy to do "pixel perfect"in LabVIEW.

 

 

Secondly, it is reasonable to have applications where you have multiple graph objects in one window, and that these can be individually scaled.  In our concrete application, we four graphs in one window arranged in a two by two matrix.  Each graph has associated controls that must move with it when the graph size is changed.  It is an end user requirement to make any of the four graphs be set to full size, or to let any of the graphs grow from half width to full width.    We have spent a fair amount of time trying to make this work "pixel perfect" and seen all the same issues mentioned in  this thread.  We have also tried using splitter panes, and here run into another set of issues.

 

The problem could be solved by following all of Trevors suggestions (which we already have learned the hard way, thanks anyway Trevor), plus turning off the "Autoscales".

 

Only recently have we discovered the Autoscales property, and that makes it possible for us to solve the remaining issues.  However, I cannot overemphasize Trevors recommendations!  In addition, we rigorously initialize each objects position/size thus getting around the risk of messing up the carefully manually positioned controls. 

 

Finally, a prayer to NI to re-work the multiple issues related to Graphs, would also be appropriate. Trevors list is a good starting point.

 

Carsten Thomsen

0 Kudos
Message 21 of 24
(5,597 Views)

CarstenPXI wrote:

 

As to applications for the desired behavior:  First of all, end users expect the application to be able to run on PCs with different screen sizes and still look good.  This is a standard expectation for Windows applications and is quite is not easy to do "pixel perfect"in LabVIEW.

 

It is not just not easy in LabVIEW but in any programming environment. Most do not even support autoscaling and if they do they produce just as horrid results for complex panels. The only thing that can and does work is when you limit the resizing to one single control and let the rest only move along. This is the same for other environments and when you look at typical applications you will notice there is usually one element in the application screen (table in Excel, text area in Word, etc. that scales but not everything else.

 

If an application does more complex scaling it is always doing so programamtically since there is no way automatic can resolve the various contradicting requirements that arise out of such a situation. This is a pain to do, I know it and there are issues in LabVIEW that certain controls do not easily allow to be resized since they do not expose an according property.

 

But apart from this NI can invest man years of development into a better multi object automatic scaling but it will never be perfect for anyone and in fact will always have deficiencies in one way of the other.

 

I rather see them invest the time in exposing size properties for every control properly. For now I have resolved to use an undocumented VI I have found somewhere that allows to control the bounds size of most controls. It works in LabVIEW 7.1 and apparently higher but I have no idea of its dirty inner tricks and would recommend to always use the properly exposed property instead whenever possible. This is totally unsupported both by me and NI! Smiley Very Happy

 

Rolf Kalbermatter

Rolf Kalbermatter
My Blog
Message 22 of 24
(5,586 Views)

Thanks Rolf,

 

I agree with you that it is not easy in any environment, and my only prayer, as you suggest, is that NI make available all the necessary hooks to be able to do it predictably and programmatically.   My main issue is the lack of ability to programmatically scale the bounds of a LabVIEW object, and I will look at your VI with great interest.  In addition, that some properties are only available via the front panel and not the diagram, is unfortunate.  It is our experience that for large applications, it is safest to explicitly programmatically initialize every important property, and not rely on front panel defaults, which is too vulnerable to unintended side effets.

 

In addition, there are a number of other maintenance issues associated with graphs and cursors, that could stand a clean-up.  I understand NI invested about a man year in the previous release working on this, but in my opinion it still needs some more work along the lines the Trevor lists.

 

Thanks again!

 

 

Carsten Thomsen

 

 

0 Kudos
Message 23 of 24
(5,570 Views)

I have just tried the CTRL Size Front panel object in LabVIEW 2009 and it seems to work fine.

 

Carsten Thomsen

0 Kudos
Message 24 of 24
(5,469 Views)