Leaderboard

Howdy I am chuffed to be giving away an AudibleListener® 6-Month Gold Gift Membership. Sure beats reading

I almost didn't get them finished in time, but I will be donating a hand-made necklace and bracelet featuring the "top" (ahem) new feature of LabVIEW 2014! That's right, the launch icon! They're reversible: 32-bit launch icon on one side, and 64-bit on the other. Some assembly required: I'm not tying off the cords so you can adjust them to fit. [i've been told men might not want to wear a necklace, but, hey, you could always share with someone special!] Brought to you by Christina Rogers, member of LabVIEW R&D, author of the Eyes on VIs blog, and creator of the (free!) graphical novel Rune: A Tale of Wizards and Kings and sequel novella Wizards and Kings: Sacrifice (only 99 cents on Kindle, and free with Kindle Unlimited!)

2) You configure the Call Library Node parameter as Adapt to type: Pass C Array Pointer. 4) Just because you assign the pointer value of memory location to a pointer parameter does nothing about making sure the contents of the memory area is copied into that parameter. table datatable[16]; (here is C allocating the memory for the array with struct of integers if i am right) int32_t func (struct *pointer) { pointer = datatable; } This only assigns the memory address of datatable to the pointer. However the calling function never sees that pointer nor any data in the pointer. You simply destroy the data area that LabVIEW has allocated and on return of the function LabVIEW can't help but trip over the trap you laid out for it. You would have to do something like int32_t func (struct **pointer) { *pointer = datatable; } but that only works for C as caller (and not like this since the datatypes are not the same). LabVIEW can't deal directly with pointers. More appropriate would be: int32_t func (struct *pointer) { *pointer = *datatable; } But that works in standard C not for all compilers and even in modern C++ it would cause a compilation error since the datatypes are incompatible. The best thing to do would be: int32_t func (struct *pointer) { memcpy(pointer, datatable, sizeof(datatable); } And making sure that you allocated a big enough variable in LabVIEW to be passed to the pointer parameter. If the dataarea from LabVIEW is even one single byte smaller than the length of datatable, very bad things will happen for sure.

Guys, guys, I for one am delighted at the increasingly barren "new features" list for each LV release. I've been using LV for many years and have grown to love hate accept many of its idiosyncracies as being de-facto standards. Bugfixes are cool, new features = new bugs. I don't like bugs and as much as I'd love Interfaces for LVOOP and a host of other things, at the moment, bugs and stability issues are my main source of pain with LabVIEW at the moment. Daily crashes, huge delays when editing VIs in projects used on multiple targets simultaneously.... LV needs major repair work. We would all most likely agree on that. The 20+ year old code base is no longer an adolescent and really needs to get its act together. There are certain kinds of petulant and stubborn behaviour which may be acceptable for a teenager, but at the tender age of 28, its time we raised our expectations. Minor rumblings from NI (and quite possibly some optimistic pattern recognition on my part) have led me to have some hope that this process of repair or self-improvement is already underway. I for one look forward to the day where all of the fixing in the background can finally be accelerated because a lot of the old crap (there's no other word for it) has been cleaned out and the source code for LV is finally in better shape. As someone who has been crying for better stability for years, I am delighted to see shorter and shorter "new feature" lists because I'm optimistic and believe the time spent NOT implementing new features has been used for a much more valuable long-term goal. So my message is, have faith. PS Yeah, I wrote behaviour with a "u". I won't give in to the LAVA spell-checker. I won't..