Announcement

Collapse
No announcement yet.

Com using unicode?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Com using unicode?

    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?
    hellobasic

  • #2
    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.
    Forum: http://www.jose.it-berater.org/smfforum/index.php

    Comment


    • #3
      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...
      Code:
        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
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        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?
        Last edited by José Roca; 25 Jan 2009, 10:41 AM.
        Forum: http://www.jose.it-berater.org/smfforum/index.php

        Comment


        • #5
          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.
          Forum: http://www.jose.it-berater.org/smfforum/index.php

          Comment


          • #6
            That's the same doc I have. But I just did a...
            Code:
              LET vnROW = nRow
            .. and thought the VARIANT might just be returned with appropriate changes.

            Then I tried...
            Code:
              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:

            Code:
              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....
            Code:
               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
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              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

              Code:
              vParam = ERROR %DISP_E_PARAMNOTFOUND
              That is an special value used by COM to identify omitted optional parameters.
              Forum: http://www.jose.it-berater.org/smfforum/index.php

              Comment


              • #8
                You have to use
                Code:
                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
                Last edited by Michael Mattias; 27 Jan 2009, 08:24 AM.
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  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
                  Forum: http://www.jose.it-berater.org/smfforum/index.php

                  Comment


                  • #10
                    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
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment

                    Working...
                    X