type def automatic changes not being saved in LV2013

[John Lokanis]

I am not sure I can totally prove this but here is what I have seen:

In a large project built in LV2012 and then loaded into LV2013, I recompiled and saved all files.

Now every time I open the project, a bunch of VIs want to be saved because they claim a type def was updated.  I go ahead and save them then close the project and reopen it.  Again the same VIs want to be saved.  There seems to be no way to get them to save the change once and for all.  (Oh, and of course it never says WHICH type def changed!)

After fighting this for weeks I finally opened the project and then opened one of the types defs used in one of the files wanting to be saved.  I nudged the control by one pixel and saved the type def.  I then saved the calling VI.  I closed and reopened the project and now the number of VIs wanting to be saved was smaller (and the one I 'fixed' was not among them).

I then repeated this process with every type def in the project and saved (individually) each calling VI.

Finally, now when I open the project there are no VIs that want to be saved.

 

So, my theory is when LabVIEW converts from LV2012 to LV2013, it changes the type def files and triggers the need to save the calling VIs but for some reason that change is not saved in the type defs so each time I open them, they again convert from LV2012 to LV2013 and re-trigger the change.  By editing them I forced something to permanently alter them into LV2013 type defs and that fixed the issue.

 

Anyone else see something similar to this?

 

ps. I have all code set to "separate compiled code from source file".

 

-John

Oh, and 'mass compile' did not fix this issue.

[mje]

Interesting. I've been dealing with this for years on one of our projects. The project has seen major development bouts in versions 2009, 2011, and now 2013, but also went through the intermediate versions and some of the code is legacy which pre-dates 2009. Only difference with my problem is once saved on a computer it is good-- the full project can be opened/closed as many times as you like without anything appearing dirty. Commit the changes though and update your source on another machine and you're SOL: dozens of VIs (not ctl or lvclass files) give the dreaded and oh-so-helpful "Type definition modified" message. Wreaks havoc on source code control.

I've lost the ability to develop on multiple machines for that project because it's just impossible to untangle the legitimate changes from the the other ones. To allow multiple developers each library is "owned" by a person and never worked on in tandem. Major libraries are pushed not through source code control but VIPM repository updates. I *hate* this solution but I've literally invested hundreds of hours into trying to make LabVIEW work right and have frankly given up.

I have big projects which are fine in LabVIEW, but I also have ones like this. I'm a firm believer in LabVIEW for large application development, but shenanigans like this make it a hard sell at times. I'm at the point in my career where a language is frankly just the grammar I use to get my ideas down. I may be more proficient in LabVIEW now, but that's just because it's been the tool du jour for the last few years. It's the development environment I care more and more about, and I'm not sure NI is winning that battle. To be fair, they have made fantastic advances, and it's not like other IDEs/languages are all rainbows and such.

Anyways, sorry for the rant. You hit a nerve: this is one standing issue I have no patience for and I am a very patient man. Hopefully this reply makes some semblance of sense, it's late and a little hard to proof through lava's mobile interface.

[shoneill]

I'm at the point in my career where a language is frankly just the grammar I use to get my ideas down. I may be more proficient in LabVIEW now, but that's just because it's been the tool du jour for the last few years. It's the development environment I care more and more about, and I'm not sure NI is winning that battle. To be fair, they have made fantastic advances, and it's not like other IDEs/languages are all rainbows and such.

 

^^^^ This a million times.

[ShaunR]

^^^^ This a million times.

Hear, hear.

 

The palettes are hopelessly restrictive and haven't really changed since 2.x. I would like to see dockable palettes that I can attach to the screen edges (and to each other) and be able to create palettes that I can drag and drop primitives onto as a quick favourites for that project. I've had a play with the "Smart palette" and it's good. But not exactly what I would like.

 

Still hate the probe window so much that I'd rather create temporary indicators on FPs rather than use it (especially for strings which you cannot format).

 

And while I'm ranting Are they ever going to fix the greying out during execution highlighting that seems to forget and get confused as to where and what it should grey out.

[hooovahh]

Still hate the probe window so much that I'd rather create temporary indicators on FPs rather than use it (especially for strings which you cannot format).

I can't seem to find the link at the moment but Olivier JOURDAN over at SAPHIR made a String Details custom probe that I've been using for a while that I like which shows hex, and code display of strings.  They have several others here but the string details is not one of them.

 

But I totally agree that the probes that ship with LabVIEW could use an overhaul for things like this, along with properly handling resizing of the probe window.

[John Lokanis]

Thanks for the thread-jack guys.  

I seem to have triggered some deeply suppressed feelings about LabVIEW.

 

Back on topic: I just hope someone at NI can get to the bottom of this and fix it in the next release.   (I did report this to tech support)

[Phillip Brooks]

Have you tried to change something in the typdef other than the appearance? Maybe update the VI Description.

 

If it worked, it could easily be automated with VI Server.

 

It sure sounds like a bug to me...

[LogMAN]

Just out of couriousity, do you use class property nodes in your project and are the VI updates related to them?