Value of Application Directory?

[aputman]

---

@coloredsound wrote:

i want to consolidate all my non variable value into one sub vi 

---

If these are truly non-variable, meaning they are "write once, read many", use a global variable.  These can be defined in one VI file, initialize them in a separate VI (or set the default value, if they will never change) and then you only need to read them where needed.  But I should stress that this is only good for "write once, read many" situations, IMHO.  

[coloredsound]

Hello Gerd,

i am aware i can do this, i am just emphasis on code simplicity

it is ok if path constant cannot do this,  i am wondering if there is more simple way so that static and relative path can coexist in one output

guess i will just create another output

[coloredsound]

Hello All,

it is not that i dont know how to do this

i am aware there is a lot all kind of alternative

what i emphasis is code simplicity, to put it simple, i wonder if the same code can carry out both static and relative path function 

it is ok if there is no answer for my question, consider case close

[aputman]

The code you have posted doesn't look simple to me.  You are storing some random values that are not all the same datatype in an enum.  Some are strings, some are numbers, some are paths.  Then you appear to be pulling a value out of the enum and you try to convert that value to a path, to an integer and to a string, all at the same time.  Two things wrong with just this step:

1. The value that is returned from an enum is the enumerated value (0,1,2, etc), not the item name.  If you want the item name, you need to use a property node.  This alone makes your whole concept more convoluted, when compared to using, for instance, global variables as I mentioned previously. 
2. You are trying to assign this enumerated value to every indicator in the VI rather than the one that it belongs to.  For example, enumerated value 2 belongs in the path indicator only but you are writing it to all indicators.  If you run this code twice, the value written to all the indicators in the first iteration will be overwritten by the value from the second iteration.  

[GerdW]

Hi aputman,

The value that is returned from an enum is the enumerated value (0,1,2, etc), not the item name.  If you want the item name, you need to use a property node.

Wrong! (Well, not completely - but in this context.)

As shown you can use FormatIntoString to convert the enum item text into a string!

For me the 2nd point is more senseless:

When the shown snippet above is used as subVI you need an enum constant at its input to get the needed output value. Why not use the correct output value as constant (instead of the enum) then?

[aputman]

---

@GerdW wrote:

Wrong! (Well, not completely - but in this context.)

As shown you can use FormatIntoString to convert the enum item text into a string!

---

Nice.  I did not know that.  Or I have forgotten it.  

[crossrulz]

---

GerdW wrote:Why not use the correct output value as constant (instead of the enum) then?

---

I think the OP is trying to avoid many VIs.  They mention trying to keep things simple, but it seems to me to be more complicated than a simple VI for each constant (that you can inline, have a small icon, etc).  Personally, I have a VI just for the application directory except is has the relative path input.  Then I get a full path relative to the folder of the application with just a string constant and a small VI.  I use that thing all over the place.

[coloredsound]

Hello aputman,

you can also convert string back to enum

 

default case is not avoidable if you wire string to case

this is quiet dangerous if you have many case connected to this string and forgot to define new case for each case

i use enum to control the case and immediatetly i know which case havent define if i add new case (the top level vi will not able to run due to broken arrow of incomplete case)

by using this convertion, i can both accept enum and also string without worry to have unhandle case

[GerdW]

Hi crossrulz,

I have a VI just for the application directory except is has the relative path input.

I use similar VIs for LocalAppData and for some folders on our internal server…