Jump to content

Zaphiro Technologies

Members
  • Posts

    25
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Zaphiro Technologies

  1. I get this error when building my package, previously the package was building fine, it did taka a long time (~15 to 20 minutes) to build though because it's quite large (~78 classes, 1200+ VIs).
    Since the last successful build I've only added some methods in the classes.


    Sources are in LV 2019 32 bit

    I'm using the latest version of VIPM 2021.1 b2754

    647188973_Capturedcran2022-11-10183001.png.3b5bb4bd40a419e5467f34b101e2d185.png

  2. 4 minutes ago, Jim Kring said:

    Oh, that's very interesting! Thanks.

    Question: is there any possibility that you opened this code on a Mac? (where the EOL character is a "\n" -- note that the EOL character is "\r\n" on Windows).

    Nope, never on a mac but this project can be run either on Windows or on a NI Linux RT target, so I naviguate between Linux RT and Windows almost every day.

    3 minutes ago, Jim Kring said:

    Also, are you able to reproduce this issue right now?  I might have a fix/test for you.

    If you've fixed it locally, maybe you can reproduce by uninstalling OpenG String from 2019 and then re-install OpenG.

    Being able to reproduce would really help me test a fix.

    Will try that.

  3. [ Update: The work-around for this issue is to OpenG String v4.1.1.16 ]

    Take a look at this "issue" that can appear after installing LV2020 : https://lavag.org/topic/21753-1d-array-to-string-not-compiling-correctly/

    The video posted shows how to fix it.

     

    What happened to me was :

    - I've been using EasyXML happily for some time in LV2019 (my use include attributes)

    - I installed LV2020

    - EasyXML in LV 2019 started to add an extra line at the end of attributes. I noticed that in Git when my config files had so many modifications.

    - for a few days, it's been very painful to try and find the error so I dug into EasyXML's inside then notice that the OpenG String VI : "1D Array to String" was adding a "\r" at the end of the delimited string.

    - then I found the post on LAVA which saved me a lot of time.

    So... just be careful with this if you use attributes.

     

    to give you an example, this :

    image.png.cf36ece0789d5e942f59d3082b9a68e1.png

    became that

    : image.png.86ecfea1248685abec1c62469d191b38.png

×
×
  • Create New...

Important Information

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