David Boyd

Rick, Tables in LV are always an array of strings. There's no 'conditional formatting' as such, but the attached VI gives a trivial example of using property nodes on the table to recolor the cells at runtime. Hope This Helps. Dave Download File:post-10-1088696703.vi

This is a very minor behavioral issue with the editor, but I wish I had some control over this. When a for- or while- loop is resized, the iteration (and conditional, for the while loop) terminals maintain their locations relative to the loop border, unless they have a wire attached. If they do, they stay put. I'm one of those wire Nazis about this particular issue. In my own code, I try to keep these guys down in the corners, for consistency's sake. I get annoyed looking at someone else's code and having to play 'hunt the wumpus' to find where they relocated these terminals. Now that wires autoroute, couldn't the loop terminals be made to move with the loop resizing, perhaps as an option with yet another hidden INI setting?

Jim, Just did a quick test and it does support the case selector terminal on my LV7.0 installation. What does the status box say when you select the case selector and an output terminal? Dave

Here's another one I wrote awhile back. Now that the ability to get a BD refnum is out there, I suppose there's no harm in posting this. If you really want to have fun with your coworkers, get a refnum to a BD on THEIR machine via VI server and run this..... Have fun, Dave Download File:post-29-1080065315.vi

OK, since it seems someone's taken the lid off the undocumented stuff (at least partially), I'll share a little utility I wrote last summer. Have you ever added another shift register to the while loop of your state machine, then cursed while adding default thru-wires across sixteeen of the seventeen cases? This has happened to me a few more times than I care to admit, so I wrote the attached little gem. I called it 'Tunnel Wiring Wizard' for lack of a better name. It's a floating tool that will autowire all the unwired cases after you highlight the left and right case tunnels and push the button. I recommend that you drop it into your 'Projects' folder so it'll show up on your 'Tools' menu. I'd be curious to know if anyone finds this useful.... I'm leaving the diagram locked for now, sorry. Dave Download File:post-29-1080058291.vi

This has been confirmed in email correspondence with NI. When converting an OLE Date variant, or an OLE BSTR variant formatted as a date/time, into a timestamp value using the 'Variant to Data' primitive or the 'Database Variant to Data' primitive (this one is exposed on palettes which ship with the DB Connectivity toolset), the timestamp value will be off by an hour if the current DST setting is not the same as the DST setting in effect for the value being converted. If converting to a LV string value, the primitives behave as expected. My workaround involves getting the DST flag values for the current timestamp and the converted timestamp, and adding an offset to the converted timestamp based on the difference between the flags. I've attached a VI which can be used in place of the Var2Data primitives. Dave Download File:post-16-1073112847.vi