Latest revision as of 19:25, 26 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

(remove these edit's as you see fit Griz, this is your domain! As far as I can see the two lines to be edited are the same line under two different names as regards Erics post later on)

 
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.

(It saves the error sim but also lets you degug as well AFAIK, based on experience it doesn't make a difference, what is the real advantage of doing this?)

i don't think so, at least it didn't in the past ... or with 2.37 anyway.

it may be a little different setup in 2.4X ...

but i still think one needs to comment it out ... else why would eric have posted about it?

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
(variables in the highlighted line of code, if there are no variables there don't worrry, a step by step intro to how you obtain the error can be just as useful) 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

(Should be up top, if, like me, peeps are VB newbs then the acronym KISS seems appropriate, start with the simple stuff)

still just gathering info. will see what all we get and then arrange it ...

assuming anyone is going to ever read it. ;)

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. (example? I always add a few following lines of code in case the line in question is repeated, don't know if that is needed but it makes me feel better!)

The highlighted code will also display the values of the various variables (if there are variables in that line) 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. (Always note the steps you took before the error. Standard error reporting info...)

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

Setting Breakpoints

pause VB, highlight a line, press F9

(Or use debugger option when it finds error, I'm still not sure why I should use a breakpoint)

because you can set them anywhere in the program ... not just where the debugger sends you.

this will cause the program to 'break' there ... for testing new code or investigating where

you might think there is a problem.

an example for you might be ... setting a break point just after the code that is activated

when you click that "win" button in leagues. then you could go there and take a look at the

variables and maybe see why they increment by something other than "1".

you might even put in a line of code as a delay after clicking the button ...

if it turns out the routine is executing so quickly it catches you with your pants, err ... button down. ;)

i think you can even 'step' thru the program, watching what happens. Griz^talk

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?

Breakfast at Tiffany's? Good stuff so far, I would start with a really basic page, downloading relevant stuff and basic reports then expand into the more difficult stuff. Just my opinion, you may ignore it as you see fit! (Is there a better way for me to add comments to pages? I'm not used to not getting a new post for my comments, don't want to slow you down by making you search for my comments). (my mistake didn't read your message first!)

yeah ... seeing as i don't know how to debug myself yet ... i still have no idea what we will put here.

so we're reinventing the wheel as we go i guess. this is still the 'info gathering' stage.

added in context is ok ...

just try to use some color or something so i see them.

it's all temporary right now anyway.

also ... adding ~~~ or ~~~~ adds your sig and/or time stamp. then i know who it is and when it was added.

like so: Griz^talk 17:13, 26 Dec 2006 (MST)