INI file functions don't work in EXE on on some devices

[billko]

---

@David_R._Asher wrote:

Unfortunately I only had access to the tablet where the error shows up for a short time.  I was kind of hoping someone else had seen similar behavior with INI files or queues not working in executables on some devices.  If I can get the tablet back I'll give that a try.

Thanks!

---

Oh, I see.  Unfortunately, I haven't seen this issue specifically related to specific targets before.  I wish I had more helpful ideas.  If you could keep us updated on what you find, I'd be very interested.  I never pass up an opportunity to learn from someone else's experience!

[crossrulz]

---

@David_R._Asher wrote:

 Apparently it dequeues this cluster of path, boolean, and 1D array of clusters of strings and a 2D array of strings.

---

Just to clarify for everybody...

The INI functions actually use a Single Element Queue to store the data.  It is an old-school way of doing a DVR.  There are just type casts inside of the INI functions to convert the reference between a Configuration Refnum and a Queue.

So the fact that you are getting an error code 1 tells me that you have an invalid reference.  This implies something went wrong when trying to open/read the configuration file.

[rolfk]

---

@crossrulz wrote:

---

@David_R._Asher wrote:

 Apparently it dequeues this cluster of path, boolean, and 1D array of clusters of strings and a 2D array of strings.

---

Just to clarify for everybody...

The INI functions actually use a Single Element Queue to store the data.  It is an old-school way of doing a DVR.  There are just type casts inside of the INI functions to convert the reference between a Configuration Refnum and a Queue.

So the fact that you are getting an error code 1 tells me that you have an invalid reference.  This implies something went wrong when trying to open/read the configuration file.

---

Indeed. Either the Open Ini file failed or the top level VI in whose hierarchy this was called has terminated. Being a real refnum behind the scenes it has the same life cycle rules as all refnums in LabVIEW. The refnum dies as soon as the top level VI dies, in whose hierarchy context the Create/Open Refnum function was executed. If it is not the Open INI itself that fails, because the path it is told to open points to an invalid location or you forgot to open it for read-only while you have no write access to that file, it must be something in front of it such as your path builder logic or similar whose error out prevents the Open INI to work. And since Opening INI always works (right?), who is checking its error output? 😀

[tst]

---

@crossrulz wrote:

---

 This implies something went wrong when trying to open/read the configuration file.

---

Or that there is actually a race condition (CLAs are not exempt from making mistakes) and the reference is closed before it's actually used (by explicitly calling the close VI, by being created in another hierarchy which is stopped, etc.). It's certainly possible the tablet behaves differently from other computers (fewer cores, etc.) and that's why it manifests there.

Ultimately, without seeing code, we're just playing guessing games. Even if the tablet itself is inaccessible, looking at the code could help figure out the issue.

[billko]

---

@tst wrote:

---

@crossrulz wrote:

---

 This implies something went wrong when trying to open/read the configuration file.

---

Or that there is actually a race condition (CLAs are not exempt from making mistakes) and the reference is closed before it's actually used (by explicitly calling the close VI, by being created in another hierarchy which is stopped, etc.). It's certainly possible the tablet behaves differently from other computers (fewer cores, etc.) and that's why it manifests there.

Ultimately, without seeing code, we're just playing guessing games. Even if the tablet itself is inaccessible, looking at the code could help figure out the issue.

---

I'm sure that looking at the code will narrow it down to a few places to look for where the issue could arise.  Once you figure out where it could happen in the code, it's a short jump to figuring out why.

[Yamaeda]

Is it compiled or source distribution? I had a similar error on a source dist since that VI has separated compile code and that account couldn't access the compile cache.

Compiling to an .exe or making a lvlibp solved it.

[JÞB]

David,

The fact that you are encountering a likely race condition accessing a simple configuration file gives me pause.  Not in your skill but, perhaps pointing to a poor architectural choice.  To put it bluntly your ini smells like a "God Object" from over here.  Likely consisting of (essentially) a "Supercluster" of Clustersaurusii containing parameter settings for vastly unrelated components. In fact, that simplification is a "Natural" format for Sections of Key-Value pairs.

When you have such a "God Object" its easy to make the mistake of accessing it from multiple unrelated areas and there is really no "Priest" to pray to that god on behalf of the separate components that require its intervention.  If you do not have an "Open once Close once" paradigm for the ini file you risk the wrath of the "God Object."

Break up the configuration into configure for <components> and access those through action engines or even class configuration accessors. 

[David_R._Asher]

In response to all of the inquiries:

Here is a screenshot of the VI that handles the INI file functions.

All the code is compiled into an executable.

I wish having a CLA gave me immunity to mistakes.  😃

Thank you!

[billko]

edit decided probably not.

[JÞB]

DING!

I doubt that this vi is the only one opening and closing a reference to the configuration queue.  I'll support that assertion by stating that writing a config file is usually not done unless some other place is reading the same file.

A quick turn to an AE with Open, Read to FP, Write from FP and Close actions with the reference as the private data (on USR or FBN) kills any chance of a race.