jzoller

It'd be nice if it were down around $250, like Visual Studio, but we don't have anywhere near the volume that MS does to be able to make back our expenses at that low a price.

And of course, you won't ever sell enough while the price is closer to $4.3k US. And no, I don't know how to cross that gap... or if it should be crossed.

I wish NI had an ISV program (https://partner.microsoft.com/40066412, for instance), but, as far as I can tell, they've chosen to forego that market.

<shrugs> I develop in C# on my own time now. I'm sure NI will never miss me.

Joe Z.

I've built a couple XML function sets. It's a good-and-bad technology.

Positives:

->Everything mentioned above.

->I love XPath support.

Negatives (which may not affect you at all):

->Everything mentioned above.

->File size bloat: there's a lot of overhead in most XML tags.

->Memory: Most (all?) libraries with LV use the DOM system, which means the entire file needs to be put in memory. This can be prohibitive if you're storing a lot of data.

->Brittle structure: simple changes to the XML schema can really mess with your code. Using a predefined standard like ATML may avoid this.

->Validaton: If you decide that you need validation, it can require a painful amount of work to get things just right.

->External libraries: most XML writing and parsing is going to require dragging along some non-LV library (ActiveX, LibXML, .NET, etc).

->Possible memory leaks: many XML libraries require a lot of references to be opened, and it's not always straightforward when they should be closed.

->Searching is relatively slow: Again, in order to search, you need to read in the file, then traverse it. This is much slower than doing something like a fixed offset column search.

Joe Z.

Open Query XML Document for Multiple Nodes.vi (from the example finder), and delete the error line immediately after the for loop. Save what you're working on... and run the XML VI. LV apparently fishes around for a moment, then goes away.

Joe Z.

x-post to http://forums.ni.com/ni/board/message?board.id=170&message.id=437600

OOP.

Depending on how you prefer to learn, you may want to grab a good book and stick to "low fidelity prototypes" (pencil & paper) rather than learning the oddities and corners of LVOOP.

Joe Z.

I have serious doubts about the willingness of NI to fix bugs, that are not totally critical.

Unfortunatly bugs like these (semi-minor cosmetic) are easily dropped from any known issues list.

Very strange that such things happen.

Ton

Since this actually works if you run the selection backwards, I was hoping it would be a nice low hanging fruit (as my project managers like to say) for NI to easily fix.

this may remain for quite some time considering NI is planning to release a new version of LabVIEW every year - JustinThomas

I wish I could dispute this, but there's still the mentality that "new features sell new customers". I don't really think that's so true anymore, given LV's level of maturity. On the other hand, I've yet to see marketing put "with over 200 bugs fixed!" in a major product announcement.

Maybe you should also post this in the LabVIEW Idea Exchange to get it higher visibility.

Hopefully, the Idea Exchange doesn't get too cluttered with bugs. Maybe the idea to post is for a LabVIEW Customer Bug Ranking system... what's causing the most pain for end users?

Thanks all,

Joe Z.

MCL = MultiColumn Listbox

Broken since... erm, 7.1ish?

To see the bug, select the first element in the MCL, scroll to the bottom, and shift click the last element. It pegs a processor core, too.

To see the correct behavior, restart the VI, scroll to the bottom of the MCL, select the last element, scroll to the top, and shift click the first element.

I'd hate for it to fall off the bug list.

Joe Z.

x-post to http://forums.ni.com/ni/board/message?board.id=170&thread.id=436150

MCL_Bug.vi

Any possibility that you could use a web service instead of a direct .NET call?

This would essentially wrap your .NET call into a local process, which can hand off safer payloads of XML (or JSON or whatever) across the network.

It can be quite a bit simpler as well... though, if you have a restrictive IT department, it can run into human problems due to the need for a web server

Joe Z.

LV 8.6, dynamically calling a VI with an XControl from an exe with the debugger attached. The build failed to bundle some things into the exe... nothing new, but the error messages are nice

c:\builds\penguin\labview\branches\Saturn\dev\source\linker\xlinker.cpp(739) : DWarn: GetAbilityVI should never have to actually load the VI; Nick Neumann was wrong. Go yell at him now!

c:\builds\penguin\labview\branches\Saturn\dev\source\panel\xctlVICalls.cpp(353) : DWarnInternal: Expected async ref, something's gone awry!

x-posted to: http://forums.ni.com/ni/board/message?board.id=170&thread.id=435384

...Are you looking for a framework to help with resizing the fp during runtime?

That's close.

The system I'm thinking about has embedded rules to deal with how front panel items are rearranged when the screen is resized.

... but it looked quite complex so I stopped

That's the impression that I've gotten so far: it's a difficult problem.

I suspect that the diagram cleanup code was worse, though

Does anyone know if a flow layout method for front panels has been attempted?

For instance, Silverlight's: http://msdn.microsoft.com/en-us/library/cc645025(VS.95).aspx. (I need to stop learning new tools. I keep finding features that I want!)

Thanks,

Joe Z.

I'm pretty sure crelf was being facetious. There is a rumor that on more than one occasion our IT guy has throttled crelfs network because of torrents. I'm sure he was just downloading some large linux distro, and not any copyright protected video content.

Maybe crelf was just madly posting to LAVA...

Maybe you understood me wrong. I wanted to change a string into an Integer Array.

Thank you

For ascii:

http://zone.ni.com/reference/en-XX/help/371361F-01/glang/string_to_byte_array/

If you need integers rather than U8's, you'll need to convert to them. Using http://zone.ni.com/reference/en-XX/help/371361F-01/glang/to_long_integer/, for instance.

Joe Z.

Joe,

Thanks for doing some digging down the rabbit hole, but as expected there is no good reason for the failure at the moment.

What I do suspect and have currently re-architected around is the fact that because the Quick Drop VI is dynamically loaded, it must somehow not be a valid accessor of the .NET references even though it's through a VI that is still reserved and resident in memory.

Yes, you can easily farm this list of quick drop items outside of the quick drop window and load them elsewhere and it should work.

The re-architecture is instead LVSpeak Engine now a receiver of all commands and is in charge of registering them within the MS SAPI which should resolve any issue with someone else registering commands outside of the VI that owns the .NET constructor.

All is going would love to use you as a guinea pig tester if you're up for it.

Open invitation to anyone else encountering the same issue.

I'd be glad to guinea.

Joe Z.

Getting ready for the exam myself. I thought Darren's blog had a nice, practical approach:

http://labviewartisan.blogspot.com/2009/02/labview-certification-preparing-for-cla.html

Joe Z.

I don't think that's entirely true. If you look at the wires on those arrays where you expect allocations, you'll see that those are not exactly Arrays, they are "sub-Arrays". See this AQ post for more details: http://lavag.org/top...mensional-array -> post #13.

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.

duh

Joe,

Close and re-open LV (just to clear all stuff from memory)

Enable LVSpeak

open this VI <LV>:resourcedialogQuickDropEnable Voice Command.vi

Then open QD and see if an error is tossed on the output of that VI

If it is as I suspect, then I don't have an immediate fix, but I am working on the re-architecture of LVS as I write this so that patch will be coming soon.

Sorry about the error, but it's something insidious in the bowels of LV that seems to be causing it and I haven't been able to dig that deep into the beast.

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,

Strictly speaking you can't do what you are asking. A pure hexadecimal number is an integral value and cannot represent a fractional value. You can get the hex representation for the binary value of the double value but without knowing the internal representation of the value in terms of the mantissa and the exponent the hex value is rather meaningless.

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.

If the VI didn't know about the library:

• Scope enforcement would not exist. A VI is broken unless its library is loaded... this is because LV assumes that if the library is missing, you're trying to access a VI that is marked as private by the library.
• Loading a VI needs to load its library so that it is *always* namespaced. Otherwise loading a large VI hierarchy would suddenly fail unless you loaded all the necessary libraries first because you would have a bunch of VIs with all the same file name colliding with each other.
• Classes, XControls and StateCharts -- all of which are libraries -- would not work.
• Licensing restrictions from NI would not work

That's it. ;-)

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.

River and Bottle would be Projects. You can do the described feature with projects (and manually resolving your name conflicts).

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

Joe Z.

VIs are normally known strictly by name. When a VI is added to a library, the library name becomes part of the VI name in memory. For instance, I have a VI called "Initialize.vi" for two different libraries (in my case, N5700 and KE2425). These are for power supplies. The Agilent N5700 and Keithley 2425 need different initialization processes. If I didn't put Initialize.vi into a library, there would be a conflict. So I made the two libraries. Now I have, according the the LV memory space, "N5700.lvlib:Initialize.vi" and "KE2425.lvlib:Initialize.vi". Two different VIs.

So I guess the short answer to your question is because the lvlib is part of the VI's name in memory space.

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.

It is also part of a lvlib's protection mechanism - In an LVLIB you can specify that a VI is "private", ie the VI can only be used as a subVI in other VIs that are also part of the library. Therefore, the VI in question needs to know what library it is a member of so that LabVIEW can check with that library where the VI is allowed to be used.

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.