LabVIEW
How to copy a file to %TEMP%?
Solved!
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.
@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.
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.
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:
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
Search LabVIEW like a graph! 
@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.
