For those that have been following our foster dog, Chance, you'll be amazed at what happened yesterday - the breeder who had raised Chance found us! She was looking over the Austin Sheltie Rescue page, saw the picture of Chance, and recognized him. She's sent us this great picture of him as a puppy, and is going to donate to help with his care!
While the nose is much shorter and the body not so thin, this is so Chance. That look he gives is unique. If you want to learn more about Chance, check out my Dogscategory, read from the bottom, looking for titles with Chance in the title.
Okay, I'm probably making a bad rep for myself among LV folks, but what can I say, I think this is pretty neat.
One of the great things about .NET is that it supports multiple languages under a single runtime (C++, C#, VB.NET, etc). In addition to these traditional languages, scripting (aka Dynamic or Weakly Typed) languages are also supported. For example, you can use Python or PHP.
So, getting back to the topic, I've been asked several times whether LabVIEW would provide a simple text interface to do some simple ActiveX or .NET programming. This often comes up when dealing with Microsoft Office, due to the amount of properties you end up setting. The same can also be said for the .NET WinForm controls that we host on the front panel - lots and lots of properties to set.
Of course, you can do this with LabVIEW using the property nodes, but I must confess that the ratio of pixels to instructions can get pretty high in some cases. However, using the scripting languages of .NET and LabVIEW can get you this...
Well, tell's you how out of the loop I can be! One of our LabVIEW developers, Marc Page, has created a blog (back in December no less) regarding LabVIEW on the Mac. I know that as a .NET guy, I've gotta just shake my head, but in truth he's also done some good platform neutral posts as well. Give him a try...he's good, if misguided :)
The big fix that we've put into 8.0.1, as far as .NET support is concerned (and what else is there, eh?), is the ability to get the output from array parameters.
In LV 8, we tightened up the invoke node so that it correctly mapped to a .NET method signature, but we did too good of a job. If you pass an array into a .NET method, we correctly reported it as an input only parameter.
Of course, the problem is that, in LV, the array is copied into .NET - thus any changes made to any elements in the array (say, for example, with a Read(byte) method), would be lost. *sigh*
But it's no longer a problem *smile*, so download away. Of course, you'll need to mass compile due to other changes, so make sure you kick that off before you go home for the night.
So, in a previous post, we discussed the new unmanaged assemblies that are used in VS.NET 2005. At that time, I mentioned that this had an impact on LabVIEW developers, and as you can guess from the title, it has to do with creating CINs.
Seriously, an interesting thread has started up here. I'd love for anyone reading my blog to jump into the discussion - let's keep it friendly because there's enough love to go around for both systems :)
And yes, I'll get the next post up today - the continuation on the VS.NET 2005 unmanaged assemblies. I'm actually about to head out of a couple of business trips (more as it happens), so it's been a bit crazy. But I'll have it up today...I promise...