Pain with Panes

[CoastalMaineBird]

LV 2018 SP1, Win 7

Having trouble making panes work out

What I want is a window with a fixed vertical splitter- there will be controls on the left which do not resize.

On the right pane, I want a TAB control, which resizes withe the pane.

On one tab is a TABLE, which resizes.  On another tab is a GRAPH, which also resizes. (there may be more tabs later).

The tab shows one or another of these, based on conditions from the controls section.

I don't care whether the actual tabs show or not, I just want to show one item out of several on the right.

When the window resizes, I want the tables and graphs to resize, to take up the entire pane, with scrollbars positioned appropriately.

For this test, I have SCALE ALL OBJECTS WITH PANE set TRUE.

The right pane is set to STICK LEFT and STICK TOP.

I force the TAB, the TABLE, and the GRAPH to have POSITION = {0,0}, so there should be no reason for them to move (is that right?).

Yet, when I resize the window, the table moves its position (notice gap between splitter and table).  Everything is just off, sometimes by a little, sometimes by a lot.

My guess is that it has something to do with integer arithmetic - when resizing, it calculates proportional changes and applies them to integers, which means it loses precision every time.

Am I missing something ?

Is there any way around this?

Here is a <JING> which shows the issues.

I have attached the VI in LV2013 format, if you care to play.

[Intaris]

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=2ahUKEwjRxrG3x97f...

Shameless plug for Wiebe's excellent presentation on how to properly do this kind of thing.

[Intaris]

I have anecdotal evidence that forcing the origin of the objects you want to resize to actually be OUTSIDE the pane which is resizing helps things a bit.  Obviously, this makes many things unworkable, and the logic behind it is lost on me but it's just an observation.  The inability to guarantee a hysteresis-free scaling (The rounding errors you mention) makes the kind of solution Wiebe presents to be very attractive and very powerful.

I haven't done much with it yet, but it seems like a pretty solid approach to the problem.

[CoastalMaineBird]

If I remove the TAB control, and have just the table and the graph on the right pane, things look a bit different, but still not right.

The TABLE, which started at {0,0}, moves around a bit and then "locks in" to a position, where it stays.  Reading the position after it locks in yields {-1,-1}.  Why is that?

The graph seems a bit better, unless you notice that the axis labels, which claim to be "centered" ,actually move around.

<JING>

[CoastalMaineBird]

I have anecdotal evidence that forcing the origin of the objects you want to resize to actually be OUTSIDE the pane which is resizing helps things a bit. 

Well, setting the origin to be {-1,-1} actually makes the table work, so there's another anecdote for your collection...

[CoastalMaineBird]

There seems to be no way to repair the damage that LabVIEW does to the panel, without code.

You can modify the property YSCALE - NAME LABEL - POSITION - TOP, but you have to calculate the position yourself.  To be exact, you need to know the extent of the text label and the position of the plot area top and bottom.

[aputman]

Hello Steve,

I downloaded your VI and mimicked your actions in 2017, changing the VI to Run Mode and I did not see the effect that you show.  I could move the window around as much as I like and the table and graph origin did not move.  So I backsaved to 2012 and I still did not observe the issue.  I wonder if this has something to do with 2013 2018 specifically.  Unfortunately I don't have 2013 2018 installed so I can't check for you. 

Edit: just realized that your version is 2018 and you backsaved to 2013 for forum purposes.