Announcement

Collapse
No announcement yet.

objects and debugger

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

  • objects and debugger

    Sent to PowerBasic today:

    It would be nice if the debugger's variable watcher could show whether an object is valid or not - to be truly useful the "name" column syntax would have to allow subscripts and indirection (I mean like MyInterfaceArray(11) or @pInterfaceArray).

    Thanks,

  • #2
    sent to PowerBasic today:


    Further to my suggestion of 5th Feb 2009 - change in bold.

    It would be very useful if the debugger's variable watcher could show whether an object is valid or not, and also which interface of the object it represents. - to be truly useful the "name" column syntax would have to allow subscripts and indirection (I mean like MyInterfaceArray(11) or @pInterfaceArray).

    Thanks,

    Comment


    • #3
      ISOBJECT() is useful.

      And if you need to "watch" an object variable in a stepping debugger, IMO you need to rethink your object initialization/de-initialization strategy.

      Sounds to me a parallel to watching a PB ARRAY to see if it is currently dimensioned... if you need to "watch" that you need to rethink your REDIM/ERASE strategy.

      MCM
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        What IS missing (and for which I have sent in NFS), is an OBJECT counterpart to ERRCLEAR.... eg, something will will reset the OBJRESULT system variable to S_OK.

        Support told me to do that I just need to call a method which won't fail. Well, that's fine except if OBRESULT is not S_OK, I really don't want to call another method in that object so I need some kind of second object in the procedure so I can call a method there because OBJRESULT - like ERR - is one per procedure (or maybe it's global, I'm not sure)

        Usage: I want to test which OLEDB provider is available on the target system,,, MSDAORA or ORAOLEDB.Oracle... I know ONE of these is installed.

        If I try something with the ORAOLEDB.Oracle provider (OPEN method), OBRESULT is set to E_DISP_EXCEPTION on "provider not found", so now I want to try using Provider=MSDAORA to see if that works.

        Sure, you can code around it but I'd rather just "OBRESULTCLEAR" before trying again.



        MCM
        Last edited by Michael Mattias; 14 Feb 2009, 09:35 AM.
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          ISOBJECT() in use for something other than testing that your "NEWCOM" statement was correct..

          Code:
          ' ---------------------------------------
          ' CONNECT TO DATABASE
          ' szConnect (input)  = Connection string
          ' oconn (I-O)        =  if not an object when passed, instantiated and returned (open)
          ' sErrMSg            =  error text if unable to connect
          ' RETURNS            =  TRUE = connected to database, FALSE = not
          
          #IF %PB_EXE
             FUNCTION ADOConnectToDB ALIAS "ADOConnectToDb" (szConnect AS ASCIIZ, oConn AS INT__Connection, sErrMsg AS STRING) PRIVATE AS LONG
          #ELSE       ' compiling to DLL
             FUNCTION ADOConnectToDB ALIAS "ADOConnectToDb" (szConnect AS ASCIIZ, oConn AS INT__Connection, sErrMsg AS STRING) EXPORT AS LONG
          #ENDIF
          
            LOCAL vConn AS VARIANT       ' connection string so I can try multiple
            LOCAL sCOnnect AS STRING
            LOCAL vW   AS VARIANT  ' working var
          
            LOCAL vItem     AS VARIANT
          
            LOCAL sIdispInfoText AS STRING
          
            LOCAL vValue    AS VARIANT
            LOCAL sValue    AS STRING
          
            LOCAL iRet      AS LONG
            LOCAL s         AS STRING
            LOCAL w         AS STRING
            LOCAL fv        AS LONG   ' function value. %S_OK =0
            LOCAL sErrITem  AS STRING
            ' ---------------------------
            ' Begin code portion here
            ' ---------------------------
          
            ' ASsume we do not connect; set function false.
              fv = %FALSE
            ' create a connection object
            IF ISFALSE ISOBJECT (oConn) THEN
                  LET oConn  = NEWCOM $PROGID_ADODB_Connection   ' CC 5 syntax
            END IF
          
            IF ISOBJECT(oConn) THEN
               sConnect    = szCOnnect   'convert passed connection info to dynamic string
               vConn       = sConnect
               s           = ""
               OBJECT CALL   oConn.Open (vConn)   ' establish connection
          
               iRet        = OBJRESULT
               IF iRet <> %S_OK THEN               ' some kind of error
                    sErrITem =  "open method"
                    sErrMsg  =  ADOGetErrorTextOnConn (iRet, sErrITem, oConn)
                    fv =        %FALSE              ' can't connect
                    GOTO AdoConnectToDB_Exit
               ELSE    ' connection succeeded,
                   fv  =  %TRUE
                   sErrMsg = ""
          
               END IF  ' if the open (Connect) succeeded or not
          
            END IF     ' if we had a valid oconn object. either passed or created here
          
          ADOConnectToDB_Exit:
          ' Do NOT set oconn = nothing we return that object
          
            FUNCTION  = fv   ' connected status.
          
          
          END FUNCTION '  ADOConnectToDB
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Originally posted by Michael Mattias View Post
            ...IMO you need to rethink your object initialization/de-initialization strategy.
            No, I just want to debug my code without adding statements to it. However good my strategy is, my implementation of it can be wrong. Hence the need for debugging.

            Comment


            • #7
              >No, I just want to debug my code without adding statements to it.

              Figgers. Everyone wants to go to heaven but nobody wants to die.
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                Wait a minute.... you mean adding ISOBJECT() at the appropriate point is "too much" to do? This is worse than I thought. Not only do you want to go to heaven without dying to get there, you want a lifetime (eternity?) pass to come and go from there as you please.
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]talsystems.com
                http://www.talsystems.com

                Comment


                • #9
                  Originally posted by Michael Mattias View Post
                  Wait a minute.... you mean adding ISOBJECT() at the appropriate point is "too much" to do? This is worse than I thought. Not only do you want to go to heaven without dying to get there, you want a lifetime (eternity?) pass to come and go from there as you please.
                  I'd like to have that, too. Wouldn't you?

                  I use debuggers for a lot more than debugging. I find them useful to help me visualize the effects of my code. I often step through code that's working just fine to be sure I haven't overlooked a good idea and it's surprising how often something useful occurs to me while doing that.

                  That's not to say I can't change the code a little to help. Of course I can, but doing so is a distraction at that point and it's a little better if I don't have to.

                  Barry

                  Comment


                  • #10
                    Originally posted by Michael Mattias View Post
                    >No, I just want to debug my code without adding statements to it. ...nobody wants to die.
                    A bad habit I got into twenty years ago using outmoded products like Microsoft C, Codeview, Turbo Pascal, and state-of-the-art stuff like that. You Basic chaps were probably still using line numbers at the time (I know, don't tell me, COBOL).

                    Comment


                    • #11
                      bad habit I .............outmoded products like Microsoft C, Codeview, Turbo Pascal
                      Nice try.

                      However, this particular issue (Want to go heaven etc..) is development-product agnostic.

                      MCM
                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment

                      Working...
                      X