project explorer fails with vi (folder displayed as file)

[Balze]

Hi LabVIEW folks,

I have a very strang behaviour of the project explorer. (LV 8.5.1f4)

It has a problem with one of my VIs.

I stripped the VI down till it's in fact empty now, but the problem still exists.

(I have several projects, where i use the original file, so my problem multiplies )

When I add this VI to an empty project, one of my folders (Entwicklung) is not displayed as a folder anymore but as a VI (file).

This seems to happen to the fourth folder above the file.

Additionally: if i copy this file to a location with less then 3 folders and try to add it to a project LabVIEW crashes.

If it's in the third folder,the driverletter is displayd as a file.

The software works fine even in application, but this effect leads to the fact, that I'm unable to save my project to a new location !! (Even the recommended method to save to a prior version and select 8.5 as version does not work)

I have to create a  source-code-paket for a customer the first time now and am unable to do so.

(I always said they will open pandoras box if they provide sourcecode to a customer, but who cares what my opinion is 🙂 I'm just a stupid engineer 🙂

Would please someone be so kind and try to figure out what is wrong with this VI ?!?

I tried allready and suggest it has to do with it's relative path, but i can't see a possibility to acces it directly.

Thanks in advance,

best regards,

Rainer

Message Edited by Balze on 12-08-2009 09:04 AM

[Christian Mergl]

Hi,

I can see kind of a same behaviour in LV2009 with your VI.

When adding it to a new project, the folder "Temporary Internet Files" will be added as a VI under the dependencies. Really weird!

It's still a folder, but the icon in front of the name is the one of VIs.

I never saw this before and have no idea what was causing this behaviour with your VI, so I would suggest to simply create a new VI and delete this one.

Christian

[Balze]

Christian,

thank you for your suggestion.

The original VI is kind of a template for our DAQ-software.

It's the basis for some dozens of applications adapted to the equipment we build.

Thus replacing these VIs is my last option.

I would greatly appreciate if someone finds a solution to this problem.

Best regards,

Rainer

[GabbyG]

This is a good one !

I can confirm, that it happens as well when used in a LV 8.6.1/english version. And I tried to modified all I could find in the Properties/ Eigenschaften.

Another hint: sometimes it helps to open a blank VI and drag and drop the diagram to the new blank. Otherwise, Viel Glück.

Gabi

[Balze]

Gabi,

thank you for your suggestion.

But as I mentioned this problem is part of many dozens of applications (with different releases with this file slightly modified.

I have to copy-paste too many Vis that i would like to go this way.

I would prefer, if someone (NI are you listening?  ) could give me a real (!) solution to this problem and tell me how to fix these files without creating, copying, pasting,....

This problem is definitive part of the VI itself.

I tried to find differences between a new created file and this file in same folder. (Same size, icon, color,...)

But the stripped down VI is still to different to find this particular difference.

Even when i try to look at the resources of this VI i still can't find the problem.

I copied all resources from a new created VI one after the other to find the resource that is responsible for this behaviour, but did not succeed .

Still looking for help, ....

Best regards,

Rainer

[Christian Mergl]

Rainer,

I think you will agree if I say something is wrong with this particular VI. I don't know what it is, but it seems to be corrupted.

As we allready suggested you simply need to copy the code of the VI into a new one, delete the old one and save the new one with the same name under the same place like the old one. I don't see a reason why this should change something in your other VIs or your application, or why this is a lot of work.

Christian

[Balze]

Christian,

I totaly agree with you. This VI is corrupted.

I agree with you that it's possible to copy the code of it to a new VI (Set all properties, set frontpanel to right dimensions, origin, .....) to get a working copy.

I did not say that this will change any depending VIs or this particular application.

My problem is, that we've deveolped dozens of applications with this particular VI as basis. Several releases of each software were build.

Thus there are hundrets of applications build with this corrupted VI.

As I mentioned, there is no problem with it while developing or building applications.

The problem occurs when you try to save a development release for someone else to modify this code.

It's not possible due to the fact, that saving it stops at this folder shown as a VI.

I appreciate your suggestions. But as I would have to do this "create_new, copy, set_properties, .... don't miss anything) process for hundrets of VIs I'm trying to find the real source of this missbehaviour.

If someone with the necessary knowledge could DEBUG this VI and let me know where to turn the bit I would do that with a little fixing tool I'll write on my own.

Thanks, best regards,

Rainer

P.S.: Found 132 "Release 1.0" folder on our server. -> 132 different labview software products with a multiplicity of releases. Some/Most of them with this corrupted VI as basis. Do you see a lot of work Christian ?

[Christian Mergl]

Hi Rainer,

I'm sorry, I still don't get it.

If someone, somehow would be able to make your VI working again, you will still need to do that change with your VI. So I don't see a difference (appart from the more work because of properties and so on) in make a change that it works or copy the code into a new one and save it with the origin name.

Neverthless, there is no way to debug this anymore. I tried some things, but your VI stays corrupted.

You will need to replace it.

Christian

[Balze]

Well,

if someone could give me an information about what exactly is wrong with this file, it's probably possible to fix this with a little tool.

If this is something very clear, like the VI resource MUID must not be 00 00 25 79 but 00 00 26 80 then i could write a little helper, that searches all VIs, check this setting and fix it for me.

This is not only less work, but i can be sure the VIs will work after I changed them because there is not property I missed.

Best regards,

Rainer

P.S.: As I mentioned, there are 132 projects on our server, let's say half of them have this problem and they have 4 releases in the middle. 132*4/2=264

Are you willing to copy, paste, setup, ... >250 VIs the way you mentioned? I'm not!

P.P.S.: Please NI developers have a look inside my VI and let me know what's wrong with it.

Message Edited by Balze on 12-15-2009 12:54 AM

[Norbert_B]

Rainer,

i understand that you are not happy with the current situation.

Since code is saved in files, those files can get corrupted by any means (failed saving, bad sectors on harddrive,...). This is nothing uncommon for all file types. So even VIs get corrupted by chance.

If a VI got corrupted, there are only few things we can do. If you can open the VI and extract the diagram, you can consider yourself to be lucky.....

Your request that NI uses some kind of "Bit-Check" on your VI is impossible to conduct. Since the VI-file contains the frontpanel, the blockdiagram (aka uncompiled source code), the compiled source code and some additional information, the possible layouts for your VI are infinite. Since the VI is obviously still accessable, i am not sure if there are any mismatches which can be found by a simple checksum analysis. Other analysis are (at least due to my opinion) not promising due to the fact that setting up a tool takes much more time than to copy and reconfigure 300 VIs. And still i doubt that such a tool is capable of getting all issues in the corruption so still some VIs can create unpredictable behavior.

Please note that this is again a lesson learned:

Use Source Code Control!

Sorry that i don't have better news/attitude, 

Norbert