ganeshkumar1989 Posted November 8, 2011 Report Share Posted November 8, 2011 (edited) Hi, In one of my projects, I have to check if a control is a Sequence context control. This cannot be done using any properties like the 'Classname' of the control. Hence I am converting the control reference to variant and using 'Variant to Flattened String' to get the 'type String' array which describes the type. I see that the first two element of this array varies for each control and the remaining elements are the same for controls of the same ActiveX class type. Please tell me if this is the best way of doing it. I have attached the snippet for reference. Thank you. Ganesh Kumar Edited November 8, 2011 by ganeshkumar1989 Quote Link to comment
jcarmody Posted November 8, 2011 Report Share Posted November 8, 2011 This'll <edit>NOT</edit> work. EDIT: see lordsathish's post. 1 Quote Link to comment
lordsathish Posted November 9, 2011 Report Share Posted November 9, 2011 Jcarmody, If I'm not wrong the Name Indicator will return the Label of the wired data. I doesn't return the data type. This looks a problem of identifying the ActiveX server from the control. Quote Link to comment
Popular Post jcarmody Posted November 9, 2011 Popular Post Report Share Posted November 9, 2011 How about this? It may require more testing to eliminate things like String controls that contain the search text, but that's easy enough (depending on the application). 6 Quote Link to comment
Darren Posted November 9, 2011 Report Share Posted November 9, 2011 How about this? Very nice...I always use the VariantDataType VIs, and have never thought about using Flatten to XML to get more info out of a refnum than what those VIs provide. Your approach looks solid...find the <Name> tag under the <ActiveXType> tag and you should be good: <LvVariant> <Name>Variant</Name> <Refnum> <Name>ActiveX Container</Name> <RefKind>ActiveX</RefKind> <ActiveXType> <GUID>{9B4CD3E6-4981-101B-9CA8-9240CE2738AE}</GUID> <Name>Acrobat.CAcroApp</Name> </ActiveXType> <Val>0x00000000</Val> </Refnum> </LvVariant>[/CODE]It's not often these days that I get to add something new to my LabVIEW bag of tricks... 2 Quote Link to comment
ganeshkumar1989 Posted November 10, 2011 Author Report Share Posted November 10, 2011 (edited) How about this? It may require more testing to eliminate things like String controls that contain the search text, but that's easy enough (depending on the application). Jcarmody, This is exactly what I wanted and your snippet will exactly fit in to my application. Thank you very much. Edited November 10, 2011 by ganeshkumar1989 Quote Link to comment
jcarmody Posted November 10, 2011 Report Share Posted November 10, 2011 I read this KB article just last week because I'm playing with adapting a custom probe to any data type. Quote Link to comment
Rolf Kalbermatter Posted November 11, 2011 Report Share Posted November 11, 2011 How about this? It may require more testing to eliminate things like String controls that contain the search text, but that's easy enough (depending on the application). This is a smart implementation but I personally would feel a little concerned about creating a potentially large XML string to get such an information. The solution from the original poster had one big problem that it only really checked for the refnum to be ANY ActiveX refnum. It should have gone further to not only compare two elements from the typestring but in fact 23 (possibly even 27 but I'm not sure those additional 4 words provide any meaningful information). Basically the ActiveX specific typestring description contains a 0x3110, 0x0, 0x4, <16 bytes for the ActiveX Class GUID>, 0x0, 0x1, <16 bytes for the Interface GUID>, and then some other stuff (usually 0x0, 0x1, 0x0, 0x0). It's quite possible that the constant numbers could change with different ActiveX refnums, but my own testing seemed to indicate that they stay the same for several different ActiveX refnums, and quite likely are really the same for the same ActiveX type. To be really right the higher significant byte of the 2nd value of the full typestring should be masked out, as it contains LabVIEW private flags about the control the wire comes from. Quote Link to comment
mje Posted November 11, 2011 Report Share Posted November 11, 2011 Basically the ActiveX specific typestring description contains a 0x3110, 0x0, 0x4, <16 bytes for the ActiveX Class GUID>, 0x0, 0x1, <16 bytes for the Interface GUID>... I do like the idea of pulling the GUID from the typestring, and might work in this situation (or not...I honestly don't know what a SequenceContext is) but I expect it wouldn't work as a general solution. If you're looking for an interface that could be implemented in any number of refnum classes, you'd need to maintain a list of all possible GUIDs to compare against, which might not be possible. Versioning also worries me. Quote Link to comment
Rolf Kalbermatter Posted November 19, 2011 Report Share Posted November 19, 2011 I do like the idea of pulling the GUID from the typestring, and might work in this situation (or not...I honestly don't know what a SequenceContext is) but I expect it wouldn't work as a general solution. If you're looking for an interface that could be implemented in any number of refnum classes, you'd need to maintain a list of all possible GUIDs to compare against, which might not be possible. Versioning also worries me. Not really. If you compare the typestring of an ActiveX refnum with another typestring of a ActiveX refnum it only is equal if both UIDs are the same. The class GUID is basically the whole class and the interface GUID is the actual interface implementation. If only the class GUID is the same, then it is not the same refnum type, but a different one (with usually different properties and methods). Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.