config data refnums invalidated by for loop

[Larry Trout]

I have found the following problem with LabVIEW 7.0. This only occurs when running the application as built with the application builder and does not appear to be a problem in the development environment.
Given an open refnum for a config file one can loop through several read key operations while passing the data and the refnum to outputs on the for loop. If you disable indexing on the refnum output of the for loop you should get a usable refnum out. What happens instead when you try to close the refnum is an error indicating that the refnum is invalid. If you simply route the refnum around the loop avoiding the for loop output altogether this doesn't happen. It appears that somehow, going through the indexing output of the f
or loop invalidates or changes the refnum when in a built application using the runtime.
If anyone can reproduce this or prove me wrong it would be helpful. This bug cost me days of chasing down why my "major app" would only work when in development but fail when built. The lack of debug capability in a built app of course leant to the effort that it took to track this down.
Thanks,

[Mads]

From the description you give I made a test application to see if I could recreate it. I could not.

Check out the attached example, is this what you do and have a problem with? If not, could you post the code here? Or a picture of it.

[Greg_McKaskle2]

> I have found the following problem with LabVIEW 7.0. This only occurs
> when running the application as built with the application builder and
> does not appear to be a problem in the development environment.

I think the problem is that the inputs to your loop are causing it to
run zero iterations. When a loop runs zero iterations, the outputs are
the default for the datatype. For refnums, this is equivalent to the
invalid refnum.

I suspect the problem doesn't only occur in the executable, but occurs
whenever the loop executes zero times. It happens in the exe because of
a directory or other input to it.

The upgrade notes for LV6 or 6.1 mention that the behavior of loops that
run zero iterations is now better defined. Once upon a time, the loo
ps
that ran zero iterations would output the values of some input or the
values of the last time the loop was run.

Anyway, the right way to wire this is either around the loop or through
a shift register.

Greg McKaskle

[Larry Trout]

You are correct. Upon further pondering I realized that the number of iterations that my loop was making was actually zero. In this case the output terminal for the refnum had no data. It was not the runtime that caused the problem but rather the lack of any iterations through the loop that made my refnum invalid. This is a subtle but easy to make programming error. Never depend on the output terminal of a for loop if the for loop can iterate zero times.
Sorry for the false alarm and thanks for checking this for me.

[Larry Trout]

Thanks, Greg.
You are absolutely right, here. I thought of this just this morning as I was getting ready for work. The loop indeed was running zero iterations because the config file that I was reading had no elements in it (the number of elements was used as my number of iterations).
I used the shift register approach as a "work around" and, behold, it is a very correct way to handle this.
Thanks for your advice.
Larry Trout

[Ikoria]

Hello, i'm french so scuse for my writting...

I don't find where put this question so i writte here.

I want to do a soft who's objective is to writte config data (open config data + write key + close..).

you can find it in the join piece.

this soft run correctly but when i do an exe with the application builder, when i try to run the exe, that saying me error 7 about the Nex file in Open config data...

How can i solve this problem???

Tanks for all....

[Dennis_Knutson]

When you're in the development mode, the path to the VI is something like c:\folder\example.vi. When you build the executable, the path becomes c:\folder\example.exe\example.vi. To get to the folder, you have to do an extra strip path. What I would recomend you do is add the Application property App.Kind. This will return either invalid, Development System, Run Time system, Student Edition, Embedded, Evaluation, and Custom. Wire the output of the property node to a case statement and if Development System, do the strip path. You VI should then work in both development and run-time modes.

[Ikoria]

Thank for your light but i don't understand all you say...

1)what is App.Kind, and where i found it?

2) the path of the config data is create in the same folder of the VI (see my VI: chconfexe.vi in my latest message)

3) What is an EXTRA STRIP PATH???

Scuse me for my english but i'm french and i think i don't writte english very well...

[Ikoria]

Year, i win, i have understand my error!!!!

Ihav to do the exe in the folder who contain the under-folder where is the Vi:

explain:

Vi is in a folder B. Folder B is in a folder A. The exe of the Vi must be creat in the folder A!!!

Thanks a lot for your light....

Iko