asbo

This is the LabVIEW Simulation Interface Toolkit, right? If you're still receiving licensing errors, you're probably still calling one of the toolkit's VIs somewhere. How exactly does the toolkit ask for a valid license? When LabVIEW starts, or when you actually run your code?

Ooooh, good call.

Practically copy-paste from mine You should wire your Sequence ref through the first for loop and close it. You probably won't ever have a problem without doing that, but it's just The Right Thing To Do.

Touché! Odd, though, the code I posted worked fine with XLS and XLSX in Excel 2007.

I've been meaning to learn Postgre for a while now. Do you have much experience with it to contrast with MySQL? (Sorry to hijack, Cat )

Take a look at Sequence.GetNumSteps() and Sequence.GetStep(). We use this code in an OI to pull out all the steps in the Main StepGroup to do almost exactly what you're trying. The preconditions are overkill; You can use Step.SetRunModeEx() directly once you get the Step object. If you want to do this in a VI, generate a default action VI and use the SequenceContext object that gets passed in.

The data out from the read and into the write are identical, yeah, but you've overlooked a pretty important terminal on the write node: The "prepend array or string size" parameter needs to be set to false or LV prefixes a value to your data when it writes it back to disk. Pretty silly default value for that parameter, if you ask me.

Edits are mod-approved?

Ooooh, shiny. I need more excuses to work with databases so I can play with all this stuff I'm missing out on.

Good call - with that in mind, sending "\1B40\n\r" is really sending "\1B\34\30\n\r". Definitely not the same thing.

Someone else raised the same "full duplex" question on stackoverflow. What I glean is that the duplex mode has no bearing on the flow control, so you should be able to use none. Looking at their example for "Read Model # & Date", you should write "\1B40\n\r" (notice no spaces) and receive something like "125 dd MMM yy". If you get a garbled response, try changing the flow control around.

The flavor depends on why you're going with a database. I prefer MySQL over MSSQL (though you make a good point about internal resources). If you don't need network access, SQLite is a fast, portable option. ShaunR actually just released a slick toolkit for working with SQLite. Another limiting factor could be deployment - is this going on RT or just desktop systems? As for design principle, I learned most of what I know through trial-and-error so I don't have any particular resources to suggest. At least a handful of people on LAVA are knowledge about DB design, so you could always post specific questions about speedbumps you run into.

The Match Regular Expression node does have a multiline parameter to account for that; when set to True, the ^ and $ anchors no longer match line endings and the . wildcard will also match \r and \n. But more importantly, you should rarely, if ever, write a regex that uses that . wildcard. You might parallel it to global variables in LV - there are valid use cases, but they are far and few. Using more specific matching makes debugging and readability much more straightforward. Though my solution does have a flaw - if there's a nested > (within an attribute, for example), the regex will break. This way why regular expressions are almost never the correct solution for HTML/XML/*ML problems, it's a job for a proper parser (TidyHTML, for example).

Try using a property node, not the property browser. Worked for me. As for your focus issue, controls (in general) have a KeyFocus property. That may work to give your SWF control focus at run-time.

If you change the ScaleMode property, you should find what you're looking for. Values from -1 to 3 are valid, I think, but I don't know what each is necessarily defined as. If I had to guess, this ActionScript doc on StageScaleMode are the descriptions. If you share your VI with the associated SWF, you may get more help the first issue.

For the record, /<(.*?)>/ is considered a fairly "bad" regular expression. You should work with something more like /<[^>]+>/. A cookie to whoever can explain why that's better

Since LabVIEW is my friend, I prefer to think of them as personality quirks

No, the reference wouldn't go invalid - LabVIEW would prevent the VI from unloading from memory -because- that reference is still open. I don't think that there's a way that a subVI could force itself to go out of memory in that scenario.

What a wild goose chase ... there's no pig avatar in sight.

Personally, I like this option. Gets me right in the game To turn if off, go to Tools > Options > Environment and untick "Skip Getting Started window on launch".

Or SQLite?

Is that VI reentrant or have any other unique execution settings?

It would be much easier if you uploaded the code itself to look at; that's a fairly involved BD ... Pre-allocated arrays are a good step, but are you familiar with circular buffers? Used properly, they practically guarantee constant memory consumption.

Can you post the code? Either way, sounds like you could benefit from converting the code to a state machine.

IIRC, you need at least 8.6 for that toolkit, but I could be mis-remembering. Either way, I'll vouch that it has a learning curve of its own, but once you get the hang of it, it can be a very valuable asset when you push the limits of LV.