Leaderboard

It's guessing but I could imagine that there is actually a situation possible where the Test Stand Editor doesn't know about the Friendship of objects but the user may want to select a Community scoped class anyhow. If that class is then executed in a context that has friendship relationship it still succeeds. Otherwise it gives a failure. Bad UX maybe. A feature that makes things possible that should be possible, quite likely. Fixing that may require to teach TestStand about LabVIEW implementation specific details and present its test adapters in a way that forces dependencies into the TestStand paradigma that it doesn't really care about otherwise. Likely weeks or months of extra work and a brittle interface that can fall flat on its nose anytime LabVIEW makes subtle changes to something in these implementation specific private features. Much safer to leave this inconsistency in there, save time, sweat and money and call it a day.

The 32-bit version may be difficult to test. 2016 was the last version that had a 32-bit version of LabVIEW both on Mac and Linux. After that it was 64-bit only. Not sure how many people still have a 2015 or 2016 installation of those.

One of my UIs has a problem where it can chug down if you throw too much data at it. The underlying problem is formatting I'm applying to a native LabVIEW multicolumn listbox (MCLB). I'm not aware of any way to get events out of the MCLB when an item is scrolled into view, etc, so the application just blindly applies formatting to the entire list. Not a problem when I wrote the application because the data set was at most bounded to perhaps 1000 rows. Being in R&D, we're never happy though and my colleagues who use the application started throwing data sets at it that can have something like 100 000 rows. Yeah, the UI bogs down for minutes at that point, even with UI updates being deferred etc. Simply performing hundreds of thousands of operations on the MCLB even with no UI updates takes patience. Now ideally I'd like to have better support for the native MCLB, but for now I need to work with what I got so I figured I'd kludge together a pseudo virtual MCLB in native G-code. Here's a proof of principle: virtual mlcb lv10.vi If you run the VI and generate some stupidly large data sets, say 100000x8, you'll see that the render time hopefully stays constant as you scroll through the data, and with a little luck is reasonably fast. Now if I could make a virtual tree view...