LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to copy a file to %TEMP%?

Solved!
Go to solution

Hello everyone! 

This is something I expected to work, but it doesn't. Since the temporary user path is variable, using the %TEMP% environmental path variable should help.

Of course, I could some dissolve that variable into a full path and use that on the copy VI, but that requires more coding. Trying to copy a file gives me error 1430.

copy.png

0 Kudos
Message 1 of 14
(498 Views)
Solution
Accepted by MaSta

Hi,

 

You can use the Temporary Directory constant:

Ajskrim_1-1674212727224.png

 

_______________________________________________________________

-Patrik
CLA || CTA
If it helps - Kudo it, if it answers - Mark As Solution
Message 2 of 14
(490 Views)

Hi Ma,

 


@MaSta wrote:

Hello everyone! 

This is something I expected to work, but it doesn't. Since the temporary user path is variable, using the %TEMP% environmental path variable should help.


Or use this:

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO
Message 3 of 14
(483 Views)

Ouch, so simple? Shame on me, because I know these system constant/path VIs.

0 Kudos
Message 4 of 14
(469 Views)

@MaSta wrote:

Ouch, so simple? Shame on me, because I know these system constant/path VIs.


We can't remember everything all of the time.  We can only hope to remember some of the things some of the times.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 14
(450 Views)

@billko wrote:

@MaSta wrote:

Ouch, so simple? Shame on me, because I know these system constant/path VIs.


We can't remember everything all of the time.  We can only hope to remember some of the things some of the times.


To paraphrase a famous quote: We can remember some of the things most of the time, and most of the things some of the time, and that's sufficient.

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 14
(439 Views)

You already got your answer, but I wanted to clarify why these system variables don't work this way.  LabVIEW is compatible with more then just Windows.  LabVIEW works on various Linux machines, PharLap, VXWorks, Mac, Windows, some FPGAs, and some corner cases on things like a Pi.  Not all of these environments know what a %TEMP% is, or what a %APPDATA% is.  There are some 3rd party tools that can read these variables.  I made one 17 years ago (my bones hurt) on LAVA.  I expect the code is messy and uses older coding styles but it might be useful to look at for someone.

 

Because not all these operating systems work the same, NI made the tools that others here have mentioned, so that you can get a temporary directory, no matter the operating system, without having to know specifics about the OS it is running on.  Ideally someone could take your VI and run it on Mac and it would work just fine without any changes.

 


@Yamaeda wrote:


To paraphrase a famous quote: We can remember some of the things most of the time, and most of the things some of the time, and that's sufficient.


Every time I learn something new, it pushes some old stuff out of my brain.  Like when I learned to make wine at home, and I forgot how to drive.

Message 7 of 14
(326 Views)

The constant or environment VI won't work if the path comes from a file or other user input.

 

If you're given a path, you can catch more then one fly at once by using .NET:

 

Expand System Path.png

 

See list-of-all-environment-variables-in-windows-10 

 

ENVIRONMENT VARIABLE CORRESPONDING PATH
%SystemDrive% C:\ (Operating System drive)
%SystemRoot% C:\Windows
%WINDIR% C:\Windows
%HOMEDRIVE% C:\ (Operating System drive)
%HOMEPATH% C:\Users\<Username>
%USERPROFILE% C:\Users\<Username>
%APPDATA% C:\Users\<Username>\AppData\Roaming
%ALLUSERSPROFILE% C:\ProgramData
%PROGRAMFILES% C:\Program Files
%PROGRAMFILES(X86)% C:\Program Files (x86)
%PROGRAMDATA% C:\ProgramData
%TEMP% C:\Users\<Username>\AppData\Local\Temp
%LOCALAPPDATA% C:\Users\<Username>\AppData\Local
%PUBLIC% C:\Users\Public
%COMMONPROGRAMFILES% C:\Program Files\Common Files
%COMMONPROGRAMFILES(x86)% C:\Program Files (x86)\Common Files

Message 8 of 14
(262 Views)

@Hooovahh, a counter thesis: LabVIEW uses a Windows system DLL to do the actual copy action and will pass the given path to it. The system DLL should be able to cope with %TEMP%, wouldn't you agree? 

0 Kudos
Message 9 of 14
(243 Views)

@MaSta wrote:

@Hooovahh, a counter thesis: LabVIEW uses a Windows system DLL to do the actual copy action and will pass the given path to it. The system DLL should be able to cope with %TEMP%, wouldn't you agree? 


I can't say how it actually works under the hood.  It is possible that there are some checks on the characters in the path control and to throw an error if the path isn't multiplatform.  There is a utility in the vi.lib that checks for this, and if it fails then the path isn't valid on all platforms LabVIEW uses.  So if NI uses some function like this, before the DLL call, it might see the % symbol and say it isn't valid and to throw an error.

 

That being said I tried moving a path from "%temp%\Editor Icons\Aux Device off.png" using the MoveFileA from kernel32.dll and it threw an error too.  I'm guessing this means environmental variables is a shell thing, that these DLLs either aren't aware of, or need some thing extra to evaluate.

0 Kudos
Message 10 of 14
(232 Views)