DeBugging - Revision history

Griz: /* Setting Breakpoints */

2006-12-27T00:25:11Z

‎Setting Breakpoints

Griz at 00:23, 27 December 2006

2006-12-27T00:23:48Z

Griz at 00:13, 27 December 2006

2006-12-27T00:13:48Z

Jez at 22:30, 26 December 2006

2006-12-26T22:30:18Z

Jez at 22:28, 26 December 2006

2006-12-26T22:28:25Z

Griz: added debugging tip for those long, long sims

2006-12-26T00:05:18Z

added debugging tip for those long, long sims

Griz: /* Highlighting Variables */added Ulciscor's note

2006-12-25T17:54:13Z

‎Highlighting Variables: added Ulciscor's note

Griz at 22:04, 24 December 2006

2006-12-24T22:04:00Z

Griz: how about some VB debugging tips?

2006-12-24T15:19:53Z

how about some VB debugging tips?

Numsgil: Reverted edit of 85.255.113.155, changed back to last version by 70.95.101.129

2006-01-15T22:03:45Z

Reverted edit of 85.255.113.155, changed back to last version by 70.95.101.129

@@ Line 110: / Line 110: @@
 ::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. ;) {{User:Griz/sig}}
+::if it turns out the routine is executing so quickly it catches you with your pants, err ... button down. ;)
 == The Immediate Window ==

@@ Line 101: / Line 101: @@
 == 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)
+pause VB, highlight a line, press F9
 == The Immediate Window ==

@@ Line 23: / Line 23: @@
 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)
+In MDIForm1 (code), Private Sub simload
 <pre>
@@ Line 34: / Line 36: @@
 Comment this '''''On Error''''' out when using VB and Debugger ...<br>
-or it will abort and go save the error.sim.<br> (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?)
+or it will abort and go save the error.sim.<br>
 Then remember to uncomment it once you have located and fixed an <br>
 error and want to recompile or the recompiled prog won't do it's<br>
@@ Line 75: / Line 85: @@
 :'''''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)
 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!)
@@ Line 89: / Line 105: @@
 == 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!)

@@ Line 91: / Line 91: @@
 == 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).
+(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!)

@@ Line 23: / Line 23: @@
 This is the only one I know of that has to be commented in/out:
-In MDIForm1 (code), Private Sub simload
+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)
 <pre>
@@ Line 34: / Line 34: @@
 Comment this '''''On Error''''' out when using VB and Debugger ...<br>
-or it will abort and go save the error.sim.<br>
+or it will abort and go save the error.sim.<br> (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?)
 Then remember to uncomment it once you have located and fixed an <br>
 error and want to recompile or the recompiled prog won't do it's<br>
 '''''save error.sim'''''
 Also ... once the debugger has sent you to the break ...<br>
-'hovering' the mouse over variables in the code will<br>
+'hovering' the mouse over variables in the code will<br> (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.<br>
 this is helpful in finding overflows or variables out of range.<br>
@@ Line 75: / Line 75: @@
 :'''''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 (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.
-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. (''Always'' note the steps you took before the error. Standard error reporting info...)
-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. (Yay! (sry))
 == Setting Breakpoints ==
-pause VB, highlight a line, press F9
+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)
 == 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? ==

@@ Line 43: / Line 43: @@
 this is helpful in finding overflows or variables out of range.<br>
 using this, even I have been able to locate errors on occasion.<br>
 == Search ==
@@ Line 48: / Line 67: @@
 Select where you wish to search, current modual, current project.<br>
 This will step you thru all occurrences.
 == Highlighting Variables ==
 Once the debugger has sent you to a line containing an error,<br>
@@ Line 67: / Line 85: @@
 == Setting Breakpoints ==
-I need some help with this one. ;) {{User:Griz/sig}}
+pause VB, highlight a line, press F9
 == what else? ==

@@ Line 53: / Line 53: @@
 use the mouse to highlight variables to determine their value.<br>
 This may help to determine if a variable is out-of-range.
 == Setting Breakpoints ==

@@ Line 10: / Line 10: @@
 :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.
-:{{User:Griz/sig}} 08:19, 24 Dec 2006 (MST)
+:Just click on edit and have at it.

← Older revision		Revision as of 15:19, 24 December 2006
Line 5:		Line 5:

	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.		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.
		+	:{{User:Griz/sig}} 08:19, 24 Dec 2006 (MST)

@@ Line 1: / Line 1: @@
 == Compiler Related Recommendations ==
- <div style="overflow:auto; height: 1px; ">
 == 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.