Lycangeek

NI Blogs

Just wanted to let people know about the new page at ni.com for NI bloggers: http://www.ni.com/blogs. We are just five right now but I'm hoping to see that number grow over time. If you share my hope, please let us know - either post a comment on any of the blogs or send mail.

Thank you, B.B. King

Sunday night was a wonderful experience. The legendary B.B. King came to Austin's own Backyard arena and performed a benefit concert for the Austin Humane Society.

It was a magical Blues night. The concert opened with Bobby Bland and his band for the first hour. To add a bit of pixie dust to the event, the audience contained none other than Clarence "Pine Top" Smith - the great blues pianist who has retired to Austin. Unfortunately, Pine Top didn't play any songs, but was called out by both Bobby and B.B. to take a bow. I was thrilled because I was just one row behind him (a few seats down, but still).

B.B. came out and the energy really shot up. Bobby's first hour was great but a mellower tempo. B.B. came out and immediately jumped into some higher beat pieces. For those that don't know the Backyard, it is an outdoor event location - and the outdoors was in rare form. Thunderstorms had been going across the area for the entire weekend, and when B.B. started, the sun had fully set and there was a constant supply of lightning going across the sky - it was almost surreal.

Luckily/unluckily the sky finally opened up on us around 10pm, but that was about the time the concert was to wrap up anyway. The idea of a encore was right out as I watched the rain, driven at an angle, drench the stage. I was almost expecting security to run out and jump on Lucille to protect the famous guitar. But what a show!

Welcome Nigel

Gotcha! This isn't another NI blog intro, but a welcome to the new furry addition to the Tyler home. Nigel is a foster dog that we've had for a short while - but in that time he has wormed his way into the hearts of my wife and I.

He is a 5 year old dog of currently undetermined breed. We have heard Papillion X, Sheltie X, King Charles Spaniel (both X and non-X). I'll need to do some more research myself.

Yes, I am still planning on continuing the foster work for Sheltie Rescue once he has gotten himself settled in. Although the amount of shedding caused by three long coat dogs doesn't bare thinking about...

Welcome Charles

Another LabVIEW developer has joined the blogging ranks. Let's all welcome Charles to the blogsphere. Again, please check out his blog and fire up comments if there is anything you would like to know more about.

TrackBacks

I have no idea what I have done to the RSS status of my site, but I realized that I had TrackBacks turned off. They're on by default now but apparently I needed to go back to previous posts to enable them there also.

So, if you have an RSS reader and suddenly got several of my old posts again, I apologize. But fear not, you don't have to go through them again - lol

ForceVIEW

Got this forwarded to me on an internal email thread - thought you might like it. Can you see LabVIEW hard at work helping the FX guys on the new Star Wars movie. Can you spot it?

http://www.starwars.com/episode-iii/bts/me3/3.html

Unfortunately I was not invited out to help on this project so I have to go by the film, but it appears that it is being used for motion recording and playback for the space/air craft in the scene.

And no, I haven't seen III yet. I will, but my drive to see it just isn't there like it was for Phantom. However, early reports are that it is much darker and more adult - which makes me quite happy. My favorite has always been "The Empire Strikes Back".

Welcome Joel

Joel is a software manager here at National Instruments and he has just started his new blog - so welcome Joel to the blogsphere!

You are going to love his topics as he was the manager over the LabVIEW Performance Team for many years - so expect a lot of great information about how to get the most out of LabVIEW. And as I have asked (but no one has taken me up on...shame on you), feel free to post comments to him (AND ME) about topics you would like to see. Even if we aren't the experts on them, we can track down the right people here at NI to say a few words on them.

Some handy VIs

There was a good question on the DevZone today and I realized that it would be a good idea to broadcast out the information a bit more widely (assuming this blog is a broadcast point - bit of ego on my part I guess - lol).

Anyway, as you must have noticed, the .NET integration with LabVIEW automatically provides conversion between .NET types and LabVIEW types. For example, if you drop down a .NET Invoke node and it takes a .NET string, you can wire a LV string up to it. Same thing the otherway around - drop a property node that returns a .NET string, for example, and a LV string comes out.

There are cases, however, when we don't know what conversion to do. As in the case of the DevZone question, the .NET method takes an array of .NET objects. So, how do you pass in an array of LV strings? The answer is in two little hidden VIs in the vi.lib directory: "To .NET Object" and ".NET Object to Variant" (go look in <vi.lib>/Platform/dotnet.llb).

The first VI, "To .NET Object", simply takes in a LV Variant (although you can skip creating the Variant and just wire up a string, integer, etc) and returns a .NET Object refnum. If you need a more specific type, you can then use the "To More Specific Class" node in the .NET palette. Make sure you wire up the error clusters as the conversion is a run time check.

The second VI, ".NET Object to Variant" does the exact opposite - it takes in any .NET refnum and attempts to covert it to a native LV type. The attempt comes out in a LV Variant, so you then use "Variant to Data" to expose the specific type (string, integer, etc.)

Cash all gone

That one goes for the record - our foster sheltie "Cash" went to his new home yesterday. I think we had him for less than 9 days. Whew!

He is such a big sweetie and loves to play with other dogs, so I am very glad that he has gone to a home with another sheltie. This family had recently lost their 2nd dog to cancer and their current sheltie was obviously affected - becoming lathargic and sad. I think a few days with Cash is going to turn that around - here's hoping!

Network Paths and AppDomains

Here's an interesting issue that has come up recently. As you may already know, .NET provides several layers of security for .NET applications. One of these layers is very similar to the Zone concept in IE. When an assembly is loaded into .NET, where the file came from is very important. If it's loaded from the local disk, it's assumed to be fully trusted. However, if it comes from the network (even a mapped drive), it isn't.

Here is an important piece of information from MSDN regarding AppDomains. Note that the ApplicationBase is simply the home directory for the AppDomain.

"The ApplicationBase property can influence which permissions are granted to an AppDomain. For example, an Appdomain originating from the local machine normally receives full trust based on its location of origin. However, if the ApplicationBase of that AppDomain is set to the full name of an intranet directory, the ApplicationBase setting will restrict the AppDomain permission to a LocalIntranet grant even though the AppDomain actually originates from the local machine."

You're probably saying "Wait a minute. You were talking about assembly locations and now you are talking about AppDomains...what gives?"

Well, of course, it is regarding LabVIEW and .NET.

If you recall, in LV version 7.x, we create an AppDomain for each top level VI that runs (see all my earlier posts on this topic). In Constellation, that's changed to one AppDomain per project. In either case, the ApplicationBase setting for the AppDomain is tied to a file (the directory of the VI in 7.x, the directory of the project in Constellation - or LabVIEW's install directory if you haven't yet saved a project).

So, what would happen if said VI/Project was on a network drive? Not much. Meaning, of course, not much would run. You're application probably wouldn't make it very far because LabVIEW's .NET code needs full trust.

I should also point out that this is the same problem you are going to have if your assembly is on a network drive, even if the VI/Project is local.

Solution?

But of course...

There is a handy little tool that ships with the .NET framework called caspol.exe. This creates security policy settings that tell .NET to consider a given network drive to have full trust. For example, imagine that your code is on the Z: drive, which is a network mapped drive. You can add it to the trusted list by the following command:

caspol -q -machine -addgroup 1 -url file://z:/* FullTrust -name "Z Drive"

Now everything should work fine.