Jump to content

jyoung8711

Members
  • Posts

    4
  • Joined

  • Last visited

Posts posted by jyoung8711

  1. 10 hours ago, Rolf Kalbermatter said:

    It for sure helps. I was really thinking that I was overlooking something here. But with this explanation everything makes sense. The actual code in the DLL is substantially different to 4.0. In 4.0 most was just a very thin wrapper around existing LabVIEW functions. But those LabVIEW functions do not support Unicode paths so I have been refactoring that code substantially to support full Unicode paths for the underlying functions (and create compatibility wrappers that still use the old LabVIEW paths, which of course won't support Unicode path names).

    The advantage of using full Unicode throughout the ZIP tools, eventually will be that path names can contain characters not present in your current ANSI locale and that path names can be almost arbitrarily long, namely 32k characters. The ZIP standard internally already supports UTF8 encoded file names, so once this is fully working you can also extract and create ZIP files that are using UTF8 filenames. But this complete porting to full Unicode support is not yet finished. Most of the actual programming is done, but it needs more testing.

    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!

  2. 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.

  3. 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!

  4. 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!

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.