Leaderboard

View File Data Matrix Generator v1.0 LV2020 This project library enables conversion from string data to a 2-D integer array encoding Data Matrix ECC200 symbology. The library includes demo code to render the output to a LabVIEW picture indicator. Submitter David Boyd Submitted 05/07/2023 Category *Uncertified* License Type MIT  

Thanks, I did not know about this. I am not sure I will ever use it, but I like to know such a feature exists (or not). Reading that thread, I am not 100% in agreement with the comments that moving to class solves everything. Not everything needs to be a class, sometimes a plain old cluster is really ok. Even for biggish clusters. Anyway, completely separate discussion 🙂

There's a private method called Convert to Stub which does this. I never used it, but I understand it does have some caveats.

Yes it of course depends on the target you are compiling for. The actual application target, not the underlying OS. It's the same for pointers and size_t datatypes (at least in any system I know of. There is of course theoretically a chance that some very obscure compiler chooses a different type system. But for the systems that are even an option for a LabVIEW program, this is all the same).

For that I have left this sentence with a reference to your message and the next ones after: But I would say that size_t type rather depends on a target bitness, than on a platform bitness. On 32-bit OS we can compile 32-bit applications and cross-compile 64-bit ones, if supported by the compiler. On 64-bit OS we can freely compile both. So sizeof(size_t) is either 4 bytes for 32-bit target or 8 bytes for 64-bit target. I've just checked that in MS Visual Studio.

Totally correct so far but you forgot that size_t is also depending on the bitness, not just the pointers itself. So these values also either need to be a 32-bit of 64-bit integer value.

First, C unions are special data type that allows for multiple data types to be stored in the same location. Therefore you don't need to bundle each and every field defined in your header for that union. The union length is set by the longest field. So you should pass 4 bytes in both of your cases. It's up to the code on how to interpret that union onwards: either as uint32_t "value" or as four uint8_t fields struct. Second, you have two pointers in your main struct (pImagePtr and pUserPtr). You should pass them as 32-bit fields in 32-bit LabVIEW or 64-bit fields in 64-bit LabVIEW. To satisfy both cases, use Conditional Disable Structure with two cases for 32- and 64-bits accordingly. Now you're passing U8 fields, that will likely lead to writing to the neighboring fields inside the shared library. The same applies to size_t parameters (read here for details). Maybe it would even be easier to make two different structs for 32- and 64-bits in Conditional Disable Structure instead of defining each parameter separately.

A union is always sized to its largest member, not the sum of its members. In your case, 4 bytes. You currently provide 8 bytes of memory. Try reducing the size of the union to 4 bytes.