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

Similar Messages

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

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

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

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.

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

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

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

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.

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

Determine if a control reference is a strict type definition

If a VI is passed a control reference it can determine the VI Server Class using the ClassName property but how can it determine if the control reference is from a control which is based on a strict type definition?

That a pretty neat little VI you've found, Darren. Kudos!
The solution that Darren presents, however, will not tell the difference between a typedef and a strict typedef (unless I'm missing something). If you have VI Scripting enabled (see attachment for where to enable this in the Options menu), you can expose the Is Typedef? property.
This returns an enum with the following values (as pictured)
not a typedef
typedef
strict typedef
class private data
Although this property is not settable in a VI at run-time, it should be readable.
Below is a picture of the Options menu where you can enable VI scripting
Mitch
Attachments:
VIScripting.PNG ‏33 KB

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

Cluster of control references: want to access the control value

I want to be able to save and set control values that are saved (XML). I have my controls on about 5 sub vi's. So I thought it'd be a good idea
to put all the control references in a cluster from the several sub vi's and save and read from one point.
I can get the cluster values (i.e. the references to the controls), but how to proceed from here? If somebody has a better idea it is very welcome.
I have also read Ben's nugget here, but it deals with references to controls in a cluster, not references to a reference of a control in a cluster

Thank you for reading that Nugget!
I use a GUI Controller in many apps so I can grab refs in sub-VI's.
Here are some screen shots of them in use.
The first "GUI Cnt" is a wrapper around the AE and invokes the action "Set Analysis mode" then another call let me get a cluster of the refs so I can choose based on the name.
This image shows what that action does.
THis is what happens when going into collection mode.
That is a small set of what you will find in my image gallery Feel free to browse (yes I know there is a lot of Olivia in there ) and ask if anything catches your interest.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Obtaining a reference to CURSOR LEGEND (Tree Control) of a graph (for purposes of compressing it)

The Captain (Norm Kirchner) told me awhile back how to obtain a reference to the Cursor Legend of a Graph so as to be able to compress it (the cursor legend is a tree control that unexplainably likes to expand at times). Norm, if you are still there or if someone else knows, please provide instructions for all to see. Much obliged as I have searched everywhere in my email and notes and cannot find the correspondence.
Thanks,
Don

If it is indeed impossible to create a reference to the cursor legend tree, then how was I able to do what I did in the attached VI?
(Expand one or both of the cursor trees in the legend and then run the VI.) See the block diagram.
Note that I don't remember how I did it either (which is why I posted this originally). I had notes on this in an email exchange with Norm Kirchner but I think during our change of email clients, it got deleted.
Don
Attachments:
cursor_tree_legend_reference.vi ‏14 KB

Reference an FPGA Array of Controls

I am developing a cRIO application that has an array of 23 controls in the FPGA. The FPGA Interface C API Generator defined them as a name and size.
typedef enum
NiFpga_ControlArrayU32_Setpoints = 0x8118,
} NiFpga_ControlArrayU32;
typedef enum
NiFpga_ControlArrayU32Size_Setpoints = 24,
} NiFpga_ControlArrayU32Size;
How would I reference the 15th setpoint, as NiFpga_ControlArrayU32[15] or as an offest to 0x8118?
Solved!
Go to Solution.

Hi Paul_Knight,
When the C headers are generated, there should be one called NiFPGA.h.
There is a function within this header for reading a U32 array. The function is called NiFpga_ReadArrayU32. Here is some documentation on the various read array functions.
http://zone.ni.com/reference/en-XX/help/372928G-01/capi/functions_readarray/
You should be able to read the array values and store them into an array in C. Then you can access them as you would normally within your C program. Hope this helps!
Robert B
Applications Engineer
National Instruments

Reference behaviour of strictly typed controls

Similar Messages

Maybe you are looking for