Rube Goldberg Code

[altenbach]

A common task is to generate a path to a file (e.g. ini) that is located right next to the VI or exe.

Here are two possibilities, the top one was seen here.

Top:

• Hard to debug and reconstruct from memory in the future.
• Breaks after building exe
• Breaks on any other OS.

Bottom:

• just works!

[Andrey_Dmitriev]

---

@altenbach wrote:

A common task is to generate a path to a file (e.g. ini) that is located right next to the VI or exe.

Here are two possibilities, the top one was seen here.

Top:

• Hard to debug and reconstruct from memory in the future.
• Breaks after building exe
• Breaks on any other OS.

Bottom:

• just works!

---

These two methods are "the same" as long as VI opened stand alone, or located in the same directory as project. When opened within project and locations of the project and VI are different, they are not the same any longer. Its because if you call this VI from the development environment and the VI is loaded in a LabVIEW project file, then Application Directory VI returns the path to the folder containing the project file, not the VI:

In additional, for many users, who coming to LabVIEW from text-based languages is still more easy to use RegExps or Formula Nodes in graphical environment. Especially in this case could be easily modified to get it running within exe as well. Nothing principal wrong with this, although NI recommend other method how to Access a VI's Current Directory.

[rolfk]

---

@Andrey_Dmitriev wrote:

---

@altenbach wrote:

A common task is to generate a path to a file (e.g. ini) that is located right next to the VI or exe.

Here are two possibilities, the top one was seen here.

Top:

• Hard to debug and reconstruct from memory in the future.
• Breaks after building exe
• Breaks on any other OS.

Bottom:

• just works!

---

These two methods are "the same" as long as VI opened stand alone, or located in the same directory as project. When opened within project and locations of the project and VI are different, they are not the same any longer. Its because if you call this VI from the development environment and the VI is loaded in a LabVIEW project file, then Application Directory VI returns the path to the folder containing the project file, not the VI:

In additional, for many users, who coming to LabVIEW from text-based languages is still more easy to use RegExps or Formula Nodes in graphical environment. Especially in this case could be easily modified to get it running within exe as well. Nothing principal wrong with this, although NI recommend other method how to Access a VI's Current Directory.

While that is mostly true, if you use projects you really should not tie configuration files into a subfolder of your project tree. If you intend to have your ini file located along the exe file (since Windows 7 only valid if it is not written from the app) then it would be the most logic place to store it in fhe project directory.

You don’t determine the path of your C or C# file to use as base of your configuration files either!!!

And if you need to also write to the file it should be stored in the Public or User Preferences.

Also, string manipulations on paths are a bad practice even in a C, C# or Python app, so no need to not suggest correcting them in a LabVIEW code!

[paulmw]

I contend this is the true equivalent de-rube'd version.

[crossrulz]

---

@paulmw wrote:

I contend this is the true equivalent de-rube'd version.

---

As a direct replacement, that is correct.  But, as at least alluded to (I only quickly skimmed the previous few posts), configuration files really need to be relative to the executable/project.

[altenbach]

If autoindexing never existed, we probably would need to do somethings as follows (top of image, seen here ).

(It is puzzling that the OP has partial knowledge about more advanced concepts, such as the feedback node, but missed the class about autoindexing)

[crossrulz]

---

@altenbach wrote:

(It is puzzling that the OP has partial knowledge about more advanced concepts, such as the feedback node, but missed the class about autoindexing)

---

I think LabVIEW defaults to insert a feedback node on circular wiring.  So I doubt the OP actually knows about feedback nodes, but rather stumbled upon it.

[altenbach]

---

@crossrulz wrote:

---

@altenbach wrote:

(It is puzzling that the OP has partial knowledge about more advanced concepts, such as the feedback node, but missed the class about autoindexing)

---

I think LabVIEW defaults to insert a feedback node on circular wiring.  So I doubt the OP actually knows about feedback nodes, but rather stumbled upon it.

---

You are probably right. 😄

Actually, upon further research, it seems they've been (ab)using feedback nodes for over three months already.. 😄

 

[AeroSoul]

The amount of times a feedback node was created when i wanted it is pretty low.

The amount of times a feedback node was created when i absolutely didn't want one is too damn high.

[VinnyAstro]

---

@altenbach  a écrit :

If autoindexing never existed, we probably would need to do somethings as follows (top of image, seen here ).

(It is puzzling that the OP has partial knowledge about more advanced concepts, such as the feedback node, but missed the class about autoindexing)

---

Yet the OP should know about autoindexing, since a FOR loop automatically creates one when you input an array... So that means that they've disabled it on purpose 🤔