Type descriptor & Downcasting a refnum

Hi,
This question is a re-opining of this old thread, which ends by an non-answer ... (since the proposed solution is supposed to disapear one day)
http://forums.ni.com/t5/LabVIEW/LabVIEW-8-2-control-refnum-type-descriptor-missing/m-p/592060/highli...
So how do we actually downcast a generic refnum ( command in the following VI example ) to it's initial type ?
What I don't get is that typeDesc property node disapeared , but type descriptor still exists (and will obviously always be , see http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/type_descriptors/ )
So what ?
OpenG libraries use the type descriptor for lot of operations but for refnum, it seems to stop downcast to the generic "VI server" class.
(in case you wonder, I'm basically looking the same things the OpenG_Variant_Configuration_File library does, but instead of using cluster of data, I want to use cluster of references to data)
I suppose (and hope) there is a very simple replacement of the old deprecated property node, or solution to this problem, but I cannot find it.
Any help ?
Solved!
Go to Solution.
Attachments:
DeprecatedTypeDescriptorProperty.zip ‏21 KB

Ok, been looking for this during hours, but of course I found the obvious answer right after having asked.
Just need to "unpack" the inner type descriptor by using Value property node... Oo ...
Posting answer to my own problem just in case some else one day wonders the same.
Attachments:
TypeDescriptor by Refnum.zip ‏10 KB

Similar Messages

LabVIEW 8.2 control refnum type descriptor missing

In LabVIEW 7.1, the control refnum had a type descriptor property, I do not see it in LabVIEW 8.2.1? How do you get the type descriptor from a control refnum in LabVIEW 8.2.1?
Respectfully,
Robert

Matthew Kelton wrote:
The problem I have is that I have a generic control reference, so I don't know the type. That is why I was using the descriptor to determine the type to properly use variant to data on the Value Property. As it stands now, 8.5 still supports the Type Descriptor if it exists in VI I upgrade, but how long before it disappears? I use this in a generic VI that is used in every project I do, saving me hours per project.
The least NI could have done was just name is TypeDescr16 and TypeDescr32 or something.
TypeDescr32 is NOT exposed and on purpose too so there can't be such a property. And yes there is a chance that the old TypeDesc property disappears at some point. However it won't be tomorrow. The 4.x compatibility mode for the Typecast function (necessary for the boolean size change from 4.x to 5.x) is still there but for the Flatten/Unflatten it had to make place for the 7.x compatibility flag. And it might disappear with LabVIEW 9.x since as I have found out today, LabVIEW 8.5 is the first version that refuses to load 4.x VIs directly.
So the TypeDesc property will probably work until around LabVIEW 12.x when it will cease to support loading LabVIEW 7.x VIs. (Note, this prediction is just a very wild guess and should be taken with a big grain of salt).
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

List of Type Descriptor Values

Where can I find a list of the type descriptor values for controls? I am looking at the output of the Cluster Refnum Type Descriptor property. Using the debugger I have found that strings are 16, numerics are 22, but I have not been able to figure out arrays yet.
I am writing a VI that will write an entire cluster to a text file so it will be important to distinguish between 1D/2D arrays and data types stored in the array.
Thanks,
Dave
Message Edited by davey31415 on 10-25-2006 03:59 PM

Thanks for the replies, type descriptors it will be!
I read that post and Scott said the following:
A cluster's property node contains an item called "Controls []", which generates an array of refnums which can be used to access the cluster elements with the generic property node "Value" item. This refnum array can be indexed by the For loop for individual access. Be sure to forcefully limit the number of loops, because the size of the refnum array may not exactly match the actual number of items in the cluster (I think it grows in single byte increments, so it is typically a little bigger.)
Could someone clarify that? I have not been forcing the for-loop index. If the Controls[] array is not the same size as the number of controls in the cluster, what is it the size of? I don't see how the array being incremented in "single byte increments" would cause a problem- if the array WAS the size of the number of controls in the cluster, it would have been incremented in single byte increments as well, right? (Maybe I'm missing something big here?)
Having asked that, how could I determine the number of controls in a property? (My initial thought is to run Array Size on the Controls[] array!)
The other idea I've come up with is parsing the Type Descriptor property- not something I'm eager to set out to do with LV!
Thanks,
Dave

Specifying byte stream type for Read File with Type Descriptor

Hi.
I'm trying to write a VI that reads an image file format that can have
different datatypes. What I have so far is that I open the file, read
the header, and get the width, height, number of frames, and datatype.
I calculate number of pixels by nrows*ncols*nframes with no problem,
but I'm not sure how to tell Read File the correct datatype to read
the data into.
I tried using a Case structure where I have a Read File in each case
with the correct type constant as input for that case. The problem is
that the tunnel graduates the datatype to the highest representation.
I found in Application Note 154 the discussion about Type Descriptors.
Is there a way to generate a Type Descriptor and output it from a C
ase
structure? I tried just returning the value (e.g. 0x0402 for a Word),
but Read File will just see that the byte stream type is a uint32.
Is there any other way to do this?
Thanks for any help.

I converted the code to LabVIEW 6.1 for you and attached it below.
Don't worry about being a newbie. We all start there. Keep asking this type of question and you won't stay there long.
As you are discovering, being strictly typed means that you must rewrite code even for a simple data type change, or convert everything to the same data type first. For image data, conversion can result in a lot of extra space being wasted. Use a modified version of the GLV_WaveformBuffer.vi to hold your data. Use the array functions, which operate inline, to add to and delete the data wires in the buffer. This allows you to save several different data types. You will need several different inputs and outputs to handle these data types. I ha
ve also attached a similar file created for exactly the problem you have - storing arrays of different data types (data from NI-SCOPE devices, in this case - can be float, I8, I16, or I32).
Routines that take any type work in one of two ways. LabVIEW primitives, such as plus and minus operators, work by figuring out the type and doing the right thing in the C code layer of the LabVIEW environment. Users of LabVIEW can't do this. Users can make polymorphic VIs. Polymorphic VIs are actually a single VI for every data type that are referenced by a "wrapper", the polymorphic VI. Users still need to write a different VI for every data type they need.
Take home message - if you need to work with different data types, you will need to rewrite your code for every data type or convert your data to a common data type. Polymorphic VIs and case statements are your friend.
Let me know if you need more help.
This account is no longer active. Contact ShadesOfGray for current posts and information.
Attachments:
GigaLabVIEW61.zip ‏362 KB
sfpScpChan_Waveform_Buffer.zip ‏74 KB

Error when accessing low level objects and converting variant to refnum Type

Hope someone can give a clue....
I'm using a dll, but it only has one creatable object, and I need to call two non-creatable objects.
When the method to return the new reference is called, an error occured ("Member not found.
in My.vi").
The weird thing is that when I wired the new reference, I'm able to see the new methods and properties expected of the new object.
Should I ignore this error???
Also, does anyone know, How can I convert a variant to a ActiveX refnum??? because, when I use the To G type Lib, if a refnum type is wired, it's like this type is not supported, but the list states otherwise.
Thank you in advance for any clue you can give me!!!

Since I do not know what type of ActiveX object you are calling, I do not know about the error you are seeing. However, since everything seems to be working after that, I would assume it's okay. Now, you can convert a variant to an ActiveX refnum, but how you do this depends upon what type of refnum you need. Use the Variant to Data.vi to convert your variant type to a refnum by wiring in an ActiveX refnum to the "type" input. You will first need to determine what type of ActiveX refnum it is (Automation, Control, etc) and then wire that wire type into this VI.
J.R. Allen

How can I calling LabView DLL within LabView and pass similar Data Types?

I am trying to use an Instrument Driver, which is created in LabView6.1 as a DLL. At this point I have only LabView to test this DLL. I was wondering, is there easy way to find out what sort of Parameter or Data Type I should be using.
How can I pass the following data with in LabView:
LVRefnum as Type?
LVBoolean as Type?
TD1 (a structure) as Type?
It is funny to see that I am able to create a DLL in labview but having trouble calling it within LabView. I thought, it would be easier to test the DLL within the same environment.
Basically, I am more worried about the VISA calls that are used in the driver to communicate with instrument. Because, there is no link to �VISA32.dll� in
the header file, is that handled by the LV Run-time engine? I guess more details are needed on using the LabView DLL within LabView from National Instrument Technical Support.
Attachments:
RL5000.h ‏1 KB

A LVRefNum seems to be an unsigned long data type (32bit). You can cast it
in LV then use that as a parameter to call the DLL. (an Occurrence type
seems to be a Ulong32)
When you created the DLL what was the resulting type for the LVRefNum?
Happy Holidays
"Enrique" wrote in message
news:[email protected]..
> I see...
>
> After doing some research, it seems to me that there is no easy way to
> find out the type of data, other than looking at the header file and
> have documents like Using External Code in LabVIEW handy. The
> following information is from that document:
>
> LVBoolean is an 8-bit integer. 1 if TRUE, 0 if FALSE.
>
> LabVIEW specifies file refnums using t
he LVRefNum data type, the
> exact structure of which is private to the file manager. To pass
> references to open files into or out of a CIN, convert file refnums to
> file descriptors, and convert file descriptors to file refnums using
> the functions described in Chapter 6, Function Descriptions.
>
> I know you are creating a dll in LabVIEW, but I am pretty sure the
> information applies as well and is useful. For your dll this can be
> interpreted that, rather than passing a LVRefnum, try passing the file
> descriptor.
>
> From the header file, is can be deduced that TD1 is a cluster in
> LabVIEW.
>
> You are right in saying that "more details are needed on using the
> LabView DLL within LabView from National Instrument Technical
> Support.".
>
> Enrique

How to pass a general datalog type to a subvi

I am writing a general subvi to determine if a file of a given name and optionally datalog type exists in a directory specified by the user. To match the datalog type I must be able to pass it into my subvi. To keep this question in a simple context, imagine putting the standard file/directory LIST vi inside a subvi. Now I want to pass the datalog type into this subvi so that this bit of code is generally useful. Is there a (preferrably easy) way?
I tried a variant control and it does not work - but does not generate an error either. It simply doesn't return any files. I also tried passing a cluster control refnum, but this failed for the same reason; when I wire the Value Property node it supplies a variant . . .
I am guessing that this job cannot be done with file/directory LIST since it checks the type of data wired to Datalog Type at program time. So if I take on the task of passing a type descriptor for a cluster/datalog type, how can I match this to the header of a datalog file? I see that most of the information matches, but not all . . .
Thanks,
Art Mihill
McPherson, Inc.

Hello,
Well, you may be able to do this, but it may be easier to have a naming convention for your files, where you can determine immediately the datalog type from the file name. One way you may attempt this is to read the file and use it's size, perhaps (mod) something (ie. look at the remainder after dividing by some integer) to determine the underlying datatypes. You may also be able to parse the file and look for clues; in that case you may want to reference the following tutorial:
LabVIEW Data Storage:
http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/370dfc6fd19b318c86256a33006...
If this isn't sufficient or not a viable solution, repost and we'll try to get a bit more creative!
Best Regards,
JLS
Best,
JLS
Sixclear

What is the impact of using a variant data type on performance, speed memory demands etc?

This is another one of my "lets get this settled once and for all" threads.
I have avoided variant data types whenever possible to keep the performance of my apps up. From some observatsions i have made over the years, I am of the opinion that;
1) In-place operations can not be carried out on variants.
2) Passing a variant to a sub-VI (regardless of the terminal on the icon connector) are always copied.
I would like confirmation or correction of the above so we know more about this animal we call LabVIEW.
Thank you,
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction
Solved!
Go to Solution.

A couple notes:
1. You can use the To/From Variant nodes for the Inplace Element Structure to operate inplace on the contained variant data. This should work just fine even if you have a big 2D array contained.
2. Variants are incredibly useful when you use them for Variant Attributes, rather than just storing data. The Variant Attribute implementation uses a binary tree to store the key value pairs, which provides quick insertion and lookup.
3. I don't work on the internals of LV, but I see no reason whatsoever that passing a variant into a subVI would always necessitate a copy. I could be wrong, but that sounds very odd to me.
However, I have generally started trending towards using flattened strings. Flattened strings are generally more efficient memory-wise, because they don't contain all the type descriptor information, just the raw data. (I think there's some exception when flattening LV Classes.) Variants always store the type descriptor, so even an empty variant can take up a bit of memory.
Variants received a big performance boost from 7.x to 8.x. They used to have a bad reputation, but I wouldn't be afraid to use them where applicable. I personally don't see a lot of benefits over flattened strings, though, except in the case of tools like the OpenG Variant INI files, which can dynamically parse out and construct variant types.
Jarrod S.
National Instruments

How to find the type of a variant...

I'm trying to programatically read the "VersionInfoFileVersionBuild" tag's value associated with a Build Specification. This is the fourth number in the overall version number. i.e if the version number is "1.4.3.7", the VersionInfoFileVersionBuild is 7.
I tried using the "Get Tag" method, with this tag, but the value is returned as a variant. I've tried converting this variant to data and I keep getting the following error: "LabVIEW: The data type of the variant is not compatible with the data type wired to the type input."
I've tried every numeric type and even strings and the same error keeps coming up. Can someone tell me what IS the type of the value associated with the "VersionInfoFileVersionBuild", or how do I find it?

Hey intvsteve,
Thanks for trying to help. I had already tried using I32 as the type input for the "Variant to Data.vi" and it had not worked. I have even tried flattening the variant to a string and scanning the string. None of it has worked. For whatever reason, I'm getting a '4' back for the first element in my "Type String" array which indicates the type is a 64-bit integer. But that's not working for me either. I wonder if the problem has to do with this note in the Help for the Type Descriptors:
"Note The format in which LabVIEW stores type descriptors changed in LabVIEW 8.0. LabVIEW 7.x stores type descriptors in 16-bit flat representation. LabVIEW 8.0 stores type descriptors in 32-bit flat representation. The following information applies if you use the Convert 7.x Data mode of the Flatten to String function.Note The format in which LabVIEW stores type descriptors changed in LabVIEW 8.0. LabVIEW 7.x stores type descriptors in 16-bit flat representation. LabVIEW 8.0 stores type descriptors in 32-bit flat representation. The following information applies if you use the Convert 7.x Data mode of the Flatten to String function."
I'm using LabVIEW 8.0. Any other thoughts?

How to set user defined type in binded parameter to NULL

Hello
I have a type in PL/SQL MY_ARRAY which is a array of VARCHAR2
and I want to call a procedure MY_PROC in OCCI, the procedure takes MY_ARRAY as its IN parameter, but I want to set the parameter to null. How can I do that?
"begin MY_PROC(:1); end;"
I tried setNull(1,OCCIVECTOR), but failed. and If i use MY_PROC(null), the compiler just tells me that SELF NULL parameter not allowed or sth like this.
any one can help me?

Have you found a solution ? I have pretty much the same issue with passing a NULL SDO_GEOMETRY to a stored procedure and I did this with a call to setNull( paramIndex, oracle::occi::OCCIPOBJECT ) on the statement object, but it also fails with the followins error: "ORA-24360: Type Descriptor Object not specified for Object Bind/Define"

How to set user defined type ( SDO_GEOMETRY ) in binded parameter to NULL

I am trying to send a null sdo_geometry object as parameter to a stored procedure by a call to setNull( paramIndex, oracle::occi::OCCIPOBJECT ) on the statement object, but I am getting the following error: "ORA-24360: Type Descriptor Object not specified for Object Bind/Define".
Does anybody succeded to send a NULL user defined object to a stored procedure ?
Many thanks,
Andrei

This is a problem fixed in 10.2. As a workaround you can try :-
sdo_geometry *obj = new sdo_geometry();
obj->setNull();
stmt->setObject(col,obj);
Thanks,
Shankar

Using RTTI in table type any

Hello,
i have table type any and i want to know in the loop for every field which type he have ,for instance for field type Date8.
what i the best way to do so , i guess that I need to use for instance cl_abap_elemdescr=>get_data_type_kind( <lv_field> ) but i dont know
how to use it and check every field in the loop ...
E.g.
loop at <lt_fields> assigning <ls_fields>
* check for every field in <ls_fields> which type he have and if the field is type date8
* handle it diffrently
endloop.
Regards
Joy

You can use Absolute Name to get the absolute type from the type descriptor.
DATA: lt_vbak TYPE STANDARD TABLE OF vbak.
DATA: lo_struct   TYPE REF TO cl_abap_structdescr,
      lt_comp     TYPE cl_abap_structdescr=>component_table,
      la_comp     LIKE LINE OF lt_comp.
lo_struct ?= cl_abap_typedescr=>describe_by_name( 'VBAK' ).
lt_comp = lo_struct->get_components( ).
WRITE: /(30) 'Field' , (40) 'Absolute Type'.
DATA: lv_abs_name TYPE string.
LOOP AT lt_comp INTO la_comp.
WRITE: /(30) la_comp-name, (40) la_comp-type->absolute_name.
ENDLOOP.
Regards,
Naimesh Patel

Identify the TYPE using CL_ABAP_DATADESCR

we have a custom field ROLE with the Data element as ZDOA_ROLE in a table ZTABLE.
CODE SAMPLE 1
data gs_comp TYPE abap_componentdescr.
gs_comp-type ?= cl_abap_datadescr=>describe_by_data( 'ROLE' ).
gs_comp-name = gs_comp-type->get_relative_name( ).
when i write the above code, the name is blank.
CODE SAMPLE 2
do_type = cl_abap_datadescr=>describe_by_name( 'ROLE' ).
it dumps, stating ROLE type is not available
CODE SAMPLE 3
do_type = cl_abap_datadescr=>describe_by_name( 'ZDOA_ROLE' ).
it returns the type is ZDOA_ROLE.
"--NOT USEFUL because i cannot pass the Data element, I can only pass Field name
Priority is to find the type from the Field.
Can any body suggest me, a better way to get the Type of the Field and not by the Data element ?

abhishek nms wrote:
Any work around ? because i cannot mention the table name,
abhishek nms wrote:
Requirement: based on the tab delimited file upload in Web Dynpro, I need to identify which table data (mostly our Custom ZDOA tables which are around 10) was uploaded and updated the corresponding table .
These two statements seem contradictory. If you know that the file must be one of your ZDOA tables, than you can get the table name(s) by finding all tables that match the pattern ZDOA*
Once you know the possible tables, you can determine the structure of each table like this:
lo_structdescr ?= cl_abap_structdescr=>describe_by_name( 'ZDOA_TABLE' ).
li_components = lo_structdescr->get_components( ).
li_components is a table of the names and type descriptors for each field in the structure. You can loop through this table, comparing the names of each field to the field names given in the header of the tab-delimited file.

Get type

Hi all !
I need some help...
My problem is the following: I need to write a function in order to know the type (data representation, e.g: double, I64, I32, boolean....) of all controls/ Indicators present on my Front Panel. I didn't found any function that return me the such an information. After many search i decided to use the property ClassID, from that i deduce the type e.g: If i get a ClassId = 8 , it'as a boolean....
I don't think this solution is really clean and i wonder if someone has a better idea ....
Thank's in advance.... !

Hello,
If you're using LabVIEW 7.0 or later, you can wire any control reference into this VI:
vi.lib\Utility\GetType.llb\Get Type of Control.vi
And it will return an enum describing the datatype. This should suit your purposes. If you're using an older version of LabVIEW, you may be able to find some other type descriptor parsing VIs out there somewhere, perhaps on these forums somewhere.
Good luck,
-D
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Create a default path into Automation Refnum

I'm currently writing an app which should display a nice graph (chart) on
its front panel. I choose to use Mapinfo Active X.
To do this, I've placed an Automation Refnum on my front panel, and in the window
'select object form Type Library', I choose "Mapinfo.tlb" .
It works quite well, but :
When I re-open this Vi, I should re-setting the Automation refnum. I try to use Active X container, it doesn't work. Can I create a default path into the Automation Refnum or any other method which can solve this problem.
Thanks for your help.

You shouldn't select the type lybrary, in automation refnum, when you want to select te type, available types appear if properly registered in your system, if not, you should register your tlb.
Hope this helps

Type descriptor & Downcasting a refnum

Similar Messages

Maybe you are looking for