Cast generic VI to strictly typed VI

Is there a way of casting a generic VI to a strictly typed VI through something other than from the Open VI icon? I'm trying to make a generic VI to handle the open and cast it where I need it.
Thanks,
Adrian
PS. I should mention that I am using LV 7.0 and have tried to use the "To More Specific Class" icon without success.
Message Edited by Been bitten by LabVIEW on 10-10-2007 03:18 PM

Yes, but it won't do you much good. You can't use a type cast (that's not
allowed), but you can use flatten to string and unflatten to string. That
way, you basically have what you've asked for.
All normal properties will work (only tried Panel Open). But the only reason
to do this, is so you can call the Call By Reference Node. And that will
fail. The node says something about the vi not being reserved. If you put
this code inside a sub vi, LabVIEW (8.2.1) will crash (R6025 - pure virtual
function call). This is not something that you'd want to use.
There are probably other ways to solve your problem, but you have to explain
what your higher goal is.
Regards,
Wiebe.

Similar Messages

Strictly typed refnum vs normal refnum for a waveform chart

I know that one way of clearing a waveform chart is to write an empty array to the 'history' property of the charts property node. The help file for this states: "use strictly typed refnums when reading this properrty"
I am looking at a program coded in LV 8.6
a number of control refnums are carried around in an array (so strict typed)
in some cases (but not all) the programmer used "to more specific class" to designate a waveform class when writing to properties for scaling the Y-axis, etc. Other times this is not done(?)
We are now having an issue which appears to be that the chart is re-initialized when dynamically rescaled (I am not sure if that is what is going on, but that is what it looks like).
It looks like when the chart is dynamically rescaled the previously acquired data is gone and the chart starts populating fresh.
Haven't figured out what is causing this, and I am wondering if strict type refnums vs generic refnums may be a factor?
Lawrence M. David Jr.
Certified LabVIEW Architect
cell: 516.819.9711
http://www.aleconsultants.com
[email protected]

Waveform charts can hold different data types (they are polymorphic), such as DBL or 1D-array of DBL. When you want to set the history, you need a 1D DBL or 2D DBL respectivily. The correct data type is part of the 'strict type', I guess you will get the default instance if you use the non-strict (generic) type.
But if this is releated to your problem, I can't even guess.
Felix
www.aescusoft.de
My latest community nugget on producer/consumer design
My current blog: A journey through uml

How to create a strictly typed refnum control using LabVIEW scripting

I wish to use LabVIEW scripting to create a strictly-typed refnum control that is bound to my custom control (a type-defined cluster), but I'm unfamiliar with scripting and can't see how to do it.
If I create a New VI Object, using Control Refnum as the Style, how do I provide my custom control to the VI Object Class terminal? When I try using a reference to my custom control.ctl file (using Open VI reference) I get an error: "Error 1057 occurred... Type mismatch: Object cannot be cast to the specified type."
Or, if I create a new Control Refnum as above, using a standard Cluster as the VI Object Class, how do I then convert this refnum control to a strictly typed refnum that is bound to my custom cluster control type?
Thanks in advance for any advice,
Thoric (CLA, CLED, CTD and LabVIEW Champion)
Solved!
Go to Solution.

Here we go...
You have to create a new Control VI and then specify the VI Type as Typedef.
Regards,
Da Helmut
Attachments:
example.vi ‏22 KB

Reference behaviour of strictly typed controls

I have a question regarding the bahaviour of a user-made cluster which I have set to strictly typed.
I am using a reference to this cluster (Which in turn contains other clusters) to automatically read an ini file. I also have an array within one of these sub-clusters (Main Cluster - Sub-Cluster - Array). I want to set the values within this array (The elements of which are also clusters) using only the reference to the control. This works fine, except for the fact that I cannot programatically set the index of the array if my control is strictly typed. If I change the control to type-def, it works.
Is this normal behaviour, and if so, can someone please tell me why? Does it have to do with altering the appearan
ce of the control?
Thanks in advance
Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)

I assume you mean "strict" type-def.
Go to www.ni.com
Search for "Application Note 159" (including quotes)
Look at http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/a9fbcaa7a3d7922186256a3000652b56?OpenDocument#10
Look at http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/1b04fd6a11e6f17286256c6300588bfa?OpenDocument
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

How do I get a strictly typed VI reference of a particular clone that is idle?

I need several clones of a VI that store different state informations. I considered passing data to and from these clones by the 'Call By Reference Node', and therefore used strictly typed references to call the clones. My problem is that each time the calling VI turns idle the references turn invalid. How can I access a particular clone to read out its state information in such a situation?
Thank you, Uli

Thank you everybody for so much expert support!
This was my first appearance in this forum, and it was a good experience.
Ravens Fan, thank you for the wrong browser advice. Obviously Mozilla does a better Job here.
Mike, I added another VI named '1_CallCloneByNameString.vi' to show that the clone name seems to be simply ignored (so, if you say 'open any.vi:1' it creates any.vi:2 or higher...)
I think the only way out is to keep the VI from finishing, as Pnt suggested.
It's just weird that when all VIs have finished the front panel of a clone might still be visible, but there's no way of accessing the data of its controls anymore...
Uli
Attachments:
0_CallCloneByStrictTypeRef.vi ‏16 KB
1_CallCloneByNameString.vi ‏17 KB
StateOfClone.vi ‏13 KB

Rules for casting generics type

I know that there is a section in jsr14 spec about rules of casting generic types, but it seems outdated with
JLS3.
It is obvious that e.g. Class<String> cannot be casted to Class<Integer>.
However in
<T,V> void foo (Class<T> ct) {
Class<V> cv = (Class<V>)ct;
The cast is permitted by the compiler though of course marked as unchecked (The cast should be rejected according to jsr14 spec since none of the types is a subtype of the other).
So the question is: what are the rules, compiler uses to check casts?

1. There is an (unsafe) explicit cast from l1 to l2.
2. There is an implicit cast in the last line, because
l2 is a List<String>, the line is compiled to the
equivalent of
System.out.println(" result:" + (String) l2.get(0));
// ClassCastException: java.lang.String

How to read the "Strictly Typed VI Reference" of a VI file on disk

Hi
I have a .vi file on disk. (e.g., C:\temp\my.vi)
How do I programmable read the connector pane "Strictly Typed VI Reference" ?
Br Per

Please explain what you are trying to do. Why do you need the Strictly Typed VI Reference?
If you want a strict type reference to a VI, get a "Static VI Reference" from the application palette. Right-click and choose "Browse for path...", select the VI ond disk, then right-click on the static reference again and choose "Strictly Typed VI Reference."
"There is a God shaped vacuum in the heart of every man which cannot be filled by any created thing, but only by God, the Creator, made known through Jesus." - Blaise Pascal
Attachments:
reference.PNG ‏7 KB

App Builder produces "Not Executable" error with Strictly Typed VI Refs

There is a very frustrating problem with the app builder in LV 8.0.1. Certain VIs compile and run fine in labview, but the app builder
refuses to make them into applications.
The error message is very long and ends with something like "The VI is not
executable". Standard advice for this problem is to force LV to recompile
everything you're building by either mass compiling or ctrl-shift clicking the
run arrow, but this hasn't worked for me in two separate cases (completely
different projects).
It seems that this problem is caused by wiring a strictly typed VI reference to
an invoke node with the FP.open method selected. In both cases I resolved
the issue by changing the Static VI Reference to be weakly typed (right-click
the static vi reference and make sure "Strictly Typed VI Reference"
is unchecked). After that, the project build successfully.
This is very hard for a user to track down for several reasons:
- The error message in the application builder does not give any
indication as to what the real problem is
- The app builder reports that the top-level VI is broken, even when the
strictly typed reference and invoke node may occur in a sub VI
- Nothing (that I can
find at least) in the documentation suggests that strictly typed references
won't work with the Open.FP method.
There is a page that says "some of the properties and methods do
not work when you configure this function to output a strictly typed VI
reference," but no indication is given of which methods fail
Note that in one case I was also able to make the project
build by deleting an instance of "IMAQ Create.vi" from the top-level
VI. I
have no explanation for this.
Hopefully this post will save some other users the trouble
of tracking this down and maybe even get NI to correct the issue for future
versions.
Adam Brewster

Hello Adam,
Thank you for sharing your experience and insight. Your post was well thought-out and offered a
good description of the problem as well as some possible workarounds. I believe that the issue has been filed and
is under investigation (3TU8T8V9). Feel
free to post back after the next LabVIEW release and inquire as to its status.
Thanks again,
Travis M
LabVIEW R&D
National Instruments

Selecting VI Server.Strictly Typed VIs in Class Browser crashes LabView

Hi!
My LabView 8.0 Pro on WinXP crashes in the following way:
0. Opening Blank VI.
1. Placing VI ref num on the front panel.
2. Going to "Select VI Server Class -> Strictly Typed VIs -> Browse..."
3. Loading any VI (say, "myVI").
4. Then going to menu: View -> Class Browser
5. Selecting Object Library: VI Server.
6. Selecting Class: Strictly Typed VIs - "myVI" icon.
Result: LabView crashes saying that there's error and application will be closed.
Besides there's a little question:
Did I get it right that if I change myVI connector layout or pins it's not refreshed in my
VI ref num and I have to load VI again (see step 2)?
Thanks in advance for any help.
Rashid.Message Edited by Rashid on 02-22-2006 11:17 AM

Hello,
I have reproduced this, but I think the menu navigation you indicated in step 2 has a mistake. I reproduce it with the following steps, and have filed a corrective action request to R&D on the matter:
0. Open a Blank VI.
1. Place a VI Refnum on the front panel.
2. Right-click on the VI Refnum and choose: Select VI Server Class -> Browse...
3. Select any VI (say MyVI.vi).
4. In LabVIEW click: View -> Class Browser
5. Select Object Library: VI Server.
6. Select Class: Strictly Typed VIs -> MyVI.vi connector pane icon.
Sorry for any inconvenience - the problem should be addressed in a future version of LabVIEW.
For your question, "Did I get it right that if I change myVI connector layout or pins it's not refreshed in my VI ref num and I have to load VI again (see step 2)?" - yes, I see the same behavior - you should save the VI and then select it again in the VI Refnum.
Best Regards,
JLS
Best,
JLS
Sixclear

Trouble with supposedly strictly-typed reference...

I'm having some issues with supposedly strictly-typed references.
Can anyone look at the code attached (LV2010) and tell me why the top example doesn't work and the bottom does. More over, what's the general way to make the top example work?
The discussion of strict and weak typed is rather short in the documentation in the help. Any pointers to relevant documentation would be appreciated.
Thanks!
Solved!
Go to Solution.
Attachments:
Test.zip ‏46 KB

I swear I read that help page like ten times and now I finally see the caveat in documentation. It would be nice if they mentioned this in the Enum Property page or in the table for Strings[] in the documentation instead of hiding it in the documentation.
That said, now that you say it, it's obvious why. I wish the error I received (1082, I believe) could also be a bit more specific as I don't explicitly make the enum a strict type def, it simply is implicitly.

Actor framework strictly typed message queues?

I'm just getting to grasps with the Actor framework. I have implemented "similar" stuff in the past but I've approached it differently.
One thing I noticed was how easy it is to send a message to an incompatible actor core which results in a nasty run-time "to more specific class" error.
In the example project included with LV 2012, if I make the change shown below (OK, I am purposely senidng a wrong message on the given queue) I get no feedback from the IDE that an incompatible message is being sent ont he queue. I think this has to do with the Message queues being for the base actor class.
Is there no way to have the actual queues more strictly typed so that we can say that Launching Actor Beta will result in a Queue reference which is only compatible with Beta (or children) objects or does this ruin the entire concept? If possible, it would prevent the ability oto send incompatible messages completely which IMHO would be an enormous benefit.
The presentations on the Actor framework have shown huge benefits in strict typing of state machines (I'm referring to a couple of videos I've seen ont he NI website) but this element of things seems to be just a pokey as a string flatten and unflatten. Send the wrong message to the wrong receiver and >bang< run-time error.
Just thinking out loud.
Shane.
Say hello to my little friend.
RFC 2323 FHE-Compliant

So two days and no reply...
I'm referring in essense to this part of the actor framework white paper as included with the template in LV 2012.
Messages from Callee to Caller
When a caller wants to send a message to the callee, the caller knows the type of the actor that it launched, so caller can easily choose the right type of message to send. But when an actor wants to send a message to its caller, the actor does not necessarily know what type of caller it has, so it does not know what type of message to send. Ideally, actors should be usable by many different callers. That maximizes code reuse. But making the actor truly independent of the caller requires more effort than is warranted for the situation. There are three techniques for defining messages that an actor sends to its caller
The High Coupling Solution—In this solution, the callee actor is written specifically for one type of caller, and can never be used with any other type of caller. In this case, the callee knows details about the caller's interface, so it may simply call the Send Message VI of the appropriate message. The message type is thus hardcoded into the actor.
The Low Coupling Solution—This solution works best when you have a known inheritance hierarchy of callers. In this solution, you create a matching hierarchy of callee actors. So suppose you have callers Hard Drive, Air Conditioner, and Fire Suppression, each of which needs to launch a Fan actor. You would create the Fan class, and then inherit from it Fan For Hard Drive, Fan For Air Conditioner, and Fan For Fire Suppression. Each caller launches its specific callee actor. All of the main Fan class' code is shared, but when it comes time to send messages, the Fan class has a dynamic dispatch method for doing the sending, and each of the children overrides that method to send the message appropriate for its caller. Each callee is still coupled to a specific caller, but the system as a whole is flexible to accommodate new caller types.
The Zero Coupling Solution—In order to make the callee actor independent from the caller, the caller must tell the callee what types of messages to send so the callee avoids picking a type itself. The best implementation of this solution has the caller record a message into the callee at the time the callee is launched. The callee provides a Set <Type> Message.vi method, where <Type> is the particular event that will trigger the message to be sent. The caller sets the exact message it wants to receive when this event occurs. When the event happens, the callee sends the chosen message, without any knowledge of what kind of caller is receiving that message.
Often the callee will define an abstract Message class that it uses as the input type for Set <Type> Message.vi. Callers create their own specific child of this abstract class. This setup gives the callee a way to set data into the message through the API defined by the abstract class, and gives the message a way to deliver that data in a form the caller can consume through the various overload and extension VIs.
Would it be possible to get some examples of the three different approaches to typing of the messages? I'm aiming for the high coupling solution (with the option of slipping to option 2 through common ancestors) in order to provide the ability to detect wrong messages on wrong queues at edit time.
Shane
Say hello to my little friend.
RFC 2323 FHE-Compliant

Question on Cast & generics

Only an unfinished idea (formulated as question in a may be wrong forum):
One of the big strength of generics is, that explicit cast may be avoided in many cases.
From day one Java inserted cast by itself where possible and clear. Using + in print() for all
kind of objects is a cast to (String) and this is handled via a special methods toString()
in Object.
I was always wondering, why a cast to type T is not treated as a "normal" operation , in case
where the cast is not well specified in the language or via generics. Now it inevitably leads to
an exception, without even sending a cast-message to the object.
Would it not be much more OO/Generic, to call something like <T> T cast(Class t) method
located in Object with a default behavior (throwing an cast-exception), which can be overriden
in classes to react individually on those casts, and not only in the special case +(String)object
by calling object.toString() .

thread "Request for non-throwing cast!" and your reply no. 7 and 9The 'design flaw' reply (no 8) by dcminter holds, but sometimes you have to work with imperfectly designed APIs, and that just have to use multiple if/then/else if ... constructs. This in turn doesn't mean that you have encourage bad design by providing default behaviour. See also reply 21 by lucretius.
and the track "Possible solution for unchecked casts?"That thread is not about providing new default behaviour, it is about restricting/improving present default behaviour (the unchecked cast)
But you may answer cast is not an operator.Cast is an operator, but it returns it's argument untouched when it doesn't throw a ClassCastException. This rule allows the compiler to optimize and remove type checks if it can prove that the cast's argument will be of the desired type. In combination with parameterized types, that has proven to be difficult ;)
I assume you want the Object.as() method because you find yourself writing the same conversion code on different places. In that case, I would advise to create some kind of Converter object that contains the convert() method:
interface Converter<T,U> {
   /** Convert an object from class T to class U. */
   U convert(T t);
   Class<T> getFromClass();
   Class<U> getToClass();
abstract class ConversionManager {
   /** get a converter that converts an object to class U. */
   public abstract <T,U> Converter<T, U> getConverter(Class<T> from, Class<U> to);
   /** register a converter that converts an object from class T to U. */
   public abstract <T,U> void registerConverter(Converter<T,U> cnv);
   /** Convert an object to class U. */
   public <T,U> U as(Class<T> tClass, Class<U> uClass, T t) {
      return getConverter(tClass, uClass).convert(t);
}Because this allows for multiple conversion managers, you can use different conversions on different places.

Casting, generics and unchecked expressions

Hi
I'm trying to access a vector of Recommendations held by a Person object, but I don't want to allow direct access to the vector, just the information contained in it
public Vector<Recommendation> getRecommendations() {
return((Vector<Recommendation>)recList.clone());
}The trouble I'm having is that I have to cast the recList.clone() as a Vector<Recommendation> to return a compatible type.
When I do this, the source compiles with a warning: unchecked cast.
Could someone explain an unchecked cast and give me a pointer to solving this please? I've not managed to find anything about combining generics and clones in my books. Is there another way of returning a copy of the vector? All I want to do is make the objects in the vector available for viewing, via processing in a servlet, to a jsp.
Thanks in advance

YoGee wrote:
What you are exposing is a Vector with a reference to a clone of the internal data array, you are not cloning the elements in that data array. So basically if you modify an element in one Vector chances are it will be reflected in the other (assuming the element is mutable).Thanks for the reply.
I should have said that what I want to achieve is:
make the Vector<Recommendation>recList contents available for viewing, but not expose the objects so that they are able to be changed - so what I have done is not good!
after some thought, what I really want is this:
If what you actually want to achieve is a deep clone (i.e. clone the elements in the internal data array) you need to do it yourself by looping through the Vector and cloning each element in it (assuming the elements implement clone properly)so thanks for the help!

Casting generics

Hello,
without generics the code looks like this
// Get the Map for this particular component
    Object componentMap = components.get(componentName);
    if (componentMap == null)
    { componentMap = new TreeMap();
      components.put(componentName, componentMap);
    return (Map)componentMap;
}If an Object is null, it is redefined to be a TreeMap. In both cases there is a cast to (Map) on return.
Now I tried
    Map<Object,Object> componentMap = components.get(componentName);
    if (componentMap == null)
    { componentMap = new TreeMap<Object,Object>();
      components.put(componentName, componentMap);
    return (Map<Object,Object>)componentMap;
}to no avail. Is such a kind of casting at all permitted?
If you would like to have the runnable code, please let me know.
Greetings
J�rg

Yes, how stupid of mine!
Nevertheless I cannot figure out how to make this method "generics compatible".
private Map getComponentMap(Map components, String key) {
// Get the Map for this particular component
    Object componentMap = components.get(componentName);
    if (componentMap == null)
    { componentMap = new TreeMap();
      components.put(componentName, componentMap);
    return (Map)componentMap;
}I declared each Map to be of type <Object,Object>.
private Map<Object,Object> getComponentMap(Map<Object,Object> components, String key) {
    Map<Object,Object> componentMap = (Map<Object,Object>)components.get
(componentName);
    if (componentMap == null)
    { componentMap = new TreeMap<Object,Object>();
      components.put(componentName, componentMap);
    return componentMap;
}But the compiler says:
"warning: [unchecked] unchecked cast
found : java.lang.Object
required: java.util.Map<java.lang.Object,java.lang.Object>
Map<Object,Object> componentMap = (Map<Object,Object>)components.get(componentName);"
Meaning when an Object is returned by a Map.get(...), then the compiler doesn't want it to be casted, isnt it?

Item names in a strictly typed ring control do not update.

I have a custom control (strict typedef) that contains one ring control. When I added item names to the strict type def, they do not get updated on the instances where I am using it.
S G
Certified LabVIEW Architect, Certified TestStand Developer, Certified Professional Instructor

Thanks for your response. However, I found the following sentence in the link LabVIEW custom controls ...
"A strict type definition forces almost everything about the control or indicator to be identical, including cosmetic properties such as size, color, and appearance. Strict type definitions also define other values, such as range checking on numeric controls and the item names in ring controls."
It turns out that the item names get updated if the ring control has sequential values associated with the items, but does not get updated if the values associated with the items are not sequential.
I chose text rings over enums
because I wanted the value associated with the items to be non-sequential for this particular control.
Once again, thanks for your response.
Regards,
Sudhir Gopinath
S G
Certified LabVIEW Architect, Certified TestStand Developer, Certified Professional Instructor

Cast generic VI to strictly typed VI

Similar Messages

Maybe you are looking for