table cell shifting issue

[Zwired1]

Getting a wierd within-cell selection indicator shift effect when using tables in LV 2013(32) on Win 7 (64).   Hestitate to call it a "scroll" 'cause that has other meanings in the table context.

Click on the letters in the attached VI to see it -- same effects if the table is in a running VI or not.

          + clicking on "A" does nothing.  Deleting "A" causes the cell to shift.

          + clicking on any of the cells below "A" act like the above

          + clicking on header cell "x" causes a big sideways shift.  Putting other values in the cell has other effects (some shift a lot, some not at all)

          + clicking on table cell "y" causes a big sideways shift.  Putting other values in the cell has other effects (some shift a lot, some not at all)

          + clicking on table cell "z" does not shift.  Deleting "z" causes a big sideways shift

          + I noticed the shift that happens when you delete "A" stops at the same horizontal location as if you 

Observations:

          + Appears to be tied to cell's justify=center. 

          + Shifting is always is right-to-left.

          + I noticed the shift that happens when you delete "A" stops at the same horizontal location as if you click on "y"

          + occurs on at least two different machines from different mfg's.  Both running 2013-32 on Win7-64.

[altenbach]

I can reproduce it here. Very strange. Looks like a bug. I amazed by the cute animation of the movements. 😄

Are you saying this worked diffferently before LabVIEW 2013?

[Zwired1]

Can't say as I ever tried it before LV2013. I have 2011 and 2012 avail, will try shortly.

What OS/LV are you running?  Trying to build up a complete story.

[altenbach]

I am on the same: 2013-32 on Win7-64.

[Zwired1]

I was unable to recreate using 2012(12.0.1f5) on same Win7-64 machine.  Not 100% conclusive as I'm not sure what's required to create the issue and so may not have met all the requirement on this go-round. Say 80% it does not happen on a 2012 install.

Other tidbits:

   + I select a cell and click on justify center ( rather than selecting the whole table, for instance)

   + I've typically applied the justification change after the manual drag-the-edge-of-the-cell resize

   + bug does not require header row to be visible

   + programmatically setting the active cell, selection start (with a 1x1 selection size), or edit position to one of the affected cells does not trigger the animated shifting

[elset191 · Accepted solution]

In case you are still interested, see message 5 in this thread.

[Zwired1]

That's it!  Thanks for tying up a loose end on an old thread.

With this information I was able to recreate this in LV2014-32 on Win7-64 so it's still a bug. 

The key is the table has to span quadrant 3&4 of the front panel. 

Drop a table control with (left,top)=(-108,185) for instance and (width,height)=(250,169).  Select the entire table and set justification=center.  The first column whose center is to the right of the front panel's "y axis" will have centering issues.  Move the table off the y axis and the issue goes away.  Move it back and issue comes back.

Having left or right justified prevents the issue but this is a Band-aid, not a fix, and was not applicable in my case as my UI needed centered text or it would look funny.  I was using the table to display info and allowing the user to click on a cell to select it, at which point I would change the color via property node.  My workaround was to change control focus immediately after the mouse click to minimize the time the drifting cell was noticeable. 

[RavensFan]

Is there a reason why you don't shift all the controls in your front panel so they exist in the same quadrant?  Make sure the 0,0 origin is to the upper left of every item in the front panel.

[Zwired1]

Up until ealier this morning I did not know the table location was related to the observed symptoms.  A year ago, my focus workaround was all I could think of to get me something I could deliver.  It worked well enough but should not have been required.  

I opened a formal bug report this morning (Reference#7425807) as this appears to have been around since at least LV2009 and I just recreated it in LV2014.

[RavensFan]

Please don't get me wrong.  I didn't mean to say you should have moved the controls back then.  It's true that this connection being connected to the table's location on the front panel didn't come to light until today's thread that Tim linked to.

It's good that you reported this as a bug.  I haven't been able to find any other threads that talk about this and show that it has been assigned a CAR# by NI so the bug can be tracked. Hopefully that will occur now that the new thread has come to light, and your thread has been revived, and you've reported the bug.

It looks like you found a good enough work around at that time to be able to move on with your project.  I think I might have misread your recent post and thought that you just solved your problem now by changing focus (as opposed to that being your solution a year ago.)

I think if you are still working with this code, or have a need to change it, or if you or anyone comes across this problem again, the better solution is to move all the controls on the front panel.