Programmatic Access to the Explain Changes dialog?

[TimVargo]

Does anyone know if there exists a property or method that would give me access to the same information that is within the Explain Changes dialog?  I am referring to the dialog that displays when you press the "List Unsaved Changes" button, on the VI Properties dialog.  The information I desire is the "VI List" of items that are marked as changed (docmod) in an entire project, along with the list of "Changes" for each of those items.  The "Change details" is not important to me.

 

I know that there are already the Modifications:*** Mods Bitset properties; but these appear to provide only a yes/no as to whether a VI is dirty or not, without the additional explanation as to WHY, which the Explain Changes dialog provides.  It is that list of changes that I truly need.

 

Ultimately, I wish to obtain a list of all VIs that are marked with "Type Definition modified", and then attempt to analyze that list for what TypeDefs they all have in common.

 

[mje]

I have no answer for you, but like the idea you have. "Type Definition modified" is a very annoying bug. Any insight into what triggers the behavior would be welcome.

[dannyt]

I am sure there was something for this. At my previous company before the separate source and compile code option existed I used a scripting property to check the  Modification bits to look for VI's that only had "recompiled" as their change. Cannot remember what I did thought.

 

 

EDIT Just found it, I would list all the files in a directory then open one VI at a time in edit mode and then there was a property values of the VI showing  "Modifications -> Block Diagram Mods Bitset" ,  "Modifications -> Front Panel  Mods Bitset" and "Modifications -> VI Panel Mods Bitset".  I had to play around a little to find out what the values meant but I did get it working

[TimVargo]

Thanks for the insight dannyt!  I did know about the properties that you mention, but the limited help text on them led me to (falsely) believe that they provided only a binary answer.  I see now that they provide much more than that, but it is totally undocumented.  I have two questions to see how good your own memory is. 

1. If I place one of these properties nodes onto the block diagram of the VI to be inspected, and wire a "This VI" Generic VI Reference to that, it works fine.  I of course don't want to open every VI that I wish to inspect, so I instead use the Open VI Reference function then feed that reference into the same property node; but then the output of these properties are always zeros.  Do you recall how you got it to work?
2. I will reverse-engineer the bitset mappings if I have to (it appears that there are AT LEAST 81 of them); but if you already did that, and still have even a partial list, then it would save me a lot of time if I could get a copy from you. 

[dannyt]

I never did a full list of the bitset mappings I found what I wanted and left it at that, I did find this on the web  http://sthmac.magnet.fsu.edu/LV/ILVDigests/2003/12/06/Info-LabVIEW_Digest_2003-12-06_003.html that might help you, but it may well be different for different LabVIEW versions.

 

I cannot get to grips with your idea of putting the property within the VI's you are interested in, it does not sit well with me the idea of putting in code that does not really have anything to do with the function you want your VI to do, maybe that just me.

 

You are doing something harder than my recompile check, in my case, one or two VI's that actually needed to change would be edited saved  and closed.  These VIs would then be committed to the source control system with a comment about the change just made. Then by running the tool VI  I could get a list of all the VI;s that the original edit has caused to recompile and these could be saved and committed into the source control system with a comment saying they were recompiles. The nice thing in my case was all the VI's were closed when I ran my tool.

 

 

 

In your case I think you want to get a list of files in memory and then look at them all one at a time

 

 

 

[TimVargo]

dannyt,

With your help, I now have a good handle on this.

>> I cannot get to grips with your idea of putting the property within the VI's you are interested in <<

Oh that was just a diagnostic, to see if I was calling the functions properly (since the calls from my tool were not returning expected values) -- Indeed I would not want to do it this way for real. The diagnostic was useful however, because it pointed out the flaw, and I have since resolved that problem.

Yea, I too will build the bitset mapping only to the point of the elements that I need. Manually mapping out all 128 possible bits would be a monumental task. And thanks for that link; I will add to my spreadsheet the ones that Rolf figured out. If you wish to contribute, just send me the ones that you figured out and I will add those as well; and then I will attach the aggregated info (although still very incomplete) to this discussion, to possibly help others.

[TimVargo]

As promised, here is an Excel spreadsheet which maps out (some of) the meanings of the different bits returned by the three VI Server properties:

• VI Modifications Bitset
• Front Panel Mods Bitset
• Block Diagram Mods Bitset

I credit Jim Kring and Rolf Kalbermatter with doing the heavy work of discovering most of these way back in 2003 (I figured out only one all by myself ), I merely organized their findings into this spreadsheet.  As pointed to by dannyt, the original information source is here.

 

Still, only 19 out of somewhere between 81 and 128 bits have been identified, so anyone who has ever figured out more of these is encouraged to update this spreadsheet and re-post it.  Besides the Code Repository for source-code, does LAVAg have a better file sharing mechanism for sharing non-code files, other than just attaching them to discussion threads?  If not, do we have a preferred cloud service?  I would be willing to host this spreadsheet on my personal Google Drive, if that would be helpful and appropriate.

LabVIEW Mods-Bitset Mappings.xlsx

Edited March 3, 2015 by TimVargo

[dannyt]

You could add the information to the LabVIEW Wiki at http://labviewwiki.org/Home ,  I am never quite sure if this site is related to LAVA or not.