Weird behaviour with .NET constructor node and GZipStream compression

[PhillipBrooks]

---

@Stinus Olsen

So, from reading your post it still seems this is an issue in LV2017?

---

It appears so, the CAR is noted in the 2017 known issues:

http://www.ni.com/product-documentation/53586/en/#493662_by_Category

[bseguin]

I wish that NI was taking care of their customers more and resolve BUG. Actually they are taking care of their marketing department more than their customers.

Benoit

[Stinus Olsen]

Yeah, I can only second that...
I guess whats really going on is that NI is focusing all their efforts on bringing LabVIEW NextGen up to date instead of putting more energy into fixing stuff in the old era LabVIEW.

IMO that's a shame because NextGen seems to spoil a lot of the things that made LabVIEW cool for the advanced/skilled programmer 😕

[bseguin]

Agree.

They will just lose a lots of customers...

Benoit

[PhillipBrooks]

I found a pure LabVIEW solution based on a LAVAG forum post; no DLL required. The fix is to use .NET reflection to create the specific object instance of the GZipStream object. The LAVAG post used a filestream object, but the technique works for the memorystream type as well.

Refer to the V2 decompress example:

https://forums.ni.com/t5/Example-Programs/GZIP-compress-uncompress-of-string-using-NET/ta-p/3507908

LAVAG thread -> https://lavag.org/topic/20613-net-decompression-gzip-or-deflate/