Leaderboard

JKI is pleased to add to the high geek factor pile: we're donating this shiny new Google Nexus 7 Tablet. Pssst... we're hiring. If you love LabVIEW and you're a CLD/CLA (or on your way there), you should definitely visit Booth #630. If you do it before the BBQ, I might even let you hold the box the Nexus 7 is in .

Way delayed, but my ticket is officially bought. Looking forward to meeting everyone in person.

It definitely could be an endian-ness problem, but your characterization of LabVIEW is not quite right. LabVIEW flattens to big endian but in memory (any typed data on a wire) it matches the endian-ness of the CPU. Since all our desktop platforms are now x86, they all run as little endian. So the problem would be that his data is big endian and LabVIEW is treating it as little endian. Don't mean to be pedantic but I don't want someone to come along later and convince themselves all LabVIEW data is big endian.

"What if NI were to take the top 10 or so ideas from the Idea Exchange..." But that's part of the problem with the Idea Exchange kudos system; the top 10 ideas *are* low hanging fruits with minor impact already. The good ideas (as in; will significantly improve the power of LabVIEW and the products we can make with it) hide in the middle and even lower ranks. The current top ten ideas yet to be implemented or declined are: 1. Wait (ms) with error pass-throu​gh 2. Show hidden controls as "ghosts" in edit mode 3. A faster & neater way to show Cluster Element Labels 4. Probes for Loop Iteration 5. Selection of Items on BD or FP needs to be Easier! 6. Some indication that a string control isn't showing the entire string. 7. Align objects should not align increment/​decrement buttons 8. Same Height of Unbudle by Name / Terminal / Local Variable 9. Include LabVIEW Version Number in Applicatio​n Icon 10. Smaller Event Ref Constants Of these ten only number 6 will be of any direct use to the end-user (unless the developer *is* the end user and/or the development itself constitutes the majority of time spent on the application). None of them are "killer apps".

Get.vi

And on behalf of the NI RF Team, once again I'll be offering up a flight around Austin, time weather and schedules permitting. You will get the chance to view our beloved Austin from the air and take the controls of N2817F, a High Performance Cessna Skylane 182. Any training on aviation, RF or PXI along the way is an extra kicker out of the kindness of my own heart.

That would indeed be a nice thing. I have a little utility in the Code repository that will take a class or library and create palette files based on the virtual folder structure. For classes it will also walk back up the hierarchy, creating palette files for each parent class. The palette files are added to the class or library and the 'root' palette file is set as the default palette. There is also an option to do this for every class or file in a directory tree. In principle such a tool can be integrated into the project window, but you need to know details of the project provider API. There is a group on ni.com that one can apply to join to get this information I believe.