jyoung8711

@drjdpowell -- I'm not sure how much use this library gets, or if there's a desire to continue maintaining it.  I had a need to integrate this into a common reuse library to replace the .NET API (Npgsql).

As part of that integration process I had a couple of support features I found a need for:

1. support for [null] data in both writing with parameters and in checking if a resulting element is null.
2. support for pulling out the datatype of columns when reading results.
3. pulling a result element back as a LV variant (rather than the explicit type) -- I believe the sqlite library supports this but postgresql did not.

I have a version that I've completed which includes these updates.  I'd be willing to integrate into the repo and make a pull request, but before going through that effort, I thought I'd check to see if that was of interest.  Let me know.

(I was going to log these things as issues/requests on bitbucket, but it appears that atlassian has migrated the "issues" interface to Jira, so that doesn't seem to work like it used to)

Thanks!

My part of the world as well! (Columbus based)

How committed is the company to hiring someone directly? My company has resources that could potentially help with this.  It's outside of my personal wheelhouse, but I am relatively local and can travel to the client.  The resources we have are a bit scattered, but I could be a local face.  The project itself specifically seems to align pretty closely with work our CTO has before (wave equation, imaging analysis & CUDA work) -- everyone would be US citizens as well.

So it might be a good fit skill wise, but unsure if they'd be willing consider something like this.  

If you think it might work, happy to provide some contact information and we can move this chat elsewhere!

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!

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!