jzoller

Hi JoeC, That was actually a style choice: I couldn't come up with a use case where I wanted to try to read a blank INI file. I would rather throw a "missing file" error. Of course, it's an easy mod to make if you prefer the creation: just set the file create flag in GenINI_Read_Template.vi to true. Thanks for the feedback, Joe Z. Hi SAS, I seriously considered doing that. To do it right, I think I would want to unflatten the data to have another level (that is, an array of Section clusters containing a Key Value pair array). In the end, I made the decision that the extra constants were easier to live with than the extra complexity in the generation code. Thanks, Joe Z. Thanks! I'll look into the ability to abstract out which config files are used... <famous last words> it looks pretty easy </famous last words> Joe Z.

Over time, I've found writing INI files (section followed by key/value pairs) to be easier than writing the LV code to read and write the INI files. So, here is a small tool to automate the generation of code for reading and writing existing INI files. Download zip, open project, open and run GenINI_Main.vi. Point the top file control to an existing standard INI file (like the one included in the Test folder, for instance) Click the "Read File" button, and select the Key Type for each entry from the INI file. Click the "Generate Code" button to spit out the read and write VI's (saved in the same folder as the INI file). There are a fair number of limitations and possible enhancements, but I would love to hear any feedback people might have before I complicate this too much. Thank you kindly, Joe Z. GenINI.zip

I'm trying to extend Darren's history probes a little bit. The idea is to use an XControl within a probe to allow better inspection of the data that's being probed. Unfortunately, the probe seems to end up missing data events if they occur too quickly. Anyone have an idea of what might be going on, and whether it can be fixed? Thanks, Joe Z. --------------------------------- I'm no expert on XControls, but a LV2009 demo is attached: the XCon_Probe folder and XCon_Probe_String_History.vi go into the probes folder (On Windows, it's My Documents\LabVIEW Data\Probes). The XCon_String_History_Test.vi goes wherever, with the custom probe placed on the format output string. XCon_String_History.zip

In addition to reading, I'd encourage you to actually create some object models, on paper, of real world systems. It's one thing to read about whether the Square class should inherit from the Rectangle class or not (what is it with OO authors and shapes?... and cars?) It's quite something else to try to make the messy, analog world into neat packages with clean interactions. It's fun, though! Joe Z.

Of course, the term geek originally meant a circus performer who bit the heads off small, live animals. Such an odd word permutation. Joe Z.

The issues aren't technical (well, primarily, since I've seen LuaVIEW's daemon cause some stability issues), they're financial and company cultural. And (rewrites post 7 times) ...a bit too detailed to go into here. PM me if you're really interested in details. Joe Z.

mesmith is right: this is a function library, not really a state machine. I wouldn't try to diagram it. Rather, I'd describe each "function" (or case), with pre- and post-conditions expected. If it modifies a variable with multi-function scope, I would add that as well. I would also document typical use cases for each function and for the program flow as a whole. However, I see nothing wrong with this style of programming: it's powerful and flexible. The problem with inserting states into other state sequences can be solved by adding a batching mechanism to the architecture (I use a second queue). I've found the licensing limitations and additional software requirements of TestStand and LuaVIEW are really restrictive in the environments that I work in, and a native LV solution is usually easier to handle. ... then again, I like to build compilers, so maybe this should be taken with a grain of salt Joe Z.

If you're using MyODBC, you may need to update your driver, or possibly recompile with an optional switch. From http://bugs.mysql.com/bug.php?id=7445: As far as cursors, it appears there may be a mismatch between MySQL cursors (http://dev.mysql.com/doc/refman/5.0/en/cursors.html) and the DBCT cursors (http://www.ni.com/pdf/manuals/321525c.pdf, page 62)... not sure how well they'll work together, but I haven't had the toolkit for a while. Joe Z.

Warning! Installing newer versions after installing 7.1 will remove your 7.1 DAQ drivers. Such a charming behavior. Joe Z.

Congratulations!

Oh, fine One can guide charged particles through free space using fields generated by guide plates or guide wires. For instance, time-of-flight mass spectrometry uses this: http://en.wikipedia.org/wiki/Time-of-flight_mass_spectrometry. For the pulse of energy itself, you could use anything that generates a gaseous plasma or free electron cloud: laser, ebeam gun, etc. All of these (including various ball lightining experiments) require large amounts of equipment and power, positioned very carefully, and aren't terribly useful outside of scientific fields. Hence, no public demonstrations of lightning guns.

Wiki: Paiʻea is said to have had a dour disposition, and acquired the name he is best known for today: Kamehameha, from the Hawaiian language term for "the lonely one".

I'm still not sure of your motives, or what you mean by "real time" but... If you're looking to learn something, C++ graphics (like OpenGL) has a fairly steep learning curve, especially if you are new to C++ as well. If you like a challenge, you'll learn a lot. If you're looking to create something, have you considered LV's 2D and 3D picture controls? Joe Z. Edit: Another possibility: could you use Java/JNI to draw onto an AWT canvas? (http://en.wikipedia....ative_Interface)

Ask http://stackoverflow.com/. Much bigger crowd. Joe Z.

http://lmgtfy.com/?q=kamehameha (Just a joke. Sorry, I love that site)

Yep, 2pm is the witching hour in the summer. Joe Z.

I'll try to be there... can't guarantee, work's been, well, a lot of work lately. Joe Z.

Hrm. How to put this diplomatically. I'll just settle for calling my IT management "extremely conservative".

Sorry for the delay, my RSS feed didn't pick up the replies. Unfortunately, I work directly for the (40k+ person) company, and don't have the ability to keep virtual machines or separate partitions... or a modern browser, or a number of other things developed this millenium. I guess I'm stuck with the manual version for now. Thanks all, Joe Z.

I can work with that...

Skinning at least implies an intermediate layer of architecture that abstracts the UI (as in Model-View-Control). Changing a background is just an environment change. I think skinning capability is a user-land responsibility, but, as the original topic shows, LV makes it painful. Joe Z. Edit: oh, one more solution. Use a picture control to imitate the appearance of buttons, and swap images on it.

Changing a background isn't even close to skinning.

There are a couple of social solutions as well. Saying no to multiple interfaces is sometimes valid. Or, deliver an "initial version" with only a single interface, and see if they really want multiple interfaces. Of course, if they're paying hourly, then you may not want to argue... Joe Z.

For simple types, you can use <LV>\vi.lib\Utility\VariantDataType\GetTypeInfo.vi. There are other useful bits in that folder, too. I wish they'd put some of these on the default palette... it always takes me a few minutes to remember where they are! Joe Z. Edit: "On closer inspection...". Of course, ShaunR's answer is more correct for your question. Sorry, I'm not used to this side of the AM/PM

My users are in a medical development environment. Sometimes, they're a little paranoid about updating. Joe Z.