jyoung8711

Thanks for the additional context. That's helpful in understanding some of what's going on behind the scenes. Also nice to know that it wasn't something "weird" on this particular system or something. For the moment I've worked around this by moving everything into a temporary path on the system making the call, but long-term I'll look forward to the next release! Thanks!

Ah... So, I know the reason for that! and it might help with troubleshooting... I run the last "official" release for my 32-bit installations (4.0.1-1), and the 4.2 version found here for 64-bit -- [historical compatibility reasons... the newer dll caused issues with some older "common" code, while that version doesn't actually work in 64-bit]. Sorry for the confusion, but hopefully this might be helpful since it was working in the older version.

The DLL outputs an error "1". (the function call is LVPath_UtilFileInfo) - Apologies for not including in the previous post. This is for the 4.2 beta version posted here with 64-bit LV (tried 2018, 2020, 2021). Windows 10 21H2 The same file, if moved to a local path, runs through the VI/Function just fine (or if executed in 32-bit version). I haven't had the opportunity to try it on a second computer yet. Thanks!

I know this thread is pretty old, but I've been working with the beta version of 4.2.0, and came across something strange. It seems like if I try to zip up files in LV 64-bit (2020/2021), if the files are at a network address (\\Network\file.ext) I end up with an error coming from the "fileutil.llb\FILE Resource File Info__ogtk.vi" file (and internally from the DLL call). the 32-bit version seems to support network paths just fine, so this caught me a bit off-guard. I took a look at the current version on github, and it looks like you were making some changes to the file utility functions, but it doesn't look like it resolved this issue (at least with a simple attempt on my side). Any ideas what might be happening here? Thanks in advance!