objects and debugger

[Michael Mattias]

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

[Chris Holbrook]

>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).

[Barry Marks]

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

[Michael Mattias]

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]

>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.

[Chris Holbrook]

...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.

[Michael Mattias]

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

' ---------------------------------------
' 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]

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

[Michael Mattias]

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

[Chris Holbrook]

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,

[Chris Holbrook]

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,