Leaderboard

I do a lot of this, but oddly enough often shy away from it for UI interactions. Architecturally my frameworks are often designed around this. BaseClass is designed to receive SomeMessage which invokes a dynamic dispatch BaseClass:OnSomeMessage for which child classes may override as desired. In the end the underlying transport layer disappears and largely becomes irrelevant to the component designer-- all that matters is picking off the right level in the hierarchy and implementing the right overrides to hook into the larger application. The framework could be event based, home-baked queues, actors, or voodoo, it doesn't matter much at the component level. I don't find myself using this type of framework for handling too much of the controls in a UI though. Dynamic registration is very powerful, but at the end of the day your dynamic event registration is not extensible. What do I mean by this? If your register for events node is set up to work with ten different events, that's all it will ever do. The next level in the hierarchy can't add another set of events, it needs its own registration. Add to that the venerable front panel is filled with statically defined interface elements means I don't see too much use for objects in this context. Yes, my frameworks may have some level of inheritable functionality that implements an OnCancel method or the like, but at the end of the day they're method calls that are made from a single event structure in a single loop, in a single VI. Don't get me wrong, I use a ton of dynamic events, just not in the inheritable OOP context.

Hello forum LAVA-ites, I am attempting to write a Tools Menu item to slot into the IDE. The intent of this "Tools" VI is that it determines the application instance that launched it and dynamically run a VI in that application instance so that the launched VI can access VIs in that instance. This is basically a custom Unit Testing tool that looks for particular VIs in the project that houses the application instance. I was attempting to use the App.MenuLaunchApp property in this "Tools" VI so that I could wire up an Open VI Reference node with the right application instance and the name of the VI to run dynamic VI to run. I added an extra indicator on the launched VI to show what application context it is running in. If I have a VI open from a Project and then launch the "Tools" VI from the Tools menu, then the dynamically run VI indicator shows "My Computer" (referring to the project housing the application instance). However - if I launch the "Tools" VI from the Tools Menu while Project Explorer is showing then the dynamic VI launches in the NI.LV.Dialog irrespectively (the indicator on the front panel of this VI shows this). Is this expected behaviour? Is there a way around this so that the dynamic VI gets loaded into the right application instance even if launched from Project Explorer? Thanks in advance.

Ha! Maybe, Hooovahh. I think the fate of all the prizes will rest in the hands of the event MC (Justin Goeres again? Jack?), but maybe the stars will align. Maybe I'll end up with the Teensy or the Android mini-PC. There's a few projects I've had in my back pocket waiting for juuuust the right hardware.

Finally got the confirmation I can go. Now to frantically buy everything. Also Hooovahh Incorporated a division of Hoover Corp is donating a Teensy 3.1 microcontroller.

Have a look here on the dark side for an example of how someone has done this sort of thing programatically.

You don't need to duplicate the code. Just pass in the address to talk to Keithley A and Keithley B or, if it is already a "process", make it a Clone VI and launch an instance with the appropriate address.. If you switch to Classes, the methods will still be all very similar, only you will be forced to make each one atomic. Classes are very similar to polymorphic VIs in how they are constructed so if you have a VI with a couple of operations in a case statement (Set VISA/Get VISA, say) then you will have to make each one a separate VI, not only for that Class, but any overrides too. This is why classes bloat code exponentially and there has to be very good reasons (IMO) to consider them in the first place let alone if you already have a very adequate working system..

Greeting, wireworkers! I have an idea and a need for some software development tools, just not the bandwidth to develop them by myself. Would you help me? Problem description: I find myself needing/wanting to visualize dependencies of code modules in LabVIEW. A "module" is loosely defined here, as perhaps a library, a VI, a project... Current tools available: VI Hierarchy gives a nice view of static dependencies of a single VI; Class Hierarchy gives a decent view of a project's object model; the Dependencies section of a LVproj give a good listing of all static dependencies of the project. Rationale for a new tool: Make it easy to visualize how code modules are interconnected, to be used as a debug and design tool for system architectures written in LabVIEW. Want to help?: Just drop a line -- either private message or email. Ideally, you've got some experience with the LV Linker and Javascript; no worries if not, I can help out. Likewise, ideally you've found yourself wanting similar tools to enhance your experience developing systems. What happens to the tools we create?: The immediate goal is to help ourselves on our own projects and scratch our recreational programming itches; in the future, perhaps there's enough polish and interest to release open source to the community. Here are a few ideas: 1. Dependencies of top-level application modules (interactive source: http://www.findtheconversation.com/concept-map) 2. Relative size of libraries and their inter-connectedness (interactive source: http://redotheweb.com/CodeFlower/) 3. How VIs connect to each other, grouped by library (interactive source: http://redotheweb.com/DependencyWheel/) 4. Coupling and cohesion between methods grouped by library (interactive source: http://bl.ocks.org/mbostock/4062045)

I recently spent some time describing a logging tool that we use here at DMC that has significantly reduced our debug times and helped a lot with onsite support and I thought it was worth bringing it up to the LabVIEW community. Essentially, it's a logging utility based off of NLog that allows the user to add the equivalent of print statements to their code - any string that can be built is fair game. It also allows a logging level to be associated with the print statement and this is the concept that makes it extremely powerful. Some statements can be low-level "trace" statements, while others are "warnings" or "errors". During run-time (even in an executable) the level of the logger can be changed and you can easily do trace-level debugging for a glitch, and then set it back to an informational level afterwards. Multiple targets are supported, including RT console, log files, TCP/UDP streams, and email. All the calls are made asynchronously, so the debug statements have a minimal impact on the code execution. At this point we are finishing and polishing the implementation, but more information and details can be found in a blog post I recently wrote: NLog for LabVIEW: Logging done properly -Jody Koplo

At some point, a debug problem becomes so thorny that a programmer must declare that the current debug tools are insufficient and spend time writing new tools before proceeding. In my current hobby-at-home project, I've hit that point. I spent this entire weekend writing a couple of tools for tackling parallel debugging. One tool that I haven't written (yet) is a custom probe to simultaneously pause parallel VIs, and I want to know if anyone has already written such a beast and would share it so I don't have to build it. What I'm imagining is this: A custom probe that has on its panel an array of paths to other VIs. When the custom probe trips, it passes True for its boolean output (to pause the running VI) and it also calls Pause VI method on all the VIs listed in the array. There would be an option for each path to pause all the reentrant clones of the path or a particular subset of reentrant clones. I need this to debug an event handler and to keep the parallel VIs from continuing to generate events. A couple of times, I have gotten very close to the source of a bug only to have LV run out of memory because the background VIs continued to generate events and queue stuff up. It's really annoying. Basically, I need this probe to do what a breakpoint typically does when there are parallel loops on the VI's diagram -- it pauses both loops. But put both of those loops into subVIs and now you have my problem. PS: Bonus points if the custom probe registers the pause with some central debug tool that has a list of all the paused VIs so that all of them can be told to unpause as a group rather than finding and hitting the Pause button on every diagram (which in my case could be 10 to 20 VIs).