Com using unicode?

[Edwin Knoppert]

I wonder.. shouldn't i do com using unicode only?
I believe there are a few ansi based activex's but i think all new stuff is in unicode.

Classes as they are now are supurb but maybe we are forgetting something important, reusability..?

Am i wrong?

[José Roca]

You must use Unicode if your methods are going to be called through Invoke (OBJECT CALL/GET/SET/LET) or if you write a server to be used with languages such VB. It is not required if you use direct interface calls. DirectX, for example, uses ASCIIZ strings.

[Michael Mattias]

Related problem I ran into this week...

With ADO Connection object, the Execute method has three parameters, the first being "rows affected" (by an INSERT, UPDATE or DELETE SQL statement).

After several failing attempts, I finally got the row count back by trying...

  LOCAL vnRow AS VARIANT 

  vnRow = BYREF  nRow      ' nRow is a param passed to the procedure
  OBJECT CALL oconn.Execute (vnRow, ...)

..that is, using the EXPLICIT "BYREF" on the assignment.

I contacted PB Support about this, thinking that for sure the requirement for "BYREF" must be in the info gleaned from the typelib by the COM browser when creating the INTERFACE definition... but have learned that apparently this info is NOT in the typelib.

(There is also the obvious limitation that the compiler does not know at the time of the assignment I am going to use "vnRow" as a parameter to a method call, but let's set that aside).

So, support told me what they could: I'd have to refer to the documentation for the method to know to use BYREF on the assignment statement.

The kicker? Neither the MS-documentation nor the O'Reilly book on ADO I purchased tell you to pass the ADDRESS of the variable to be updated in the variant parameter.

Maybe that is 'obvious' but I did not see why the method would not just fill that variant param with the row count as a LONG (VT_I4).

So I guess that "BYREF/BYVAL" is kind of like "Unicode/ANSI" .... you can't assume anything and will likely end up doing a little trial-and-error programming.

MCM

[José Roca]

The documentation says:

RecordsAffected

Optional. A Long variable to which the provider returns the number of records that the operation affected.

Therefore, there is no way the method can return a value unless you provide the address of a long variable. Of course, M$ programmers could have used BYREF LONG instead of BYREF VARIANT for the parameter, but then where will be the fun?

[José Roca]

Oh, forgot that you are using OBJECT CALL. Using automation, you still will have to use a VT_BYREF variant if they had chosen BYREF LONG because parameters are passed to Invoke using an array of variants. Using direct interface calls you will simply pass a LONG variable.

[Michael Mattias]

That's the same doc I have. But I just did a...

  LET vnROW = nRow

.. and thought the VARIANT might just be returned with appropriate changes.

Then I tried...

  LET vnRow = EMPTY

.. just "knowing " that the method call would "do the right thing."

Then, I tried assigning a dummy value to the passed parameter... and lo and behold, I got the same value back, with no error on the execute method.

Granted, I am new to VARIANT data types, but at the time it really did not seem all that unreasonable.

As long as I brought it up...

I played around with doing this thru the Command Object, which uses this syntax:

  OBJECT CALL oCmd.Execute  (vNrow, vparam, vOptions)

.. in which all params are optional. What is the correct way to call with "this param is not being supplied because it's optional?"

I did not need a param, so I tried
vParam = %EMPTY

That got me a "parameter object malformed" error on the execute

Seems to me I read here somewhere there was some assignment you could make to a variant meaning "not here, missing, not supplied" but darned if I could find it either in the PB help file or in my SDK documentation for variants

One thing I just thought of but have not tried....

   OBJECT CALL oCmd.Execute (vNrec,,vOption)

.. and maybe I should try that before posting this question, but I'm already in this deep so what the heck.

Or maybe I should just mop up this application version 1.0 sticking with the Connection Object , and then rewrite the DB access using the direct interface instead of the dispatch interface. I'm pretty sure I want to do that anyway at some point.

(I have to use connection for the next part of app, because I have to use BeginTransaction/Endtransaction (with rollback or commit) and the command object does not have transaction control methods).



MCM

[José Roca]

I did not need a param, so I tried
vParam = %EMPTY

That got me a "parameter object malformed" error on the execute

Seems to me I read here somewhere there was some assignment you could make to a variant meaning "not here, missing, not supplied" but darned if I could find it either in the PB help file or in my SDK documentation for variants

You have to use

vParam = ERROR %DISP_E_PARAMNOTFOUND

That is an special value used by COM to identify omitted optional parameters.

[Michael Mattias]

You have to use

vParam = ERROR %DISP_E_PARAMNOTFOUND

Thank you, that works well.

When I first saw this syntax in your post I was befuddled and was sure you had made a typing error. But NOW I see it in the help file bigger than life. Duh.

MCM

[José Roca]

What it does is to create a VT_ERROR variant holding the value &H80020004&.

"If an optional argument to an Automation method is left blank, do not pass a VARIANT of type VT_EMPTY. Instead, pass a VARIANT of type VT_ERROR with a value of DISP_E_PARAMNOTFOUND."

See: http://msdn.microsoft.com/en-us/library/ms221627.aspx

[Michael Mattias]

I actually cheated and solved my current challenge simply using the Execute method of of the Connection object. I was just kind of playing around with the Command object, as it was shown extensively in the O'Reilly book on ADO I purchased and the author seemed to think the Command object was the greatest thing since sliced bread.

Bit I really don't see any advantage in using the Command object over the Connection object for either DDL or DML SQL statements.

For this particular application I don't expect to be requiring any parameters for anything, since I will typically be dealing with max twenty 'INSERT' or 'UPDATE' statements at any one time, and I can just build a complete SQL statement for use with 'immediate' execution.

However, for my 'next up' ADO-based application I am going to need to learn how to use parameters efficiently, since I will be doing tens or even hundreds of thousands of INSERTs at a crack.

I'm walking before I run.

MCM