LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bug (?):Table Edit Position property

Hi,

 

I found a problem in LV2009 regarding tables:

The property "EditPos" behaves different to older LV versions. The new "EditPos" will only give the current text entry when the table has focus, whereas the "OldEditPos" (property, when upgrading older LV code) will give correct results even without focus to the table.

The problem is illustrated in the attached example: start the vi, select any cell in the table, then click "get pos"...

 

This is quite annoying and hard to find for upgraded vis...

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 1 of 12
(4,973 Views)

Hi,

 

thank you for your post to our forum!

 

i tried to comprehend what you have described.

 

Could you explain which behaviour do you expect more precisely, please?

Do you have an LV8.6 example to point out the differences you mentioned?

 

Best Regards,

 

Peter

0 Kudos
Message 2 of 12
(4,940 Views)

Hi Peter,

 

the point is:

Before LV2009 the "EditPos" table property has always given the last active cell of the table, regardless of focus to the table or not. Now with LV2009 I get a result of [-2,-2] with (new) "EditPos" when the table hasn't focus, whereas the "OldEditPos" still delivers the last marked cell. This is shown in the example.

 

The problem occurs in the following way:

We have a table. The user marks a cell in the table, then clicks a button "Insert row". With new "EditPos" we get a wrong cell index to insert (i.e. no insertion will occur because of index -2), whereas the "OldEditPos" delivers (and always had delivered) the index of the marked cell. Surely there are workarounds, but in the context help this change of property behaviour isn't documented! The only documented change are the new possible output values of "-2". For me the behaviour of the new "EditPos" is a bug...

 

I have to correct my complaint just a little bit:

The "OldEditPos" is inherited from LV7.1. So the behaviour changed from LV7.1 to LV8.x. I noticed it now in progress of upgrading a program from 7.1 to 2009. See example in LV7.1.

Message Edited by GerdW on 10-02-2009 11:06 AM
Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 3 of 12
(4,938 Views)

Hi Gerd,

 

thanks for your fast response.

 

Now i could reproduce the behaviour.

 

To ensure that i understood your concern correctly:

 

The function OldEditPos gives you the desired functionality in LV2009,

but there is no sufficent documentation about the changed functionality of EditPos?

 

Regards,

 

Peter

0 Kudos
Message 4 of 12
(4,922 Views)

Hi Peter,

 

either

  change the documentation to clearly say "(New)EditPos is only valid when table has focus, otherwise you get [-2,-2]" (just a bad workaround in my opinion)

 

or (my preference)

  (New)EditPos should have the same behaviour as OldEditPos always had, so it's a one-to-one replacement!

 

Can you post a tracking number (like CAR) when there is one?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 5 of 12
(4,920 Views)

Hi Gerd,

 

i'll keep you current!

 

Regards,

 

Peter

Message Edited by pete_sch on 10-05-2009 02:01 AM
0 Kudos
Message 6 of 12
(4,877 Views)

Hi Gerd,

 

if you open your LV7.1 VI in LV2009, the EditPos function will automatically change to OldEditPos.

 

So i think this is our way to let programmers know that there is a change in functionality.

 

Regards,

 

Peter

0 Kudos
Message 7 of 12
(4,863 Views)

Hi Peter,

 

then please change the context help to state this change in functionality too!

 

At the moment the context help is exactly the same (apart from single sentence "Values of (–2, –2) indicate that no edits are being made to the text of the control." for (new)EditPos). The change of functionality also isn't mentioned in the detailed help (of EditPos) - and there is no detailed help for OldEditPos. From current description the only change is just a new possible output value!

 

"this is our way to let programmers know that there is a change in functionality"

You don't mean this seriously, don't you? There are far more (and better) ways to tell "it's new functionality" apart from the function name...

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 8 of 12
(4,858 Views)

Hi Gerd,

 

i'm in complete agreement with you that there schould be a more prescise description for the new EditPos property.

That's why I added a CAR about this issue. (#190142)

 

What i meant with letting the programmer know that there was a change in functionlity is for the portation from LV7.1 to LV2009. If the property will have a changed behavior but the name remains the same you maybe wouldn't recognize the change.

If the name changes you're able to recognize it immediately.

 

 

Regards,

Peter

0 Kudos
Message 9 of 12
(4,846 Views)

GerdW wrote:

 

"Values of (–2, –2) indicate that no edits are being made to the text of the control."


Doesn't this describe what you are seeing? If you don't edit any cell the value of the property will be (-2,-2). If the table doesn't have focus it can't be currently edited so the property returns (-2,-2). The correct name of the property with the old behavior should probably have been "LastEditPos" or so.

But I completely agree documentation could be improved.

And I think it would be nice to still have a property with the old behavior (not only by upgrading old VIs).

 

Daniel

 

0 Kudos
Message 10 of 12
(4,832 Views)