Jump to content

Antoine Chalons

Members
  • Posts

    957
  • Joined

  • Last visited

  • Days Won

    34

Posts posted by Antoine Chalons

  1. Hi all,

     

    I'm using OpenG ZLIB Compress Directory.vi to turn a folder (and its subfolder) into a ZIP file.

    When some subfolders have characters like é in their name, into the zip file those chars become something else (Ù), is there anything we can do to prevent this?

     

    I guess the reason for this "issue" - or limitation - is that zlib library uses ANSI strings and does not support multibyte or unicode strings, fine. My question is is there a way around that?

     

    LabVIEW zip VIs probably use zlib too because they give the same result :(

  2. If you activate private stuff (SuperPrivate... blablabla) you'll have access to this as a VI property : post-7452-0-60572600-1358772376.png

     

    Then if you want to have a VI that enables this option to the whole sub-hierarchy of a VI you'll need to do some work, but be carefull before doing this on all sub-vis that will slow you down a lot, maybe you want to sort a bit and avoid those VIs that are in vi.lib and user.lib.

     

    Also I think it will be much easier to get the VI's project item ref and then use the "get all descendents" method than trying to get the list of all sub-vis from the VI's ref directly.

    Edit : or maybe I'm wrong : https://decibel.ni.com/content/message/36585#36585, in this discussion is shown a method to get VI's dependencies with some exclusion options, you could just remove vi.lib VIs fron there. 

     

    If it helps, here's a VI I use to get all VIs in a project excluding VI.lib

     

    post-7452-0-85229400-1358772955_thumb.pn

     

    Edit : not sure the VI posted above sorts VI from vi.lib.

     

    Hope this helps (and sorry for my messy answer)

  3. Thanks a lot for taking the time to have a look and comment.

     

    I have no illusions about how usefull this code can be, as I said I wanted something simple to start teaching myself that's why your comments are very appriciated.

    I wont have much time this week to work on this subject but I'll definitely go back to my code with your comments in mind and probably come back here with questions.

     

    Cheers

  4. Hi all,

     

    In order to teach myself to use LVOOP -it's about time to start- I've decided to start with a little project that I've had in mind for a long time, I've called it LVOOP VIServer, I hope it doesn't sound too pretentious.

     

    The idea is to make a hierarchy of LVOOP classes that matches the LabVIEW Controls class hierachy in order to take advantage of dynamic dispatch.

    In a way it is related to this LIE Idea : Improve the "cluster to array" primitive

     

    For now I've implemented the parent class "Control" and two child classes "Path Control" and "String Control" and a bunch of VIs to read/write position, size, caption text, caption font and font.

     

    post-7452-0-17362900-1358523545_thumb.pn

     

    If anyone is interested in reviewing the code, providing advice or whatever... I've kept it small enough so that if the core concept is not good it can still be changed.

     

    The code is hosted on GitHub here, it should be accessible to anyone, let me know if there is any issue of if you would like a zip in this thread.

     

    Cheers

    • Like 2
  5. Hi,

     

    I found this bug in LV 2011 SP1 and it was reproduced in LV 2012 by an NI application engineer who filed CAR #385212 for it.

     

    Basically, if an installer build specification has values under a key that you've created in the "Registry" section and that you delete the key without having deleted all the values before the build will fail.

    The solution is either to recreate all the same keys and values and delete each value before deleting the keys or edit the lvproj file with a text editor to remove all the lines corresponding to the values and keys your want to get ride of.

     

    The error I was getting when the build was failing was : 

     

    *** Error: An internal tool or library returned an error. (Error code -21)
    Error adding registry key:  Name: name_of_value
    **************
    *** Error Details:
    Error in MDF API function: _MDFBuildDevPart_AddRegKey
    nmdkAddRegKey returned error code 26051
    *** End Error Report

    • Like 1
  6. Just a quick wild guess : amongst the reasons for a VI to have this option gray-out, you'd find "this VI is currently running, or is a dependency of another VI that is running", there are probably other reasons of course.

    Can you give more details concerning your use case?

    Is a part of your code running when you have this issue?

    Is your VI part of a class or lvlib that is protected, etc...

  7. Hi,

    Is it a known limit of OpenG LabVIEW ZIP Library that it doesn't work with LabVIEW 64 bit (2011 SP1 on Windows 7 64 bit in my case) or is it just a problem on my computer?

    When I mass compiled the package after installing it with VIPM it turned out that quite a few VIs were broken.

    It seems that the issue is that lvzlib.dll is 32 bit only and therefore won't work in 64 bit LabVIEW.

×
×
  • Create New...

Important Information

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