jzoller

Sorry I missed this thread for a while Jason, thanks for the correction. Looks like I'm totally wrong... sorry Justin! What on earth would possess them to do this? Were there just too many memory allocations to use a standard array as an output? It seems like the compiler would need a lot of custom logic to handle a different type of array representation in memory, or at least a bunch of cases where it needs to know to convert to a "regular" array somewhere downstream. And I thought I overcomplicated things Joe Z.

Simple workaround: Load the quickdrop commands within the "Engine - QuickEdit.vi", immediately after loading the standard QuickEdit commands. I'm just loading them from a constant array. It looks like there's something on the timing of the standard QuickDrop command load that causes the problem I'm seeing. Joe Z.

A little bit more information: The error is occurring in the SpeechRecognitionEngine.LoadGrammar(grammar) method in MS_Speech - Load Grammar.vi. All of the references are valid at the time the error is thrown. http://msdn.microsof...521(VS.85).aspx - QueryInterface doc http://msdn.microsof...marbuilder.aspx - GrammarBuilder doc http://msdn.microsof...oadgrammar.aspx - LoadGrammar doc Not sure I'm ready to speculate why this interface cast is failing on this invocation, but not on others. --- A little more test data: modifying the dictionary that's loaded has no effect on the error: it's thrown for 260 elements, or 1 element. It's not the content being loaded. The SpeechRecognitionEngine ref on the LV side remains the same between all calls: it's not being switched to a different instance of the engine for some oddball reason. Okay, back to paying work. Have fun Joe Z.

Error 1172: Error calling method System.Speech.Recognition.SpeechRecognitionEngine.LoadGrammar of ObjectId handle: 0x8A81160 for obj 0x23C0C5D[system.Speech.Recognition.SpeechRecognitionEngine] in domain [LabVIEW Domain for Run] and thread 5264, (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. Inner Exception: System.InvalidCastException: Unable to cast COM object of type 'System.__ComObject' to interface type 'System.Speech.Internal.SapiInterop.ISpRecoContext'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{F740A62F-7C15-489E-8234-940A33D9272D}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)). ) in MS_Speech - Load Grammar.vi->Enable Voice Command.vi->QuickDrop Launch Window.vi->QuickDrop Launch Window.vi.ProxyCaller Never let it be said that MS didn't give you plenty of information... maybe not useful information, but there's lots of it Still poking around, will post if I find anything. Thanks all, Joe Z.

Hrm, no QuickDrop support on my XP (recognizes QuickEdit words, just not the words in QuickDrop). It looks like the problem might be occurring within the QuickDrop Launch Window.vi. Sadly, it's locked. Any thoughts? Thanks,

http://zone.ni.com/reference/en-XX/help/371361E-01/lvconcepts/how_labview_stores_data_in_memory/ IEEE standard.

Company policy forbids me from really commenting on this in a public forum (nor am I an expert), but check out http://www.fda.gov/downloads/RegulatoryInformation/Guidances/UCM124721.pdf as a starting point in the US. Joe Z.

Ah, thanks Aristos, that explains it. My personal use cases are a little different than NI's, so I wasn't seeing the reasoning. Joe Z.

Yep, that works... except for hierarchies of namespaces. Which application instance would your Bottled:River:Water run in? Joe Z.

That's a good description of how the system behaves, but not quite the understanding I'm looking for. Let me expand a bit Imagine a VI of Water.vi contained in Bottled.lvlib. Further, imagine that, unlike the current system, the VI knows nothing about the lvlib. The lvlib is more of a pathing "hint". The fully qualified name of the VI could be constructued depending on how the VI is loaded: from the lvlib, you get Bottled.lvlib:Water.vi. Loaded independently, you just get Water.vi. Further, the VI could also belong to River.lvlib, or other libraries. Changing the name of the lvlib wouldn't affect the VI, and different libraries could span common components. Namespace collisions would, of course, need to be resolved. Obviously, this isn't the way LV works, but I would guess that it was considered. So, why the two-way relationship? What breaks without it? Thanks, Joe Z. Good point. I've not looked into the protection mechanism: good food for thought. Thanks, Joe Z. Edit: need to think about this some more...

Something I've never quite understood... maybe someone can enlighten me. Why does a VI need to know which lvlib it belongs to? Joe Z.

Mhttp://herdingcode.com/?p=191 This one reminded me of the difficulties of having tool builders (MS or LV devs) and tool users (the rest of us ). Joe Z.

Looking for confirmation (or denial ) Dark side link: http://forums.ni.com...hread.id=426452 Thanks, Joe Z.

No. Each array has a dimSize of four bytes at the beginning of the array. You can't have a pointer to multiple arrays: it's possible to vary the decimated array sizes independently of one another, without another buffer allocation, by using the subset primitive. Edit: From the "How LabVIEW Stores Data in Memory" doc in the help. LabVIEW stores arrays as handles, or pointers to pointers, that contain the size of each dimension of the array in 32-bit integers followed by the data. If the handle is 0, the array is empty.

There's no allocation shown even with all outputs wired.

It looks like the decimate never shows an allocation. Given that the decimated arrays each has an extra 4 bytes (for dimSize) padded onto the front, they couldn't all be re-using the same memory... The sum of the parts would be greater than the whole.

Code generation is nice... but (somewhat) supported modification of the developer environment by the end users is why I'm excited. Joe Z.

QUOTE (crelf @ May 26 2009, 04:01 PM) Just throwing out ideas: instead of the standard error cluster line, imagine a bounded size queue of error clusters. It has the advantages of an array in that errors can be added or removed at will. It controls error size by being, well, bounded. And it allows you to commit code timing suicide by handling errors out of dataflow band . Joe Z.

QUOTE (Black Pearl @ May 7 2009, 08:44 AM) Most bug tracking tools have a type to fill in when a bug is filed. It's usually pretty easy to subvert this value to something like "Feature request". Two benefits: central feature management, and the ability to assign new features to specific releases (or oblivion ). I personally like the hosted Fogbugz version: http://www.fogcreek.com/FogBugz/. Free for one or two people. Favorite book: Code Complete by Steve McConnell. Favorite essay on Agile vs agile (warning: offensive to multiple religions, workplaces, Agile practitioners, and possibly humanity in general) Steve Yegge's [Aa]gile essay Are you really looking for software engineering tools and disciplines (SCC, UML, bug tracking, project management, etc), or are you looking for ideas on how to organize a group of coders for greater efficiency and productivity? The two are, in my mind, related but separate questions. Joe Z.

QUOTE (PaulG. @ May 6 2009, 01:19 PM) Wasn't there a system flag that allowed VI's to be hidden from the hierarchy? Rolf mentions it at http://forums.lavag.org/index.php?s=&s...ost&p=11539 Joe Z.,

Okay, this is (as usual) pretty far afield, but... Could the queue's internal lock/unlock mechanism have changed between versions? The compiler might be smart enough to recognize that the sequential only needs two lock/unlock sets, while the parallel needs many. Unfortunately, this is not easy to measure. (Edit: thinking more on the above, unless the queue has a lock-on-read, it seems unlikely. Sorry.) I suppose it's also slightly possible you're getting context switching issues in the parallel version. It seems unlikely, since that would probably cause a much larger delay, and having the queue run in more than one thread seems unlikely. On Windows, Process Explorer can show the switches, though... (http://technet.microsoft.com/en-us/sysinte...s/bb896653.aspx). Joe Z.

The editor is now a bit more graceful about large numbers of objects on the screen as well. For the record: Working code > pretty code, and NI's attempts to normalize the coding style are much appreciated by those of us who inherit the disasters of the past. Joe Z.

Hrm, let's see... vi.lib, 8.6: Description 17169 empty of 24142 checked (71.1%) Tipstrips 136540 empty of 137657 checked (99.2%) diag depth: 540 items above a value of 6 (2.3% of the total) # controls: 343 items above a value of 12 (1.5% of the total) # indicators: 79 items above a value of 12 (0.3% of the total) diagram width: 11744 items above a value of 1024 (51.0% of the total) diagram height: 3992 items above a value of 768 (17.3% of the total) Now, don't get me wrong. While I enjoy poking fun at the CLD expectations vs. reality, I think there is real value in showing the capability to write to a coding standard. Joe Z.

QUOTE (ShaunR @ Apr 13 2009, 08:11 AM) The LV development environment is very useful in debugging on the fly if you have live code. NI even supports it with a licensing option. ... yes, I know, everything is always tested before it hits the floor, and no one would ever dream of pig testing so that widget can ship by Friday. Right? Joe Z. (not my current employer, btw)

QUOTE (jdunham @ Apr 9 2009, 12:52 PM) Agreed, if you have an array of clusters. Using parallel arrays of results drops some of the complexity, though you still end up doing the index-and-sort routine. Joe Z.