Bug report: Controls in the Data Entry property page reset when using relative time

[tst]

1. Create a blank VI.
2. Drop a numeric control.
3. Right click and select "Display Format".
4. Change to a relative time.
5. Switch to the "Data Entry" tab page.
6. Uncheck the "Use Default Limits" boolean.
7. Try changing the values and you will see that they return to their previous values (inf, by default). This persists even after pressing OK and opening the dialog again. It looks like the values are held in a cache and put back into the controls, since if you change a page and go back to the limits page, it shows the correct values. I also managed to get it to display the values using the correct format (relative time), which I assume is what it should be doing.

This is in LabVIEW 8.6.

[smercurio_fc]

I think the problem may be that it wants the values entered in a specific format. For instance, if I enter "03:08" for Maximum, it accepts it just fine. If I enter "999999" it won't. This sort of makes sense given the format.

Note: I tried this on LabVIEW 8.2. Have to get my 8.6 back up and running again before retesting in that. 

Message Edited by smercurio_fc on 03-01-2009 08:11 AM

[tst]

But I'm fairly sure it did work yesterday - I entered 7, it changed back to -inf, but when I switched to another page and back, it did display 7 (or 00:07, I don't remember which). Also, there was a case where the format in the control was changed automatically (as it probably should). I assume that whoever looks at the code can spot the problem easily enough (and I think I have a reasonable guess as to how the code is structured and why it does this).

[RavensFan]

I will bet that this is a bug and it is related to this one.  Data Entry Maximum and Minimum affects all objects on front panel?

[tst]

Well, it's in the same code, but I doubt it's related, as you say you saw this in 8.2 and the other bug seems to be only in 8.6.1.

[RavensFan]

---

tst wrote:
Well, it's in the same code, but I doubt it's related, as you say you saw this in 8.2 and the other bug seems to be only in 8.6.1.

---

I think you're right.  I think I mis-read Smercurio's post that he was confirming that same behavior existed in 8.2.

[Robbob]

I spent some time playing around with this in 8.6.1, and at this time do not consider it a bug - unless there is something I completely missed.

When you set to relative time, the inputs for data entry are expecting HH:MM or HH:MM:SS, depending on which display setting you chose.  Typing a '7' is undefined - does the user mean hours? Minutes? Seconds? Parsecs ?

Once we type in a value that matches the format and we get the display to change, it is true that from now on if we type '7' in the field, it will automatically coerce it to 7:00, if we type 36 it coerces to 36:00.  If we type 7.5, it does not change the value at all.  I think at this point, the user knows what is going on, so this behavior is acceptable.  After accepting the changes and re-opening the properties window, the limits are persistent.

I was not able to reproduce typing a '7' in the limit, having it automatically coerce back to '-inf', then going to a different tab or clicking ok, and coming back and seeing it as 7:00. It was still '-inf'.  If you have some more details on this, maybe I can reproduce it, but from everything I tried, users are be able to enter values and these values are saved.

Edit - I am aware of the other forum post and the CAR filed there...

Message Edited by Robbob on 03-03-2009 11:20 AM

[tst]

The correct behavior should be for LV to change the formatting of the field when the format is changed.

Try this:

1. Drop the control.

2. Change it to U32 from the right click menu.

3. Open the Display Format dialog and change to relative time.

4. Go to the Data Entry page and uncheck the Use Default Limits checkbox.

In 8.6 this causes the limits to change their format automatically, as they should. This doesn't happen, however, if the numeric is a DBL.

I'm not sure how I got the format to change after changing pages, as that was when I first ran into this and I wasn't keeping notes. I didn't manage to recreate this.

[Robbob]

tst,

I went back into LV to do some more testing of this, and ran into this: http://digital.ni.com/public.nsf/allkb/765EBEBE6568CB098625756700718B66?OpenDocument  (All zeroes on the inputs since I deleted my original control...I am using 8.6.1)

I am tempted to grab an 8.6 image and try and replicate this since it seems interesting, but based on the problems already catalogued for the data entry tab, I would say that R&D is well aware of the problems and will get it working for us in a future release.  I will be involved in the LV2009 beta testing, so I will be sure to check this out for us.  I'll keep you posted if I find something, but this other known issue with 8.6.1 is making it very difficult to do any testing.

[tst]

As I already said, this seems unrelated, as the KB article describes a new problem and this one has been around since at least 8.2. Unless the developers are told about it, they might not fix it and will definitely not check to see if it's fixed.

It is possible that this is already resolved in either 8.6.1 or the beta, but I can't tell since I don't have either of them currently installed.