Leaderboard

Courtesy of Brian Powell:

> What's inside, borscht, kimchi or Chicago hot dogs? Inside? LabVIEW, of course. This is the pot we boil it in so it fits on an RT target. The left over broth makes excellent documentation.

Sounds like a First World Problem...

You, mi'lady, are asking for a feature we like to call "Zoom." And, no, there is no way to make LabVIEW itself bigger. Or smaller, for that matter. Your operating system might supply such features (use ctrl+scroll wheel on a Mac and you get the OS and all hosted apps zoomed in... quite nice). The feature to have LV able to zoom its diagrams/panels/etc is one that we are indeed working on, but when you have 20+ years of pixel manipulation code, it takes a monumental refactoring effort, and we are still a few years away from having that graphics layer reworked.

That gives me a new idea, perhaps there should be an option to throw an error (or warning) if a coercion takes place. Now if only there was some way to let NI know I had this idea....

Hey, neat! Your way of determining if a data type is an error cluster... ...is quite a bit simpler than the way I do it: Sorry to get off-topic, but I always like to recognize cleverness when I see it. The only time your way would run into trouble is when the variant is a cluster containing a non-I32 numeric type: In this case, since Variant to Data will convert any simple numeric type into any other simple numeric type without error, your way would determine that the cluster was an error cluster, but my way would not. Incidentally, this code that I use for determining if a type is an error cluster is located here: vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Check Type If ErrClust.vi.

You can use SQLite entirely in memory by using “:memory:” as the filename. Also note that SQLite uses a caching mechanism that makes it effectively in-memory as far as reading goes, as long as the database is smaller than the cache size (2 MB by default).

Thanks for the plug. I can offer a few thoughts: Like most things, I think the Idea Exchange has stages: 1. The IE is going to revolutionize LV. 2. The IE is going to transform LV. 3. The IE is going to alter LV. 4. The IE is going to change LV. 5. The IE is going to have an effect on LV. 6. The IE is going to have a small effect on LV. 7. The IE is going to have no effect on LV. I think we are headed down the list but I won't publicize where I think we are now. As to the Kudos weighting I can offer the old parable about the pious man on his deathbed who kept praying to win the lottery. Finally after a few weeks pass and he hasn't won, he questions his faith and asks God "Why have you foresaken me?" At that point God asks "Could you at least help me out by buying a lottery ticket?" No matter how small the chance of getting your idea implemented it is certainly improved by posting the idea. Personally I have given up on winning the beauty contest, instead I hope I plant a seed in a developer who someday works on a given feature and manages to toss it in there. Even this may not work, I have one idea which for many months had plateaued at 8-9 Kudos. Three of those were Jeff K., AQ, and Darren, Yair may have even been a straggler in that group. If support of the (un-?)holy trinity was not enough, what is? Finally, since no good deed goes unpunished I have attached a VI which will move all of your error wires to the back. I once had a need to do something to all of the error wires (and it was certainly not moving back ), but it was easy to adapt. MoveErrorWiresToBack.vi

For the Discovery Channel Telescope software, we make extensive use of libraries and classes. We never have this issue when editing classes. Perhaps what helps make this possible is 1. Programming to an interface, not an implementation: Abstract classes with pure virtual methods separate almost every call layer. 2. For each software component we do development work within several small lvprojs (with few dependencies), then only one large project from which we do builds but typically no development work. 3. Architect to avoid overly-complicated dependencies.