07-05-2006 04:07 AM
07-05-2006 04:39 PM
10-08-2007 02:02 PM
10-08-2007 03:01 PM
10-08-2007 03:16 PM
Hi Jonathan,
That was exactly what I was looking for. After reading your post, it occured to me that, perhaps, when an error 1172 is caught by LabVIEW, the VI could then call a property on the .NEt instance (e.g. "public System.Exception ErrorReason{get;}" ) that would contain the exception specifics. Anyway, thaks so much for your rapid reply.
Dave
10-16-2007 10:08 AM
10-16-2007 01:37 PM - edited 10-16-2007 01:37 PM
Hi Dave,
I'm actually kinda confused as to what behavior you are expecting verse what you
are seeing. So let me make some general statements and we can go from
there.
The first piece of information I wanted to mention is that LabVIEW
automatically provides conversion between .NET types and native LabVIEW types.
For example, suppose you had a .NET method that accepted a .NET string as an
input parameter. Well, you can simply drop down a .NET Invoke Node, select the
method, and then wire a LabVIEW string up to it. The same conversion works for
the opposite direction as well. If a Property Node returned a .NET string, you
would notice that a LabVIEW string comes out.
Now there are cases where we don’t know what conversion to do and so LabVIEW
displays data types it can't convert as .NET refnums. You can then wire
that object into an Invoke Node or Property Node to call methods or get/set
properties. You can see the data types that we can convert in the Data
Type Mapping sub-category in the Using .NET with LabVIEW section found in the
LabVIEW Help.
I am not sure I understand your .NET interface question. Interfaces simple
contain the declarations of methods, properties, and events.
Implementation is done in the class that inherits the interface. You don't
apply a method or property to an interface. Thus I am a little confused as to
what you need to do.
The "To More Specific Class" node is used when you need to downcast a
.NET refnum to its derived class. The "To More Generic Class" node is
used to upcast a .NET refnum to its base class.
Maybe you can clarify what you actual problem is?
Best Regards,
Message Edited by Jonathan N on 10-16-2007 01:38 PM
10-16-2007 02:32 PM
Jonathan,
First, as always, thanks for your quick and informative reply.
>The first piece of information I wanted to mention is that LabVIEW automatically provides conversion between .NET types and native >LabVIEW types.
Right. No problem with that so far. The "type" returned from the object property is an instance of a class that implements a specific interface. That's where my learning curve starts.
>Now there are cases where we don't know what conversion to do and so LabVIEW displays data types it can't convert as .NET refnums. >You can then wire that object into an Invoke Node or Property Node to call methods or get/set properties. You can see the data types that >we can convert in the Data Type Mapping sub-category in the Using .NET with LabVIEW section found in the LabVIEW Help.
Ah. Never thought about using the Invoke Node. For some reason, I was thinking that was for asynchronous calls. I will investigate.
>I am not sure I understand your .NET interface question. Interfaces simple contain the declarations of methods, properties, and events. >Implementation is done in the class that inherits the interface. You don't apply a method or property to an interface. Thus I am a little >confused as to what you need to do.
K. Here's the deal. I am using the "command design pattern". In a nutshell, this .NET interface is a distributed system that sends commands and receives responses from client(s). So, instead of building a base class (CommandBase) and deriving commands from that class (CommandA : CommandBase, CommandB : CommandBase, ...) I am using an interface to delcare the type and then dynamically binding the commands as they come across the wire. There are many reasons to do this; the key is that I want the interface to drive implementation. If I derive from a base class and I need to change _anything_ in the base, it means that I have to consider all of the commands developed on both the client and the server. So, for example, say CommandA, CommandB, CommandC, ... all implement ICommand, then,
ICommand cmd; // Declared an instance of a type
// implementing the ICommand interface.
// ("Code to an interface, not an implementation")
cmd = CommandA; // Dynamically bind a command.
cmd.Execute(); // Execute CommandA.
// In this application, the command is passed to LabVIEW
// and the vi executes the command based on the command's
// properties. So, the method Execute really is not really executed in .NET.
// later...
cmd = CommanB; // CommandB received, dynamically bind.
cmd.Execute(); // Execute CommandB. Ditto.
So, taking this one step further, I pass cmd to LabVIEW via a property into a property or invoke node. What I am seeing now is that LabVIEW “sees” all of the Interface properties and methods, but no any of the other public properties and methods specific to, say CommandA, verse CommandB.
Now, that said, I think my mistake may be not using interfaces properly, which is probably the case. To use this scenario I am using a "To more specific class item casting the ICommand. I think what I need to do is 1) Explore your suggestion of the Invoke Node further, and 2) Consider my interface implementation in more depth. Then, based on my discovery, follow-up with an example project that you can download and load to see what it is I'm trying to accomplish (that is a basic simple project that highlights the key points). Does that sound like a plan?
Thank You,
Dave
10-16-2007 04:20 PM
10-17-2007 09:01 AM