I have found a situation where the source code of a calling VI should be updated and saved after editing a type def, but the calling VI does not get a dirty dot or prompt for save on close. Worse yet, the cached compiled code seems to get updated, so re-opening the calling VI seems to work correctly... Until the compiled cache is cleared or the source code is moved to another machine!
The situation involves a case structure driven by a type-def'd enum. Follow the steps below with the attached VI and CTL to observe the behavior:
Start with a clear cache:
- Open LV and Tools>Advanced>Clear Compiled Object Cache... Delete
Open Case.vi and Enum.vi
- Verify Run arrow
On Enum.vi
- Edit Items
- Change "K" to "Gamma" (K is the end of a range in the Case structure)
- Note that Case.vi gets a broken Run arrow.
- Save, then Close Enum.ctl
- Note that Case.vi has a solid run arrow, but no "dirty dot"
- Close Case.vi
- Note that there is no prompt for save.
Open Case.vi and Enum.vi
- Verify Run arrow
On Enum.vi
- Remove items "G", "H", and "I"
- Note that Case.vi gets a broken Run arrow.
- Save, then Close Enum.ctl
- Note that Case.vi has a solid run arrow, but no "dirty dot"
- Close Case.vi
- Note that there is no prompt for save.
Open Case.vi and Enum.vi
- Verify Run arrow
Close Case.vi and Enum.vi
Clear cache:
- Tools>Advanced>Clear Compiled Object Cache... Delete
Open Case.vi and Enum.vi
- Verify Broken Run arrow
My belief is that if separate compiled code works properly, you should never have a condition where you can open a VI with a good run arrow, close it, clear cache and re-open it and get a broken run arrow. To me, this implies that the source code and the compiled code are out of sync.
This may seem like an esoteric case, but it is a case we often have in an application we have been using and updating for years. We have always been able to rename and insert/remove enum items following the above process without a problem, until we separated source and compiled code. We know that it is important to save calling VI's after renaming items, before deleting or inserting items. It seems when a calling VI's case structure cannot find an enum item by name, it will use the correspoonding item number. By saving after renaming, we avoid the situation where a named item is not found.
In the past, if the calling VIs were in memory when the enum items were edited, the calling VIs would get a dirty dot and be saved when the hierarchy was closed. I always though the source code was getting updated, but given the behavior after separating the compiled code, I now believe only the compiled code was being updated.
You might think that enums shouldn't be used or edited this way, and you might convince me of that. Nevertheless, it is definitely a bug that a VI that works before clearing compiled cache doesn't work after clearing compiled cache.
I suspect the calling VI with the case structure has stored enum strings in the source code, but that these strings aren't getting updated when editing the enum items in the typedef. As a result, the calling VI isn't getting a dirty dot and the source code doesn't get saved. (or perhaps the strings are getting updated in the source code in memory, but still no dirty dot and so no prompt for save). Somehow, the calling VI's compiled code is getting updated when the enum typedef control gets closed. Reopening the calling VI opens the cached compiled code and everything works fine, until the compiled cache is cleared or the source code gets distributed through source code control to a machine without the compiled cache. The result is code that appears fine during development, but breaks later without any editing.
