todd

They don't lock, here. (One reuse VI was missing, by the way.) But when I close the projects, the example VIs don't close.

I'm getting an error when closing the client:

I ran the 2013 DETT on it. There are two queue ref leaks and four VI leaks, but only when I manually stop the server.

Thank you for this. Since I'm working on template projects, I used your code firstly to improve my understanding of top-level actor launching and of Actor Core.vi.

When the Event Structure's while loop ends, Actor Core's parent might still be running (if the developer makes a mistake and does something other than sending messages to self - see image below). This prevents Last Ack, which hangs the app launcher. Is it "clean" to fix this by sending Stop after the while loop?

Excellent, thank you. For the record, there has been no trouble locking every .vi, .ctl, .lvclass and .lvlib file - in any order.

Oops - forgot you'd covered that.

^{I studied hardware, not software, so take this with salt. If you make a toolkit, users with your abilities (meaning high-level) will be able to use it despite the lack of perfection. Users at my end of the skill range will find a way to mess up our code no matter how much you club us over the keyboard and mouse with contracts. What about including a lint-type script in a dashboard that searches for the non-implemented must-implements?}

I do want the code to be visible. I am not currently worried about the setting being changed. Primary concern is that someone (including myself) opens a VI and knows right away that it's in a library/package. Thanks for your input!

I've been packaging up all my reuse libraries with VIPM (Free). I want to avoid accidentally modifying those libraries while using them in another project. In a Post-Install VI, I iterate through the list of "Files Installed" and lock then save all .vi, .lvclass and .lvlib files. An up-side is that when I open a reuse VI or class, I know right away by its appearance. What are the down-sides?

http://thinkinging.com/2008/01/21/using-xml-data-in-labview-is-hard/

which links to:

http://thinkinging.com/2008/03/01/using-xml-data-in-labview-just-got-easier/

which links to:

http://jki.net/easyxml

In case you haven't seen it, remember to put ctrl-shift-g, in there:

https://decibel.ni.com/content/docs/DOC-12725

Does this help?:

http://lavag.org/topic/16660-how-to-get-actual-vi-execution-state/?hl=%2Bexecution+%2Bstate

Multiple lines in the string control end with Line Feed, not End of Line.

I agree that it's odd for ignore duplicates to provide different outputs.

I don't understand the problem. If you want to do something when the Knob value changes, perhaps start with the event structure:

<p>Since the version under your avatar says 2011, I provided links to the 2011 version.</p>

<p>And the first link is to a rar file. No need to install anything else.</p>

Perhaps add the class to the project? You could also look at the source for one of the Actor Framework Message Makers:

https://decibel.ni.com/content/thread/13809

https://decibel.ni.com/content/docs/DOC-25451

I don't know. I gave Main.vi something to do, though, and now both VIs stop when closing from the start bar.

If I combine this with more states instead of SubVIs then I could use local variables to reference the values of the enums instead.

Or keep the enum values in a shift register. Ooh, you could log and play back games, then, Or "undo" and "redo" moves.

I agree with hooovahh (including the "doing well" statement.

In addition:

Avoid duplicating code. In both VIs, there are case statements where both True and False cases write a string to a terminal (or its local). Move the terminal outide the case. I know it's a little thing, but being careful about it now will avoid trouble later. This also applies to creating two "This VI" references, and closing both.

Turn off labels for VIs that are obvious, and turn on labels for constants (instead of free labels) like row and column in the event structure.

Speaking of the event structure, you could turn those nine cases into one if you present the enums in a cluster, and use cluster-to-array for a 1d solution. Or use a cluster of 9 pic rings for the display, and convert it to enums in the code.

... i have connected output of the hall sensor to the input port of the DAQ and my daq is connected to my laptop through rs232 to USB (rs232 in daq and usb in laptop) ...

What is the DAQ card model number?

"Spec? This unit IS the spec!"

Hardware prototypes, iterating all the way to post-production tweaks of previous widgets. Com pipes can change. Byte format can change. And I need backwards compatibility - old hardware, kind-of-recent firmware, latest LV app test suite, add a new instrument to take the raw temperature instead of using the on-widget processor, ...  Every app has a pop-up parameter list with enums so users can choose versions for everything (or INI files for silent selection). Poster-child for DD, in my hardware-based mind.

Add another vote for more code*. I have communications classes (actors, actually), that allow Byte or string messages to happen over a few different kinds of pipes. These get used in more than one project. Instrument-specific command-to-useful-string conversions are performed in their own classes. Yes, lots of code - but extremely useful, in my case.

* Actually, I start with the simplest possible architecture for initial learning, then bring up the "better" code on the side.

I gave a half-answer just to point you to these forums.

Looking a little closer: is "Image Buffer Ref" a reference that gets created at run-time?

I don't see how this saves memory. If you're using this class strictly ByVal (not branching the HAL.lvclass wire and expecting the DVR contents to be the same on both branches), there are no duplicates of the Config data.

Threshold, in range and coerce and number-to-boolean array-to-cluster for display.

A little longer way around than how Shaun mentioned.

tones.zip

They stole your ceiling!

I worked with a smart guy who, when asked a question, would immediately give the answer. It motivated some people to work a lot more before asking him a question. "It was so easy for him! Maybe I can figure it out, this time." The people who came back to him with more questions tended to be either technicians or soon-to-switch-to-management-or-marketing types. (Hey, some of my best friends are managers and marketers.)

I worked with another smart guy who, when asked a question, would answer the question that should have been asked - but without telling the asker the difference. It motivated some people to never ask him a question again. Those who came back to him with more questions tended to be curious perfectionists - always searching for practical knowledge.

Forums have all types, so I vote with all those above who said, "give them both answers".