Revision as of 19:05, 25 December 2006

Compiler Related Recommendations

In-game Bug Detecting

It is possible to directly debug at least some of the random glitches that are found in the DB universe from within the game itself. This thanks largly to a useful(if dated) console, which supplies information about the various memlocs. Although they can't be directly fixed from within the game, valuable information and clues to a bug's exact cause can be obtained.

How about some of you 'seasoned' VB users giving the rest of us a few tips

on VB and Debugging so we might be able to help out tracking down errors?

Anyone signed in here at the Wiki can edit and add to these pages.

Just click on edit and have at it.

Not to worry about correct/ideal formatting ...

we'll figure it out.

Griz^talk 15:04, 24 Dec 2006 (MST)

Basic Debugging from VB

error.sim

From Eric:
There are two lines where the comment portion of the source code line indicates that line should be commented out when running under the debugger. Just put a single apostrophe at the beginning of the line. This way, the source code won't try to handle the exception (an 'exception' is just a fancy name for a crash, a divide by 0 or something like that) and VB will get the error. When an exception does happen, you should get a pop-up dialog that offers to let you debug the problem. When you hit the debug button, it should highlight the source code line where the exception is occurring.

This is the only one I know of that has to be commented in/out: In MDIForm1 (code), Private Sub simload

 
Private Sub simload(Optional path As String)
  Dim I As Integer
  Dim path2 As String
  
On Error GoTo fine ' Uncomment this line in the compiled version error.sim

Comment this On Error out when using VB and Debugger ...
or it will abort and go save the error.sim.
Then remember to uncomment it once you have located and fixed an
error and want to recompile or the recompiled prog won't do it's
save error.sim Also ... once the debugger has sent you to the break ...
'hovering' the mouse over variables in the code will
give you their value at that time and place in the execution.
this is helpful in finding overflows or variables out of range.
using this, even I have been able to locate errors on occasion.

Switching between Compiled and VB for Debugging

for those running/searching for those errors in long sims ...

if you run the compiled version and do an occasional save ...

[this can be automatically done, yes?]

then hopefully when an error is encountered and an error.sim

file produced ...

you can then fire it up in VB, ensure the error trapping is

commented out, load in the error sim or the save that

you captured which occurred just prior to the error ...

and then run it from there using the debugger.

this may not always work, as there seem to be many variables ...

but I have had it do exactly this for me in the past ...

even using the generated error.sim ...

the error still existing ...

which can certainly save a great deal of time debugging.

[remember to save/rename the error.sim to keep on file

for continued debugging, so it isn't overwritten]

Search

To search from VB, click on the Binocular icon on the toolbar.
Select where you wish to search, current modual, current project.
This will step you thru all occurrences.

Highlighting Variables

Once the debugger has sent you to a line containing an error,
use the mouse to highlight variables to determine their value.
This may help to determine if a variable is out-of-range.

a few notes from Ulciscor on the Forum

http://www.darwinbots.com/Forum/index.php?showtopic=874

If you are running the program from VB, click 'Debug' when the error box appears. This will bring the VB code to focus with the offending code highlighted in yellow. This highlighted code should be copied along with the name of the function it is from (if applicable) and the form or module, which will be shown on the right.

The highlighted code will also display the values of the various variables and properties, at the point when the program crashed, when you hover your mouse over them. It is a good idea to note down the values of each part of the code and post them up with everything else.

If the error occurs from the EXE, then describe what was happening in the sim or what you did before the glitch, or possibly provide the sim file, which should be zipped to save space.

All this info will help us track down the error and its cause, and so to work out possible solutions.

Setting Breakpoints

pause VB, highlight a line, press F9

The Immediate Window

The immediate window in VB is a mostly a place where you can execute code you write on the fly while debugging - code that is not part of the program, but code you want to execute right then for help in debugging. Say you hit a breakpoint and want to step through from there, but with a certain set of variables having a certain set of values, say to reproduce a bug further down the line. Well, instead of waiting for the program to happen upon those values, you can change those variable values manually in the immediate window e.g. x = 5, y = 10, etc. and then proceed. The code you type in the immediate window is, well, immediate. It does not become part of the DB source code - it only executes right there and then is gone. Also useful for things like printing variable values at breakpoints.

what else?