jyoung8711
-
Posts
4 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by jyoung8711
-
-
4 hours ago, Rolf Kalbermatter said:
So I did take a look and yes it was that function but no, it doesn't only fail in 64-bit mode but also in 32-bit mode. So I'm a little lost why you feel it did work with an UNC path when using it in LabVIEW 32-bit. Going to do some more tests with this and trying to clean up a few related things.
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.
-
4 hours ago, Rolf Kalbermatter said:
What would be the error you get?
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!
OpenG Zip 4.2?
in OpenG General Discussions
Posted
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!