Android Question Legacy debugger and Type elements

[SteveTerrell]

BA 3.82

When I hover over a "Type" variable the debugger shows the name of the variable (being hovered over) followed by =

The value(s) of the elements in the Type are not shown.

Do i need to do something else to see the values?

 

[SteveTerrell]

BA 3.82

When I hover over a "Type" variable the debugger shows the name of the variable (being hovered over) followed by =

The value(s) of the elements in the Type are not shown.

Do i need to do something else to see the values?

Additional info:

This failure only seems to happen on breakpoints in class code. A breakpoint in "normal" code shows the initialized state and element values.

 

[SteveTerrell]

Additional info:

This failure only seems to happen on breakpoints in class code. A breakpoint in "normal" code shows the initialized state and element values.

Sorry, that was incorrect.

In my code: a hover over a type variable after the first time a breakpoint is hit shows the Type state and element values as expected. After that when the same breakpoint (or i think any other breakpoint) is hit I just get the variable name and =, no state or element values are displayed.

 

[Erel]

Why are you using the legacy debugger instead of the rapid debugger?

Is it possible that there is a circular reference in the objects referenced from this type?

 

[SteveTerrell]

Why are you using the legacy debugger instead of the rapid debugger?

Is it possible that there is a circular reference in the objects referenced from this type?

I will answer Rapid question when I remember the reason

In the following sample magSquare, mainSquare and viewGridSelectedSquare are Type SquareCoords

Type SquareCoords (col As Int, row As Int)

Declared in a Class Module (not where the following Sub is declared.

With one and only breakpoint on the Return line in the following code I get, on the first hit,:

Hover over magSquare or mainSquare and the full debug info is shown
Hover over viewGridSelectedSquare and there is nothing after =

On the second and subsequent breakpoint hits there is nothing after = for any of them

Sub MagSquareIsOnMainGrid(magSquareIndex As Int) As Boolean
Dim magSquare As SquareCoords
    magSquare.col = relativeColIndexArray(magSquareIndex)
    magSquare.row = relativeRowIndexArray(magSquareIndex)
Dim mainSquare As SquareCoords = ConvertMagToMain(magSquare,viewGridSelectedSquare)
    Return storedGridDisplay.ColAndRowInRange(mainSquare)
End Sub

 

[Erel]

This error usually happens when there is a circular reference in one of the variable.

Try it with the rapid debugger (assuming that you are using v3.5+).

 

[SteveTerrell]

This error usually happens when there is a circular reference in one of the variable.

Try it with the rapid debugger (assuming that you are using v3.5+).

All information displayed correctly on Rapid debugger for all breakpoint hits (i.e. Initialized, col and row).

(The names) magSquare and mainSquare only exist as local variables in this Sub and are displayed correctly on the hover and local variables window in the legacy debugger only on the first hit.
SquareCoords is two ints.

Any thoughts on what should I be looking for in terms of a circular reference this case?

 

[Erel]

Is there any reason why you prefer to use the legacy debugger?

 

[SteveTerrell]

Is there any reason why you prefer to use the legacy debugger?

There is a slight advantage with the Legacy debugger in that the program will run both with and without the IDE (it just saves me a few minutes downloading a release version when showing the program to others).

The main reason was concerned with execution speed of the program while being debugged. There was a suggestion in the past (in other threads) that programs running under the legacy debugger executed faster than under the Rapid debugger. In my application there are occasions where values in a 60 by 60 array (actually a 3600 element list) must be processed to find the minimum and maximum value then a bitmap is drawn showing contrast expanded values based on that minimum and maximum. That sequence has to be done in less than 200mS in order to keep up with an external instrument which is generating new values and sending them via a SPP Bluetooth link. I cannot slow down the external instrument and must always be waiting for the next reading.

I appreciate that searching a list for maximum and minimum values to get a dynamic range is a bit crude and could be done more quickly but the main time is taken up by the need to rescale all the values and redraw a bitmap whenever the dynamic range changes.

I seem to remember that my quick tests when the Rapid debugger was released suggested that in this application it was slower than the legacy debugger.

 

[Erel]

The rapid debugger performance was dramatically improved in v3.50. It can still be slower in some cases however it is much more powerful and the deployment is very fast (1 - 2 seconds).

 

[SteveTerrell]

The rapid debugger performance was dramatically improved in v3.50. It can still be slower in some cases however it is much more powerful and the deployment is very fast (1 - 2 seconds).

Thanks, I will give it a go.