strange 8.0.1 behavior-runs when broken arrow clicked

[Jon Sweeney]

Has anyone seen this behavior before?

I was building a front panel for a subvi with a table and several enums on it.

When I tried to save it, the asterisk that indicates changes would briefly flash off and then appear again, no matter how many times I tried to save it,

PLUS one of the enum controls would occasionally dim (as if it had been changed and the changes had not yet been applied. But if I clicked on it, it would be okay again,

PLUS the Run Arrow became broken (possibly because of the dim enum).

When I clicked on the broken arrow, the vi started running and could not be stopped by the "Abort Execution" (stop sign) control or "ctrl-."

Turning on Execution Highlighting showed nothing; looking at the hierarchy window showed no green execution arrows.

I tried to close LabVIEW but got a neverending "Resetting vi" dialog.

I finally just had to abort LabVIEW using the task manager and lose my table changes.

This happened after a fresh reboot that I did, after noticing the save/asterisk problem the first time.

Befuddling. At least it hasn't happened again, yet.

[metin]

Has anyone seen this behavior before?

I was building a front panel for a subvi with a table and several enums on it.

When I tried to save it, the asterisk that indicates changes would briefly flash off and then appear again, no matter how many times I tried to save it,

PLUS one of the enum controls would occasionally dim (as if it had been changed and the changes had not yet been applied. But if I clicked on it, it would be okay again,

PLUS the Run Arrow became broken (possibly because of the dim enum).

When I clicked on the broken arrow, the vi started running and could not be stopped by the "Abort Execution" (stop sign) control or "ctrl-."

Turning on Execution Highlighting showed nothing; looking at the hierarchy window showed no green execution arrows.

I tried to close LabVIEW but got a neverending "Resetting vi" dialog.

I finally just had to abort LabVIEW using the task manager and lose my table changes.

This happened after a fresh reboot that I did, after noticing the save/asterisk problem the first time.

Befuddling. At least it hasn't happened again, yet.

yes, i have seen at least the save/asterisk problem before, using 8.01 on linux. it appears after copying and renaming strict type definitions and the VI that contains these controls using a console. after loading the VI, the save/asterisk problem appears. a workaround that works for me, is to open the renamed type definition, change e,g the label and save it. the VI can be saved without any problems.

hope, that helps.

[Adam Kemp]

yes, i have seen at least the save/asterisk problem before, using 8.01 on linux. it appears after copying and renaming strict type definitions and the VI that contains these controls using a console. after loading the VI, the save/asterisk problem appears. a workaround that works for me, is to open the renamed type definition, change e,g the label and save it. the VI can be saved without any problems.

hope, that helps.

I could not reproduce that problem in either 8.0 or 8.2 in Linux using the steps you listed. This is what I tried:

1. New VI.

2. Drop numeric control.

3. Customize control.

4. Make the control a strict typedef

5. Apply changes.

6. Save both the control and the VI.

7. Close both.

8. Rename both

9. Open the VI.

When I opened the VI, it searched for the control. If I chose the new name for the control, the VI was "good" (no broken arrow) and the VI had a doc mod (the asterisk). This is correct behavior. If I chose to ignore the control, then the VI was broken and had a doc mod (also correct).

If you have another way to reproduce this problem every time then let me know.