Conundrum: typedefs, source control (Git)

[PaulL 89]

Here is the set-up:

 

I have a component project library (StepperMotor.lvlib) that I have moved to the userlib in order to facilitate reuse over multiple projects.  Within the library I have

1) a strict typedef (StepperMotor.ctl) cluster that contains a numeric control for expressing the maximum output step rate.

2) the StepperMotor.lvclass, an abstract class that contains effectively virtual methods (they do nothing but wire inputs to outputs) and LabVIEW-generated accessor methods for the two items in the class private data.

This is LabVIEW 2013 SP1 on Windows 8.1.

 

 

OK, so I start with everything clean (git status reports clean, LabVIEW opens and closes the library without prompting for changes).

1) Then I open the StepperMotor.ctl directly from Windows Explorer (hence not opening the library), change the range of the numeric from 2 kHz to 4 kHz, and save it.

 

 

2) Then I open the library, make no further changes, and attempt to close the library.  LabVIEW correctly prompts me to save changes.  I opt to close the project without saving changes, however.

 

3) Next I discard the change to StepperMotor.ctl using git.  (I have been using Discard in SourceTree, or a git reset --hard command.)  Then git status returns a clean status.

 

4) I open the project and attempt to close it.  Since I have reverted all changes, LabVIEW does not prompt to save changes.

 

So far, so good.  This is expected behavior.

 

Now, I repeat the steps, except that in step

1) I open the library first, open the typedef control from the project, make the same change, save the control (without applying the changes), and close the project (without saving).

2) is the same as above (OK).

3) is the same as above.  Again, git status shows me everything is clean.

4) I perform the same action as above, but this time LabVIEW prompts me to save all the accessor methods on the class, citing a changed typedef (even though if I open the typedef the range is indeed back to its original value).  This is unexpected behavior.

 

Worse yet, even if I perform a git reset --hard and verify with a git status that everything is clean, if I open and immediately attempt to close the project, LabVIEW still prompts to save, citing "Type Definition modified".  This is indeed problematic.

 

(Further note: If I let LabVIEW save the changes, git status still shows clean, and LabVIEW opens and closes the project without prompts.)

 

 

 

 

[shoneill 101]

Do you have compiled code separated?

[egraham 3]

I didn't read this discussion closely enough to see if you were already part of it, but if you haven't read it, I think it touches on your problem. Steven Mercer talks about the differences in typedef behavior between different LabVIEW versions and says 2014 vastly improves upon this.

 

https://decibel.ni.com/content/thread/20339

[PaulL 89]

Do you have compiled code separated?

Yes

I didn't read this discussion closely enough to see if you were already part of it, but if you haven't read it, I think it touches on your problem. Steven Mercer talks about the differences in typedef behavior between different LabVIEW versions and says 2014 vastly improves upon this.

 

https://decibel.ni.com/content/thread/20339

Yes, I have seen that thread.

 

Yes, there is a nebulous promise that NI is working on something, but whether or not it will address this specific issue is unknowable from that thread.

 

I understand the font issue as a cause, but that clearly is not the cause in the problem I have presented.

[PaulL 89]

Note: In post #1 where I have "project" I should have written "library".  In this specific example I only used the library interface, although the results are the same with the project interface.

Another note: LabVIEW wants to save all the accessor methods, even those that deal with the other attribute of the class.  On the other hand, the *almost* virtual methods that are also members of the class have object instances (in and out control and indicator), but LabVIEW does not feel the need to save these.  This may show the problem is with the class private data bundle/unbundle nodes.

[mje 193]

I've seen similar behavior. I managed to isolate a pretty simple example and sent it in with the CAR I quoted in the linked thread.

Paul, I have no advice other than showing it to an AE if you can isolate the code and aren't prevented from giving it to NI. This issue has been an issue for years and the more examples NI can get, the more hope there may be of fixing the behavior.

[PaulL 89]

OK, thanks!  I did submit open a support case yesterday, too.

[PaulL 89]

NI Support said this was a known issue and will be addressed in a future version. CAR  451107.

[mje 193]

Nice. Same CAR. That makes me feel better-- that the problem has been characterized enough such that it has been identified as the same issue in multiple requests.