parent class wants to be saved after creating child

[John Lokanis]

I have a class that defines a message.  I inherit from this class for all my messages.  The class contains a must override method called 'Execute'.  Every time I create a child of this class and create the override method for Execute then go to save it, it wants to save the parent as well.  This only occurs after I create the override method for Execute.  If I just create the class, save it, change its inheritance and save it again the parent class is not affected.

I have no idea why it is doing this but it is really annoying.  Especially since everything is in version control, I end up having to check the parent out just to save the project.

The reason given for the need to save the parent is 'Item moved within library'.

 

The parent class is in a lvlib.

 

I am running LV 12.0f3.

 

Any ideas?  Is there a CAR for this or am I just doing something wrong?

 

thanks,

 

-John

[mje]

Well done on defining a case that causes this. I wonder if it can be reproduced with an example project?

I've seen this many times over the years but never been able to pin it down to a case that I could post or even ship off to NI. This and similar behavior continue to cause us enough grief with source code control that I still can't fathom working on LabVIEW projects with more than a very small team of developers.

[drjdpowell]

Have you tried recreating the parent “Execute” message from scratch?

[Aristos Queue]

Many people really consider religion for the first time only after they start a family. It can be totally life changing -- a parent starts realizing that promises he has made are going to impact his children, and his interface is no longer his own. It therefore does not surprise me when a parent seeks to be saved in the wake of the creation of the first child.

 

But seriously...

 

No, I haven't seen this behavior in 2012, nor do I find CARs about it. There were CARs about it in 2010 and earlier, but those are fixed (at least theoretically... your empirical evidence suggests otherwise). So if you have a reproducible case and can share your code, please do file the bug report over on ni.com.

[John Lokanis]

I tried to create a simple test case to repro this but I could not get it to show the issue.  But, I can make it happen with my message architecture.  So, I am including a zip of the required files to reproduce it.

Steps:

1. After unzipping the project, verify that all files are read only except the project itself.  (simulates everything being checked into source control)

2. Open the project and create a new class.

3. Save the project (should work).

4. Have the new class inherit from Message.lvclass.

5. Save the project (should work).

6. Create an override method for Execute in your new class.

7. Save the new Execute method. (should work).

8. Try to save the project.  You should get a dialog that says Message.lvclass has unsaved changes.  Do not save it.  Allow the save process to continue with prompts.  It should complete.

9. Close the project.  Again you will be told to save Message.lvclass.  Do not save it.  Allow the project to close.

10. Open the project.

11. Close the project.  Notice that Message.lvclass no longer wants to be saved.  Why?  And why did it want to be saved in the first place?

Here is the project:

Parent Save LVOOP Bug.zip

 

I will send this to NI as well, but wanted to post here in case someone wants to try to repro the issue and confirm it for me.

 

thanks!

 

-John

please do file the bug report over on ni.com.

Can you post the link to report bugs.  I can't seem to find it on the web site.

Have you tried recreating the parent “Execute” message from scratch?

No, I have not tried that.  Just curious why you suggest that.  The method is abstract.  There is really nothing in it since it must be overridden.

[Ton Plomp]

I think AQ means this site: https://sine.ni.com/srm/app/myServiceRequests

 

Ton

[todd]

http://labviewwiki.org/Bug

 

points to:

 

http://ni.com/ask

 

which goes to where Ton pointed.

 

Just mentioning it to see if it affects a LAVA forum search for "Bug Report".

[John Lokanis]

Reported to NI.  Confirmed by the app engineer to be reproducible.  Once they tell me the CAR, I will post it here so other can track it if they run into the same issue.

[JeffP]

Thanks for reporting it. In general, the link that Todd provided (http://labviewwiki.org/Bug) gives a good overview of how to file a CAR. Please do post the CAR number once you get it so I can follow up on it.

[John Lokanis]

I have an additional bug to add related to this.  In this case, it is more severe.  Here are the step to reproduce:

 

1. Create a second project just like the first one in the ZIP above. (Here is one I created: Parent Save LVOOP Bug2.zip)

2. Open both projects at the same time.

3. Note that the shared classes are now locked.

4. Follow the steps above for the first project (creating a child class, adding the override VI).

5. At step 7, when you try to save your Execute.vi method, this will happen:

 

This one obviously causes much more grief when it happens.  The trick to avoid it is to close the other project so the locks go away before you try to save.  But, I think it is related to the first bug because it happens with the same class and the same actions to reproduce.

 

I will be reporting this as well to NI.

 

[Ton Plomp]

Can you inspect what is changed in the saved lvclass file?

 

Ton

[John Lokanis]

Can you inspect what is changed in the saved lvclass file?

Nothing is changed.  It is identical before and after saving.

[Ton Plomp]

I suspect that the file date is changed.

One thing that has always stumped me with a 'get lock' SCC regime is that you need the server to edit the file.

I understand that there's a bug in LabVIEW. A no-op save. But that should not cause any problems. Using the 'read-only' flag is a bad method (IMHO) to control the state of a file. Merge tools are getting better (and NIs LabVIEW merge tool is reasonably good), so one should not rely on the file-date to control the contents of the file.

 

Ton

[John Lokanis]

I suspect that the file date is changed.

One thing that has always stumped me with a 'get lock' SCC regime is that you need the server to edit the file.

I understand that there's a bug in LabVIEW. A no-op save. But that should not cause any problems. Using the 'read-only' flag is a bad method (IMHO) to control the state of a file. Merge tools are getting better (and NIs LabVIEW merge tool is reasonably good), so one should not rely on the file-date to control the contents of the file.

 

Ton

Well, if I check out the file it wants to save and then save it, the date is definitely changed.  But the point is the contents of the file are not changed so there was no reason to need to save it in the first place.  LabVIEW is simply marking it with a false 'changed' flag.

Personally, I do not care for any merge process.  As a solo developer, I have no need for this.  I simply want to backup my code and be able to revert to older versions if needed.

[Ton Plomp]

At first I could not replicate your issue. But I used the Symbio toolkit to change the inheritance and generate the new override VI.

Then I used the standard procedure and I had to resave the VI. The main difference is that the Symbio toolkit does not insert 'Call Parent method'

 

Ton

[Ton Plomp]

One additional follow up.

The issue is with the LabVIEW code creation tool.

When I create manually a VI that is identical to the NI created tool I get no 'Save' message

 

Ton

[John Lokanis]

Interesting.  I had not tried that.  I am still waiting on the CAR#.  I also demonstrated to NI the crash if you try this with the class locked.  So, I hope to see 2 CARs issued.  Let's hope they can get this into LV2013.

[JeffP]

Two CARs were filed by the AE you are working with- 
 

The first issue described with the parent requiring a save after creating a child (in certain circumstances) was filed as CAR 406621.

The second issue where you are getting a reproducible crash was filed as CAR 406658.

 

Thanks again for reporting these.