LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Config files and the PATH

Hello, again more with the config file vi's. This is something I have
noticed in the PATH Read/Write vi's.

1st - the way a path is written is not what I would expect. When I
write a PATH on Windows (UNIX is alittle different but this is
on a windows box)
C:\DIR1\DIR2\ (this last slash is optional)

LabView write it as :

/C/DIR1/DIR2

The only problem with this is that if you have to tell a user how to
change the path you have to explain to them why the slashes are
backwards and what happened to the ":".

Because they know what kind of machine or OS is running they should
have saved the path using the same local if you like.

2nd - When I read a path from a networked machine I get to the
n
etworked machine but the path does not continue down the directories.

When I save the path I get:

//NetMachine/Drive/DIR1/DIR2

I then run my program and use the read vi to read it and I only get
to:
//NetMachine/Drive

Has anyone else noticed these things.

I'm thinking I will have to use string vi's to correct these problems.

Regards,

Steve Drake
0 Kudos
Message 1 of 4
(2,885 Views)
Write Key (Path).vi saves path information in a common format. If you want
to save and read it as platform specific, you'll have to modify the existing
vi's. If I remember right, you'll have to do some editing anyway to handle
network locations because of bugs in the vi's used for the conversion.

Steve Drake wrote:
>Hello, again more with the config file vi's. This is something I have>noticed
in the PATH Read/Write vi's.>>1st - the way a path is written is not what
I would expect. When I > write a PATH on Windows (UNIX is alittle
different but this is> on a windows box)> C:\DIR1\DIR2\ (this
last slash is optional)>> LabView write it as :>> /C/DIR1/DIR2>>The
only problem with this is that if you have
to tell a user how to>change the
path you have to explain to them why the slashes are>backwards and what happened
to the ":". >>Because they know what kind of machine or OS is running they
should>have saved the path using the same local if you like.>>2nd - When
I read a path from a networked machine I get to the>networked machine but
the path does not continue down the directories.>>When I save the path I
get:>> //NetMachine/Drive/DIR1/DIR2>>I then run my program and use the read
vi to read it and I only get>to: > //NetMachine/Drive>>Has anyone else
noticed these things.>>I'm thinking I will have to use string vi's to correct
these problems.>>Regards,>>Steve Drake
0 Kudos
Message 2 of 4
(2,885 Views)
On 24 May 2000 08:41:04 -0500, "Dennis Knutson"
wrote:

>
>Write Key (Path).vi saves path information in a common format. If you want
>to save and read it as platform specific, you'll have to modify the existing
>vi's. If I remember right, you'll have to do some editing anyway to handle
>network locations because of bugs in the vi's used for the conversion.

So there is a bug in the vi's when using a network?

Regards,

Steve Drake
0 Kudos
Message 3 of 4
(2,885 Views)
Steve Drake wrote:

> On 24 May 2000 08:41:04 -0500, "Dennis Knutson"
> wrote:
>
> >
> >Write Key (Path).vi saves path information in a common format. If you want
> >to save and read it as platform specific, you'll have to modify the existing
> >vi's. If I remember right, you'll have to do some editing anyway to handle
> >network locations because of bugs in the vi's used for the conversion.
>
> So there is a bug in the vi's when using a network?
>
> Regards,
>
> Steve Drake

I am not sure I would call this a bug, so much as a bad implementation.
The biggest culprit is the Common to Specific Path and the reverse
Specific to common path. These 2 VIs find the OS and manipulate the
path (by turning it into a string and
using the string functions).

Looking in these VIs there is no provision for MS Networking, they
do interpret 95/NT though. When I tried this on my 95 with MS Networking
I get the following:

Write: //machine/drive/dir
Read: D:\:machine/drive/dir

Since the Common to specific is not expecting the 2nd slash it makes a bad path.

I have had this problem before so I simply used the Read-Write String and did
any
path conversions later in the VI.

Kevin
0 Kudos
Message 4 of 4
(2,885 Views)