Stobber

Staab Engineering will ship you a vacuum-sealed Texas BBQ brisket from La Barbecue. http://labarbecue.com/ http://www.yelp.com/biz/la-barbecue-austin http://www.austinchronicle.com/blogs/food/2013-04-26/la-barbecue-turns-ups-the-heat-with-secret-pit-technology/ About $- value, depending on where I have to ship it. I hope crelf doesn't win!!!

Almost certainly yes.

Simon Hogg at NI figured it out: Put the decoration on a .vi and add that file to the control palette. You'll have to change the file browse dialog's filter from (.ctl, .xctl) to "all files" so you can select the .vi. It gets added to the palette and drops its decoration onto a new front panel just fine. We could think of it as a "merge VI" for front panel contents!

I need to create a custom "Decorations" palette. You can't drop a control file with only decorations on it, though. And you can't put a "merge VI" on a controls palette. Any ideas how this might be accomplished?

I see where your API formats the timestamp to a UTC string in the "Bind" VI, and I see where it parses a UTC string back into a timestamp in the "Column" VI. That should work. I'm going to test my code again and make sure it's not a logic error on my part. If I don't post back, disregard this bug report.

I'm having a little trouble with timestamps. If I bind a timestamp to an INSERT statement as text, it gets converted internally (by your API or by the db) to UTC. When I try to SELECT a record using that value, I get no results because the timestamp I'm using is local time. If I INSERT the timestamp as a blob, my SELECT works, but that makes the field illegible when viewing the database in an external program. Do you know how to get it working with timestamps bound as text?

No...and I have no idea what I was asking for with this comment. Ignore it. (I had collected comments in a text file and pasted them here without review.) [citation needed] Nah, all my statements are developed and tested in a real SQL editor and pasted into string constants on the diagram. I'd probably never develop statements directly in LV code.

James - I just used v1.0.3.16 in a small benchtop product test application, and I think it's fantastic. The API makes sense and is flexible enough without getting cumbersome for simple tasks. Great job! I did collect a few points of feedback that I'd like to share, though: Could you expose a read accessor for "database path"? It'd save me some effort when wrapping the API in higher-level classes. Could you remove ".lvclass" from the class Localized Name (in the Properties dialog)? It'll make class property nodes smaller on the block diagram. I would make the tunnel mode "indexing" on "Get Column Template Code.vi", since that's how it's used 99% of the time. Please put your package in <addons> or <user.lib>, not directly into <vi.lib>! This would be backward-incompatible, but I'd like to see the VI names changed so they're more "Quickdrop friendly". At present, there are names like:"(,,,) FROM.vi" which is hard to type "Get Column Template code.vi" which I think is confusing to read and remember "Open.vi", "Close.vi", Step.vi", etc. which are hard to discern from other libraries (and primitives!!!) whose palette items share the same simple names. Many (all?) of the VIs don't appear in QD unless the API is added to my project. This might be due to the API not living in <addons> or <user.lib>.

Sorry Todd, for some reason I didn't receive notification when you posted your comment. Yes, it should be "clean" to do this since you're ignoring the error out from Send Stop. It looks analagous to firing the "Shutdown" event in Stop Core.vi to make sure the event handler exits when the message handler is stopped. Frankly, I've had trouble figuring out all the corner cases for shutting down an actor that gets itself into an error state. Its two-headed nature (message handler and AC.vi override) makes that a tough problem to solve, especially since every actor is unique.

Name: Data Broadcasting Library for Actor Framework Submitter: Stobber Submitted: 01 Apr 2013 Category: *Uncertified* LabVIEW Version: Not Applicable License Type: BSD (Most common) Use v1.0.0 for LabVIEW 2011-2012. Use v1.1.0 for LabVIEW 2013+. The attached library provides extensions to the Actor Framework to facilitate the broadcast of messages from one actor to several others. Listeners subscribe to a message when they want to receive it from the Broadcaster, and they unsubscribe when they want to stop receiving it. The library provides a set of common interfaces that decouple Broadcasters from Listeners so any two actors in a messaging hierarchy can communicate via broadcast without having the same caller. This library extends the Actor Framework; it does not modify the core framework in any way, so it may be used in existing projects as well as new ones. Documentation for the library and the included example program is attached. Click here to download this file

Update: AQ's suggested workarounds still work, but they're also still a PITA. Anybody know whether this need is met by LV2013?

Any specific advice on how? I've been looking into this and don't see an obvious solution. LV seems to intercept the Tab keystroke for its own moronic purposes.

AristosQueue worked on the team that wrote that node (or wrote it himself). I would ask him.

They're not formally documented anywhere AFAIK. You can figure them out pretty easily by inspecting "General Error Handler.vi". I would definitely try to make use of them so the native error functions work correctly on your enhanced error strings. NI's "Structured Error Handler" component uses them in similar fashion; you might be able to glean some direction from looking at its source, too. (I would link to SEH, but NI.com is down for maintenance.)

Ah, I thought you'd gone through the trouble of registering for and reporting all the events possible for lots of situations. I've done it a few times before when planning out a UI design for specific cases; I thought I might be able to snag a general-purpose tool.

Who says it would have to be taken in English? NI has personnel all over the world and operates their business in lots of common languages. Besides, the current multiple-choice exam is subject to the same limitations.

The sample exam is (sadly) a very good indicator of what the real exam will be like. Study the reference texts (AAL and MSEL course manuals) in gory detail, take the sample exam, and you've got a 70/30 shot at skating by. If you don't have copies of the course manuals, talk to your local sales rep about borrowing them. Point him to this thread if he needs convincing.

Yeah, I like to use it for the "magic pattern" of unbundling/bundling exactly the same elements in a cluster, or for double-splitting arrays to operate on an entire row at a time (which I don't think you can do sans-IPE). Seeing the structure in my code six months later gives me a reminder that I need to tread carefully with edits.

I don't mind multiple-choice exams in general. People tend to use them because they're easy to grade, but they are much harder to write than freeform exams while keeping them effective at achieving your testing goals. I recall that they provided the option of taking the original 4-hour exam after all the negative feedback; it seems a good stopgap until a new exam is written.

Not to hijack the thread, but are you referring to the IPE structure here? I still use that a lot to minimize copies when manipulating large structures.

I noticed about a year ago that there are several properties, methods, and events that only work with single-pane VIs. Pretty much everything called "Panel" changes (or breaks) its behavior when you add a splitter or subpanel to the FP. In those situations, as others have recommended, use the "Pane" events when possible, and beware coordinate system conversions between "Panel" and "Pane" properties.

Minh, do you mind back-saving that to 2011?

I took my CLA-R today and have to say that it was really frustrating. Ambiguous scenarios, questions that used double-negatives in their wording, and references to materials I'm confident I never saw in my 8 hours of studying the AAL and MSEL course texts yesterday. All that aside, the very most frustrating thing was the realization that this exam did nothing to test my capability as the architect on a software development team. Rather, it tested my attention to the (often self-conflicting) details of NI's training products on (1) software project management, (2) minutia that can be figured out by clicking around for 30 seconds if you happen to run into them while coding, and (3) features of LV that 95% of its users never ever need or want. Given the nature of this test, I honestly don't think I can use someone's CLA as evidence of their capability to help me design a complex solution to a client's problem. I'd say a CLD is a more valuable litmus test for LV developers; shame a more aggressive weeding out of those skills hasn't been codified yet.