AnsweredAssumed Answered

vrf ActiveX, Variants and ByRef

Question asked by VRFuser on Sep 24, 2003

Like • Show 0 Likes0
Comment • 7

> Not sure when you find time to do your 'day job'

Ugh! Yesterday I got to sit in front of a computer for seven hours feeding
it CDs. It hasn't been very intellectually taxing lately.

> BTW, I tried the various asVariant(asInt16()) castings plus every other
> permutation I could think of to no avail.

Bummer. This can only mean VEE doesn't do SAFEARRAY. This has to go on the
list of things to check out.

> write a simple dll to convert the data from VEE into the required
> type for the OCX.

That works wonderfully. Check out SafeArrayCreateVector,
SafeArrayPutElement, SafeArrayDestroy and VariantInit, all in the Automation
SDK.
-SHAWN-

P.S. I knew a Mike Watts about 25 years ago. Does OHS mean anything to you?

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

No one else has this question

Outcomes

7 Replies

VRFuser Sep 22, 2003 8:08 PM
Mark Correct
Correct Answer
Hi,
I know there have been discussions on this forum before regarding
ActiveX and variants - maybe I missed the particular point but here is my
problem:

1. a manufacturer has provided an ActiveX [Control] interface to a data acq
card

2. some methods work very nicely

3. one particular method ( sending a digital output stream ) keeps
returning a type mismatch error - I have tried all sorts of types including
int16 ( which is what I would expect ) and forcing using asVariant()

4. the prototype that is provided by VEE's function & object browser is:

<objectname>.StartContDO(ByRef Buffer)

5. I contacted the manufacturer who did some investigation ( to their
credit ) and pointed out a part of the VEE documentation that says "variant
type of VEE only supports call by reference".

6. the manufacturer also provided the declaration for the method:

boolean StartContDO(VARIANT* Buffer)

which, to me, looks like a pointer i.e. a reference to the variable.

I suspect that I may be able to use some technique like the VB script
control as a wrapper ( I will try this anyway ).

Any bright ideas?

Regards to all,

Mike Watts

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Sep 22, 2003 9:47 PM
Mark Correct
Correct Answer
A few quick thoughts:

> 3. one particular method ( sending a digital output stream ) keeps
> returning a type mismatch error - I have tried all sorts of types
> including int16 ( which is what I would expect ) and forcing using
> asVariant()

The critical thing is exactly who is throwing a type mismatch. If it's VEE,
it's one thing. If it's the control, it's another.

There's a subtle ambiguity about using Variant in the context of an ActiveX
call (i.e., IDispatch call): everything is always passed as Variant,
regardless of what the type library looks like it's saying. When the actual
type being passed *is* variant (i.e., (var.vt && VT_TYPEMASK) && VT_VARIANT
== TRUE as it should be here) then both the client and the server must
realize that one level of resolution has been lost. IOW, if the value being
passed by an IDispatch interface is Variant, then that Variant must
ultimately specify what type it represents. It cannot represent Variant -
that's an abstract type that has no representation.

To further complicate the issue, there's ByRef. Variants are *always* passed
by reference anyway, much like strings. Adding ByRef implies that the
Variant passed through the IDispatch interface is a pointer to another
Variant (or array of Variants) who's vt member will presumably specify what
type the Variant is.

The manufacturer's declaration:

> boolean StartContDO(VARIANT* Buffer)

gives more hint for what it isn't than what it is. StartContDO - Start /
Continue Digital Output? Buffer? A buffer is usually a large chunk of
memory, but it doesn't have to be. "( sending a digital output stream )" -
this also seems to imply many values.

I'd say that this function expects an array of Variants of type int8, int16
or int32 that are to be clocked out by some previously set time base. Try
bSuccess = StartContDO(asVariant([value, value, etc...]); and see if that
gets you anywhere.
-SHAWN-

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Sep 22, 2003 10:46 PM
Mark Correct
Correct Answer
> bSuccess = StartContDO(asVariant([value, value, etc...]);

You know Mike, come to think of it VEE would probably build that into a
safearray. Try bSuccess = StartContDO([asVariant(value), asVariant(value),
etc...]);

(isn't this FUN??
-SHAWN-

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Sep 23, 2003 4:46 AM
Mark Correct
Correct Answer
Hi Shawn,
I had a feeling this may be in your territory! Many thanks for
taking the time to reply, unfortunately I think this may indicate one of
two things - either I have totally missed something or there is something
fundamental stopping me. It may be useful if I could see more than just a
"type mismatch at argument index 1" ( would have thought that, like
everything else in VEE, it should have been index 0, but maybe that's a
clue as to the source of the error message ).

I have tried your suggestions with no difference, also setting up a
VBScript to create an array and invoke the method ( this last idea was done
in two ways - 1. use a VB script to return a variant array and use the
array for a VEE call and 2. include the call within the script as
DOObj.StartContDO(Buffer) where Buffer was (a) passed in and (b) assigned
to a locally declared var ( always variant in VBScript ) - 1. gave same
error message, 2. just saying there was an error in the 'Run' method with
the "ActiveX object returned error message: Type Mismatch
'DOObj.StartContDO'" - note this message is slightly different from that
reported from the VEE call )

I have also tried setting up a global as either a variant ( and setting it
to an Int16 array ) or as a Variant array and then assigning the variant
array to the Int16 array, with no change of message. The error number I am
seeing is 552 which may be a small clue:
"552 <name> in the referenced ActiveX object failed" which would lead me
to think that (a) VEE made the call (b) the ActiveX control returned the
mismatch error and (c) VEE reported the error with the message from the
control... i.e. I would think that it was the control that is "throwing the
type mismatch" ( I'll try not to catch any other Java terminology ).

Any other suggestions, or even off-the-wall comments welcome.

Best Regards,

Mike Watts

P.S. it is nearly 1 a.m. here now - must ...stop....for... the ... night...

Previous messages:
A few quick thoughts:

> 3. one particular method ( sending a digital output stream ) keeps
> returning a type mismatch error - I have tried all sorts of types
> including int16 ( which is what I would expect ) and forcing using
> asVariant()

The critical thing is exactly who is throwing a type mismatch. If it's VEE,
it's one thing. If it's the control, it's another.

There's a subtle ambiguity about using Variant in the context of an ActiveX
call (i.e., IDispatch call): everything is always passed as Variant,
regardless of what the type library looks like it's saying. When the actual
type being passed *is* variant (i.e., (var.vt && VT_TYPEMASK) && VT_VARIANT
== TRUE as it should be here) then both the client and the server must
realize that one level of resolution has been lost. IOW, if the value being
passed by an IDispatch interface is Variant, then that Variant must
ultimately specify what type it represents. It cannot represent Variant -
that's an abstract type that has no representation.

To further complicate the issue, there's ByRef. Variants are *always*
passed
by reference anyway, much like strings. Adding ByRef implies that the
Variant passed through the IDispatch interface is a pointer to another
Variant (or array of Variants) who's vt member will presumably specify what
type the Variant is.

The manufacturer's declaration:

> boolean StartContDO(VARIANT* Buffer)

gives more hint for what it isn't than what it is. StartContDO - Start /
Continue Digital Output? Buffer? A buffer is usually a large chunk of
memory, but it doesn't have to be. "( sending a digital output stream )" -
this also seems to imply many values.

I'd say that this function expects an array of Variants of type int8, int16
or int32 that are to be clocked out by some previously set time base. Try
bSuccess = StartContDO(asVariant([value, value, etc...]); and see if that
gets you anywhere.
-SHAWN-

You know Mike, come to think of it VEE would probably build that into a
safearray. Try bSuccess = StartContDO([asVariant(value), asVariant(value),
etc...]);

(isn't this FUN??
-SHAWN-

Hi,
I know there have been discussions on this forum before regarding
ActiveX and variants - maybe I missed the particular point but here is my
problem:

1. a manufacturer has provided an ActiveX [Control] interface to a data acq
card

2. some methods work very nicely

3. one particular method ( sending a digital output stream ) keeps
returning a type mismatch error - I have tried all sorts of types including
int16 ( which is what I would expect ) and forcing using asVariant()

4. the prototype that is provided by VEE's function & object browser is:

<objectname>.StartContDO(ByRef Buffer)

5. I contacted the manufacturer who did some investigation ( to their
credit ) and pointed out a part of the VEE documentation that says "variant
type of VEE only supports call by reference".

6. the manufacturer also provided the declaration for the method:

boolean StartContDO(VARIANT* Buffer)

which, to me, looks like a pointer i.e. a reference to the variable.

I suspect that I may be able to use some technique like the VB script
control as a wrapper ( I will try this anyway ).

Any bright ideas?

Regards to all,

Mike Watts

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Sep 23, 2003 4:23 PM
Mark Correct
Correct Answer
> (a) VEE made the call (b) the ActiveX control returned the
> mismatch error and (c) VEE reported the error with the message
> from the control... i.e. I would think that it was the control
> that is "throwing the type mismatch" ( I'll try not to catch
> any other Java terminology ).

<G> Throw sounds better than "barf".

So the control is complaining. Super. At least you know you're doing
everything right. I thought so. If you can get your hands on a Visual Basic
example that uses the call it would be really helpful.

The most common source of this kind of problem is from the automatic
"marshaling code" that wraps the interface. VARIANT* Buffer is pretty vague.
It *should* mean exactly what VEE does: pass a long that's a pointer to a
Variant that describes the buffer. It *could* mean that the incoming pointer
points to a Variant who's type is VT_VARIANT | VT_BYREF though. In which
case *that* Variant is a pointer to another. Even if you looked at the IDL
you probably wouldn't be able to tell though.

Using Variants as interface parameters is strongly discouraged for this very
reason: it becomes ambiguous. It's possible to check out various scenarios,
but it's also time consuming. Hmmm... I see the dilemma. NuDAQ's VEE links
don't work. Ok, check usenet... gosh, for 800 bucks you'd think they'd do a
better job <G>.

Wow! Zip on usenet. ****. That's a first. Well, check the VRF. Maybe
somebody has run across this before. Oh my! I weighed in on this two years
ago. Hm, bummer. Ross Bledsoe had a problem with their driver - nothing to
do with StartContDO. Well, I'm downloading the NT software package now, so I
should know in a little bit (god I hate dialup). If VB can't figure it out,
I'll sick VCOM2 on it. VCOM2 is *very* literal when it comes to translating
type libraries. It will tell me in precise, confusing detail what is going
on with this function. Um, it may also crash, but oh well

Ah, we're looking for PCIS-OCX. Ok. Well, from what I saw of their other
software, they use the name Buffer for two things: as a buffer id and a
pointer to a buffer. In the C world, it's void *. In VB, it's ByRef As Any.
I can't wait to see the control - there's nothing like that for ActiveX. As
the ocx is a wrapper on the driver interface though, it's just barely
possible that they're looking for an actual pointer. I.e., a number that's a
pointer to a chunk of memory who's contents is up to interpretation. The
data format and count of data would have to be set somewhere else though.
That's kind of an outside chance though - that would make any language's job
a lot harder.

Anyway, I'll look at this stuff and see if I can figure it out.
-SHAWN-

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Sep 24, 2003 11:29 AM
Mark Correct
Correct Answer
> Anyway, I'll look at this stuff and see if I can figure it out.

Mike, there's good news and bad news. The good news is I figured it out. The
bad news is you might have to use their VarPacker.dll (in
ADLINKPCIS-OCXVarPacker). The clue is in the dox for the StartContDO
function (which I now know means start continuous digital output):

NOTE:
In VC++, Buffer is a VARIANT of VT_ARRAY | VT_I2, VT_ARRAY | VT_I4,
VT_ARRAY | VT_R4, VT_ARRAY | VT_R8, VT_ARRAY | VT_UI1

That VT_ARRAY means that the Variant is to contain a SAFEARRAY pointer
containing any of the listed types - short (Int16), long (Int32), float
(Real32), double (Real64) or unsigned char (what are they calling it?
UInt8?).

The VEE formula syntax asVariant([value, value]) *should* (I think) create a
variant of type VT_ARRAY | VT_I4. At least VEE 5 would if it had an
asVariant function. If the default type of integer in VEE 6 is int64, that
would be VT_I8 and that's a problem (a type mismatch by golly). In this case
the solution would be to allocate an array of your target type, fill it and
pass it via asVariant. Or generate data and use
asVariant(as<whatever>(data)) to pass the data array. Hopefully this simple
answer will suffice. If not...

VCOM2 (The Cheezy Type Browser) says the function is:

Function StartContDO(Buffer As VARIANT*) As BOOL

so I'm absolutely positive the ByRef in their documentation applies to
"wire" transmission (i.e. IDispatch) and NOT the VT_BYREF bit in the
Variant's vt member. This is basically a red herring. Any language would
pass Variant by reference. They should not have included ByRef in the dox.
Doing so in the idl would make VCOM2 come up with "Buffer As VARIANT**".

One of their VB samples looks like this:

[Declarations]
Dim buffer(0 To 10240) As Long
Dim vData As Variant

[Form_Load]
For i = 0 To 10240
buffer(i) = 512 + (Sin(i * 0.1) * 512)
Next i

[Command1_Click]
...
vData = buffer
res = Pci72001.StartContDO(vData)
...

Now, if emulating this sequence in VEE doesn't fix the problem, then your
next port of call is the VarPacker dll. This could prove quite the challenge
to use though - I'm not entirely sure it's possible without mucking around.
Some clever geek used C++ polymorphism to setup the function calls you need.
While this is really cool, it makes the dll practically useless to other
languages. I think about the only way you can get this done is write a C++
wrapper dll that calls their dll.

The do-it-yourself way seems out of the question: building a SAFEARRAY is no
problem, but I can't think of a way to diddle VEE's variant members. You'd
have to change the vt member and without something like varType(<variable>)
= VT_<whatever> or addrOf(<variable>) I don't see how it could be done.
-SHAWN-

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Sep 24, 2003 2:17 PM
Mark Correct
Correct Answer
Hi Shawn,
Not sure when you find time to do your 'day job' ( during the
night, perchance? ) but thanks again for all of your time and enthusiasm
investigating this.

I had missed the VarPacker dll things but there it is on the PC. I had a
quick look at this and, as you pointed out, it does not seem as though it
is going to work in VEE as ( especially the bit I need ) is encapsulated in
a class. However, this has given me the best idea so far - write a simple
dll to convert the data from VEE into the required type for the OCX. This
is certainly easier and neater than options such as writing my own ocx
wrapper or a wrapper-of-a-wrapper or ( insert any one of many other
possible solutions ).

BTW, I tried the various asVariant(asInt16()) castings plus every other
permutation I could think of to no avail.

I'll publish the dll for the vrf assuming I can make that work.

Cheers!

Mike Watts

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions

vrf ActiveX, Variants and ByRef

Outcomes

Related Content

Recommended Content