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.

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.