Jump to content

ZLIB Specific Path to Common Path (not working on Mac OSX)


Recommended Posts

The following VI is part of the OpenG LabVIEW Zip Library:

 

ZLIB Specific Path to Common Path__ogtk.vi

 

post-2-0-92305500-1363219276_thumb.png

 

If you notice, the case structure supports Mac OS, but not Carbon. The App.TargetOS output is Carbon. I'm running this on Mac OSX 10. This has a ripple effect in that I cannot use some of the Zip tools to compress files on Mac.

 

Not sure who will be fixing this, since JGCode is on hiatus. But I'm reporting it here for the Googlers of the future.

Link to post
Share on other sites
The following VI is part of the OpenG LabVIEW Zip Library:

 

ZLIB Specific Path to Common Path__ogtk.vi

 

attachicon.gif2013-03-13_1700.png

 

If you notice, the case structure supports Mac OS, but not Carbon. The App.TargetOS output is Carbon. I'm running this on Mac OSX 10. This has a ripple effect in that I cannot use some of the Zip tools to compress files on Mac.

 

Not sure who will be fixing this, since JGCode is on hiatus. But I'm reporting it here for the Googlers of the future.

 

That change was made on April 10, 2011 to the VI in Subversion. Not sure when the latest release of the ZLIB library was created by JGCode. It might have been just before that. On April 11, 2011 an additional change was made to also support Pharlap and VxWorks targets and on July 17, 2012 an additional change to support Windows 64 Bit (which is still irrelevant as the DLL is not yet released for 64 bit).

 

I have a lot of code changes on my local system mostly to support 64 bit but also some fixes to the string encoding problem but it is all in an unfinished state and I hesitate to commit it to the repository as anyone trying to create a new distribution library of that would create a likely somewhat broken library currently.

 

I'm also not exactly sure about the current procedure to create a new library release as well as the mentioned icon palette changes in the last release made by JGCode. I didn't see any commits of those changes to the repository. Otherwise I might have created a new release myself with the current code.

Link to post
Share on other sites

The way I resolved a similar issue was to use the "Path to Command Line String.vi" (which isn't on the palettes) rather than path to string then hacking the string. It seems to work on all platforms.

 


 

You can then just use all the path primitives (e.g. strip and build) to traverse the path without worrying about the underlying format.

Edited by ShaunR
Link to post
Share on other sites
The way I resolved a similar issue was to use the "Path to Command Line String.vi" (which isn't on the palettes) rather than path to string then hacking the string. It seems to work on all platforms.

 

attachicon.gifpath2string.png

 

You can then just use all the path primitives (e.g. strip and build) to traverse the path without worrying about the underlying format.

I've never heard of this primitive before, but I couldn't get your snippet to work.  I tried in 2012 SP1 but it just added it as an image (I first saved it to my PC locally then dragged it to the BD).  I opened the file in a PNG editor and I couldn't find the VI data inside.  Would you mind posting a VI file with that primitive in it? 

Link to post
Share on other sites
I've never heard of this primitive before, but I couldn't get your snippet to work.  I tried in 2012 SP1 but it just added it as an image (I first saved it to my PC locally then dragged it to the BD).  I opened the file in a PNG editor and I couldn't find the VI data inside.  Would you mind posting a VI file with that primitive in it? 

Here ya go.

Link to post
Share on other sites
You can just go to the source:

 

..LabVIEW xxxxvi.libAdvancedStringCommand Line String To Path.vi

I (incorrectly) assumed it was a primitive because of the icon, thanks. 

Link to post
Share on other sites
The way I resolved a similar issue was to use the "Path to Command Line String.vi" (which isn't on the palettes) rather than path to string then hacking the string. It seems to work on all platforms.

 

attachicon.gifpath2string.png

 

You can then just use all the path primitives (e.g. strip and build) to traverse the path without worrying about the underlying format.

 

That function does not do the same than what this VI does. For one the string part in the lvzip library is always in the unix form, while the other side should be in the native path format. Try to convert a path like /test/test/test.txt on Windows with this function. Of course you can replace all the occurrences of into / on Windows, in the resulting string, but that just complicates the whole thing.

 

I probably end up putting that entire function into the actual shared library function, since it also needs to do character encoding conversion too to allow to work with filenames containing extended ASCII (or UTF8) characters. And to make everything interesting the whole encoding is VERY different on each platform. The strings in the ZIP file are under Windows normally stored with the OEM charset while LabVIEW as a true GUI application uses everywhere the ANSI codepage. Basically they are both locale (country) specific and contain more or less the same characters but of course on different places! That is the reason that filenames containing extended characters look wrong when extracted with the lvzip library currently. On other platforms there isn't even a true standard with the various ZIP tools as to how to encode the filenames in an archive. It usually just uses whatever is the current locale on the system, which at least on modern Unixes is usually UTF8.

The ZIP format allows for UTF8 filenames too, but since on Unix most ZIP tools are programmed to use the current locale, they do store UTF8 names but do not set the flag that says so! Of course there are also many ZIP tools that still don't really know about UTF8 too so extracting an archive with them that was created with UTF names causes serious trouble.

 

Basically there is no absolutely correct way to make lvzip deal properly with all these things. My plan is to make it work such that for packing it uses only standard ASCI when the filenames don't contain any extended character and otherwise always use UTF8. For unpacking it will have to deal with the UTF8 flag and otherwise assume whatever is the current locale, which can and will go wrong if the archive wasn't created with the same locale than it is retrieved. On Unix there is no good way to support extraction of files with extended ASCII characters at all, unless I pull in iconv or iuc as a dependency.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Jim Kring
      [Update: NI Bug 974336]
      There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here).
      Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet.
      Coerce to Variant Fail (LV2019).vi


       
      Note that adding another element to the outer cluster causes the problem to go away.


    • By ShaunR
      Maybe others have seen this but I only became aware of it recently so I apologise if there is already a CAR for it.
      The following demonstrates a difference in behaviour between LabVIEW 2017 and previous versions (back as far as 2009, maybe further).
      The VI registers an event when it starts (in the timeout case) and generates a user event when the Increment button is pressed.
      The expected behaviour is that the counter will increment by one every time the button is pressed. This is the case for LabVIEW versions prior to 2017. In 2017, the user event is never fired, nor is there an error emitted by the generate user event.
      To get the VI to operate as expected in 2017; change the event refnum tunnel to a shift register. This seems to indicate that the refnum prototype is stomping on the dynamically allocated reference whereas in previous LabVIEW versions it would not. Note also, that when using the shift register, the cases do not need to be "wired through" as would be expected with similar functionality in a normal case statement.
      evnt.vi
    • By A Scottish moose
      Hey everyone,
       
      I am working on a backup function for a test executive.  The backup uses the 'class to XML' vi to create an XML string and then save it to a file to be reloaded later. All of my test specific information lives in the class (or one of it's children).  I like this functionality because it makes backup and reload brainless.  It just works.... until now... I've got a test class for my current tester that's grown rather large.  Everything works fine, until the tester loads some waveform data into either of the waveform arrays.  Without data in this field the class reloads just fine, otherwise if fails and says the XML is corrupted.
       
      As you can see in my backup vi I have built in a work around that flattens the waveform arrays to strings, drops them back into the class private data, deletes the waveform arrays and then writes the class.  This works! Much to my surprise both waveform data and the rest of the class data are written to file and reloaded without error.  
       
      Does anyone have any knowledge or experience with this? 
       
      Cheers,
       
      Tim


    • By Stobber
      If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why? See the attached code (LV15) for an example.
      I don't want to use the ACBR node right now because I want to set some control values of the VI ref on a different diagram than the one that will run it. (I just want to pass the VI ref between calling diagrams, not all the values that'll be passed into it.)
      DVRtest.zip
    • By drjdpowell
      OpenG’s Trim Whitespace fails on a string of all whitespace, if set to trim the front only.   It returns the last whitespace character.
×
×
  • Create New...

Important Information

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