JackDunaway

Since there's been a bit of chatter about Front Panel Cleanup -- four years later, I find the desire for a Front Panel Cleanup indicative of a more root desire to just "spend less time creating a functional View for the method interface; I'd rather delegate this task to the IDE and language definition". I've been thinking the correct way to do this is to allow SubVIs to be created without a Front Panel; instead, integrating the interface UI into the BD itself. This requires half a dozen small (perhaps, controversial?) steps redefining things like Terminals and ConPanes and Local Variables (spoiler: locals are properly deprecated, since true dataflow has no analogue to a traditional "local variable"), yet could fundamentally improve the mental model of how we perceive the links between VI components and how they represent the composition of logic. (e.g. -- currently, how would you explain to a beginner how data flows from a diagram to a front panel, and from the ConPane from a FP into a subsequent VI's diagram? the mental model departs quickly from the IDE representation, making LabVIEW a booger to "get") tl;dr: Front Panel Cleanup is a band-aid for the root problem of SubVIs being required to have Front Panels (no offence to the novice who first suggested this on the LV IdEx)

Agree, wholeheartedly. I've pined for the past couple years to apply functional programming to all my application domains. A recent realization is functional programming simply just doesn't map to many problem domains. Key business logic such as actuation and user interaction often blows referential transparency (i'm finding that pure functions are better applicable in purely computational domains; personally, I just don't spend much time here). That said, the quest to eliminate mutable state in hopes of achieving pure functions has, at worst, led to more maintainable code. (Simply -- striving to minimize crossing code boundaries with data, and especially references to data or objects, for all levels of procedural abstractions, down to structures) I've found functional programming and object-oriented programming (see also "pants-oriented clothing") are just two roughly-orthogonal components to the bigger picture -- service- and actor-oriented programming. OMG, AQ, Scala; you're right. All this shit does converge to something useful. (A CLA Summit that focuses on practical LabVIEW implementations of programming paradigms; that's a CLA Summit I'd go to.)

That's not OCD, that's a fantastic way to ensure your syntax can be synthesized by a measly human. CTRL+Scrolling through your diagrams, the human eye can handily diff similar cases. I'd gladly inherit your code anyday, sir. (I bet, you even understand why "Make Space" inside a structure is reserved only for Sinners)

Does the offending VI contain a Diagram Disable structure? While you're checking, do an object search on the entire hierarchy for Diagram Disable structures, and missing VIs in disabled cases. Likewise, search your project by right-clicking the root node and selecting "Find Missing Items"

Would you elaborate on what was broken? I'm intrigued. (One of the usual suspects for code that works in the IDE but a build that fails is to check the hierarchy for Diagram Disable structures. If the structure contains disabled but missing SubVI, App Builder will fail. This is typical on EXE builds but not installers, so I'm curious to learn more about the failure mode you fixed!)

Here we are a year later; I no longer consider Community scope as a tool in my API design toolbox, for reasons in this thread, but more importantly for reasons in this thread. Making the change from "Community" to "Public" caused more mental/academic anguish than practical problems (i.e., it felt improper and dirty, but I've yet to find even a single negative ramification).

Agree on use of "Application Directory" (it looks like a primitive on the File Constants palette). I prefer to structure my dev environment file structure the same as the deployment file structure for scenarios like this; e.g., a folder called "Support" at the same level as the LVPROJ in the dev environment, which maps to the same relative directory as "Support" (or "data") sitting next to the EXE in the deployment environment. However, in your case, since this the development of a COTS product; you may consider implications of statically linking this DLL rather than dynamically linking, so that App Builder takes care of the rest for your API end-users building EXEs. Since this toolkit is probably installed into vi.lib (rather than your project directory, i'm just guessing here), that's one minor level of complexity more than the method described above of straight mapping between dev/deployment environments.

Austin: if the library is statically linked to your application, App Builder should suck in the library as a dependency during the build -- the LabVIEW API would be bundled into the EXE, and the statically linked DLLs referenced by the API would by default go into the support directory "data" next to the EXE. Perhaps, you're dynamically linking or lazy loading this API? If this is the case, consider marking the file as Always Included from the EXE build spec properties dialog.

Under VI Properties >> Window Appearance, is "Show front panel when loaded" checked?

Have you heard that joke about UDP? You might not get it... (But seriously; just subscribing here for the emails out of interest on this topic)

Favorite feature: LabVIEW Web Services in 2013 -- the R&D Team nailed it with the all-new LVOOP API

For those of you joining us at NIWeek 2013: Regular Pricing is available only three (3) more days -- grab your tickets here: lavag.org/bbq-tickets And if you would like to sponsor a door prize but have not yet decided what to get, bring a couple of these and become everyone's favorite person ever:

Special thank you to Jon at JGCode in Australia for sponsoring this gift even though he is unable to come to NIWeek this year. It's very generous, and we're glad to have him a part of the LabVIEW community.

The general term for this is "object relational mapping".

Did you happen to catch the announcement a while back (LV2010 era) that LabVIEW source was being compiled to DFIR (DataFlow Intermediate Representation) and then to LLVM IR (Low Level Virtual Machine) before being compiled to target-specific machine code? Let's look at LLVM a moment; it's exciting. This acronym is not just some LabVIEW R&D mumbo jumbo; the LLVM compiler is something that has cause quite a stir in the programming community for some time now. In 2012 -- two years after NI R&D publicly announced that LabVIEW was leveraging LLVM -- LLVM won the ACM Software System Award. Who else has won this yearly award given to only one project? Ever heard of, say, UNIX? Java? The World-Wide Web? Eclipse? Apache? Shite -- i guess this makes LLVM A Big Deal. A couple top-notch articles I've caught recently include: "IR is better than assembly": https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/ "Kaleidoscope and the Lexer": http://llvm.org/docs/tutorial/LangImpl1.html And my favorite, for the dear memories and sheer genius of this guy: "Statically Recompiling NES Games into Native Executables with LLVM and Go": http://andrewkelley.me/post/jamulator.html This stuff is blowing my mind, and I'm really glad to know LabVIEW has hitched its wagon to LLVM. Keep it up, Compiler Team -- chime in here and tell us more.

Maybe someone in Austin wins it and *I* am lucky! (Psstt -- split it with you, fellow Austinite, if you want to double our chances of winning some BBQ!) On second thought... sad times... as one of the organizers I'm disqualified from being in the drawing :-(

Wirebird Labs will sponsor two (2) Leap Motion Controllers. Announced yesterday, a new marketplace for Leap Motion software has opened at airspace.leapmotion.com, featuring 75+ applications. See you at the BBQ! Screenshot from https://www.leapmotion.com/product

Not a stupid question at all! We have a complete roster of everyone signed up, so you should not need to bring anything. It would not hurt to have an email of the receipt on your smartphone, just in case. But certainly, no need to print. The only thing we would strongly suggest bringing is your NIWeek Name Badge. Not so much for identifying yourself at the registration table, but so you'll feel more comfortable meeting new people and networking. Pro-tip: the badge holder is a perfect place to stash 8-10 biz cards.

Friendly bump before many of you go away for the US Independence Day long weekend: Early-bird pricing ends this Friday, 05 July 2013 at midnight, Austin time. After that, ticket prices go up $5USD. Register today, and bring that extra Abe for the cash bar! (*an Abe is a $5 bill)

Of course! http://lavag.org/topic/16930-lava-bbq-2013-door-prizes/ And for those planning on sponsoring door prizes: there's a field during ticket checkout where you can enter information about intent to sponsor a prize. Feel free to mirror that information on the public thread linked. Between both channels, I will be sure to follow up with you prior to the BBQ to ensure we've got all the details.

Hi KJ, there's a board devoted to this on the NI forum, there you'll likely get a quicker turn-around on LAVA -- http://forums.ni.com/t5/Version-Conversion/bd-p/VersionConversion -- good luck!

Are deployed systems guaranteed internet access and the ability to ping a license server?

+1; incidentally, for the good article; fundamentally, for what's in the pipeline.

Bingo. Sounds like you'll be fine, since this Launcher VI remains reserved for execution as long as the top-level VI remains running. But just to watch out for in the future, here are two places this can get tricky: When shutting down your application: If the top-level loop stops before the clones stop, the Event Ref will go invalid since its lifetime is tied to the top-level loop. Fortunately, the Events API grants immunity against this, because the Event Registration Refnum can have a different lifetime than that of the Event Ref. In your example, the event ref lifetime is tied to the static call chain of the Launcher up to the top-level state machine, while the Event Registration Refnum is tied to the lifetime of the Clone (presumably, if the Clone is calling the Register For Events method). For this reason, it's OK for the top-level loop to send a final "Shutdown" message and then immediately close the Event Ref -- even though the Messenger is now gone, the Mailbox remains valid with the final Shutdown message in its queue. When you're running the Launcher directly from the IDE in order to troubleshoot/develop the clones: If you were to run this VI directly, it would launch the clones, but the User Event references would immediately die as this Launcher is no longer running or reserved for execution. Common misconception -- even though it remains in memory (since the panel remains open), and even though we passed the references to VIs that are currently running, references created by this VI go invalid once the VI finishes execution. One way to circumvent this, is to create a trivlally simple "Debug Launcher" VI that makes a static call to the launcher and remains running until a simple event (shown below):