Debugger vs Real - Subscript Pointer out of range

[Cliff Nichols]

I am in a bit of a conundrum where actual results do not show correctly, and running in debugger with "Break On Error" set and

#DEBUG ERROR ON

I get Error 9: Subscript/Pointer out of range

The problem being that if I evaluate each variable they all show in the watch list, so I have to wonder, is it something prior that caused the problem? Is it something I need to replicate to demo? Is it something that I should look for that I can see the results, but I am still getting an error?

I know...its a convoluted idea, but I have no idea where to start looking for my mistake.

[Gösta H. Lovgren-2]

I am in a bit of a conundrum where actual results do not show correctly, and running in debugger with "Break On Error" set and I get Error 9: Subscript/Pointer out of range

The problem being that if I evaluate each variable they all show in the watch list, so I have to wonder, is it something prior that caused the problem? Is it something I need to replicate to demo? Is it something that I should look for that I can see the results, but I am still getting an error?

I know...its a convoluted idea, but I have no idea where to start looking for my mistake.

The Error msg should tell you where the last good place (label) was "Error after XXX" (if you have #Debug Display On at the top of your code). Stick some descriptive line number/labels ("xxx10:", "xxx20:", ... etc) in after that point. The Error msg will show a different "Error After ... " displaying the last "good" label. See thread here: http://www.powerbasic.com/support/pb...ghlight=labels

=============================
You never know a man
until you've worked with him.
You never know a woman
until you've lived with her.
Moses Wynn (1920 -)
=============================

[Michael Mattias]

>The problem being that if I evaluate each variable they all show in the watch list..

If one of those variables is the target of the invalid subscript/pointer, what shows in any watch list is perforce meaningless.

One thing to look for .... if you are passing BYVAL %NULL to a procedure which is looking for an ASCIIZ variable in that position - the 'conventional' way to indicate a null string - that can trigger an error 9, depending on compiler version.

I think you'd probably get the same thing where you pass anything by reference and it is missing or you deliberately passed BYVAL %NULL , e.g. , when you are checking in the called procedure for ISFALSE ISMISSING() or VARPTR(var) <> %NULL before using it.

MCM

[Gösta H. Lovgren-2]

Am curious Cliff. Does you ever find your problem? If so, how? Mayhaps it could be of benefit to others. (Lord knows I spend a more than my fair share of time chasing down errors.)

PS - Above I said
"...Stick some descriptive line number/labels ("xxx10:", "xxx20:", ... etc) in after that point. ..."

I should have said
"...Stick some descriptive line number/labels ("xxx10:", "xxx20:", ... etc) in BEFORE that point. "

My bad. Hope it didn't cause anyone to chase down blind alleys.

=============================================
"The more prohibitions there are,
the poorer the people will be.
The more laws are promulgated,
the more thieves and bandits there will be."
Lao-tzu, "The Tao Te Ching"
(China, 6th century BC).
=============================================

[Cliff Nichols]

It took me FOREVER to track this one down. (Although the answer was staring me right in the face)

My much larger program made it that much harder to find, but the slimmed down example shows an easily overlookable error when using "OPTIONAL" parameters.

#COMPILE EXE
#DIM ALL
#DEBUG ERROR ON
#TOOLS ON
#OPTIMIZE SIZE
#INCLUDE "Win32Api.inc"
FUNCTION PBMAIN () AS LONG
     LOCAL DeviceCommandsToParse AS STRING
     DIM DeviceCommands() AS STRING
     DIM DeviceParams() AS STRING
     DIM DeviceComments() AS STRING
     DIM DeviceBytes() AS LONG
     LOCAL ComputerSent AS LONG
     LOCAL CommandTyped AS LONG
     LOCAL AxisNumber AS LONG
     ParseDeviceCommands "Hello", DeviceCommands(), DeviceParams(), DeviceComments(), DeviceBytes(), ComputerSent, CommandTyped        'Dont pass AxisNumber and you will get a Null Pointer error
END FUNCTION

     FUNCTION ParseDeviceCommands ALIAS "ParseDeviceCommands"(DeviceCommandsToParse AS STRING, DeviceCommands() AS STRING, DeviceParams() AS STRING, DeviceComments() AS STRING, DeviceBytes() AS LONG, _
                                                             OPTIONAL ComputerSent AS LONG, OPTIONAL CommandTyped AS LONG, OPTIONAL AxisNumber AS LONG) EXPORT AS LONG
IF AxisNumber = 0 THEN MSGBOX "Hey you forgot the Axis Number"        '<--- Error 9 - SubScript / Pointer out of range
          SELECT CASE ISMISSING(AxisNumber)                           '<--- Proper way to avoid error
               CASE %FALSE
                    SELECT CASE AxisNumber
                         CASE 0                                 'No Motor Axis slipped in
                              MSGBOX "Device Reply" + $CR + "VarPtr = " + STR$(VARPTR(AxisNumber))
                         CASE 1                                'Slipped in X
                              MSGBOX "Motor 1 Position" + $CR + "VarPtr = " + STR$(VARPTR(AxisNumber))
                         CASE 2                                'Slipped in Y
                              MSGBOX "Motor 2 Position" + $CR + "VarPtr = " + STR$(VARPTR(AxisNumber))
                         CASE 3                                'Slipped in Z
                              MSGBOX "Motor 3 Position" + $CR + "VarPtr = " + STR$(VARPTR(AxisNumber))
                         CASE 4                                'Slipped in T
                              MSGBOX "Motor 4 Position" + $CR + "VarPtr = " + STR$(VARPTR(AxisNumber))
                    END SELECT
               CASE <> %FALSE
                    MSGBOX "AxisNumber Missing and I would have raised a Null Pointer error (If #DEBUG ERROR ON)" + $CR + "VarPtr = " + STR$(VARPTR(AxisNumber))
          END SELECT
          FUNCTION = %FALSE                            'No Error
     END FUNCTION

I would have thought an "IF" statement to be safe, however it does make sense that an "IF" operation on a null pointer would result in invalid results if you assign the variable a value and the variable itself is invalid

[Michael Mattias]

Hard way?

          SELECT CASE ISMISSING(AxisNumber)     ' proper way (????) 
               CASE %FALSE
                    SELECT CASE AxisNumber
                    .....
                 END SELECT
               CASE <> %FALSE
                    MSGBOX    " AxisNumber Missing..." 
          END SELECT

Easier to follow ??

  IF ISFALSE ISMISSING (AxisNumber) THEN 
      Select case AxisNumber
         CASE ....
         CASE....
       End select
   ELSE
       MSGBOX "Axis number missing" 
   END IF

????

MCM

[Michael Mattias]

Basically all you have to do is never refer to any variable which might be missing.

FWIW and I haven't tried it with the "dot-oh-two" compilers, TRACE had been throwing an error 9 on entry to a procedure when an optional BYREF parameter was not passed... apparently TRACE just assumes when printing the passed parameters that a null pointer is an error... which of course it isn't if the parameter is OPTIONAL.

Don't know how the stepping debugger or DEBUG DISPLAY ON handle this.

Just a little something to watch out for....