Difference between revisions of "DeBugging"
m (how about some VB debugging tips?) |
m |
||
| Line 10: | Line 10: | ||
:on VB and Debugging so we might be able to help out tracking down errors? | :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. | :Anyone signed in here at the Wiki can edit and add to these pages. | ||
| − | :{{User:Griz/sig}} | + | :Just click on edit and have at it. |
| + | :Not to worry about correct/ideal formatting ... | ||
| + | :we'll figure it out. | ||
| + | :{{User:Griz/sig}} 15:04, 24 Dec 2006 (MST) | ||
| + | |||
| + | = Basic Debugging from VB = | ||
| + | |||
| + | == error.sim == | ||
| + | From Eric:<br> | ||
| + | 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 | ||
| + | |||
| + | <pre> | ||
| + | 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 | ||
| + | </pre> | ||
| + | |||
| + | Comment this '''''On Error''''' out when using VB and Debugger ...<br> | ||
| + | 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> | ||
| + | '''''save error.sim''''' | ||
| + | Also ... once the debugger has sent you to the break ...<br> | ||
| + | 'hovering' the mouse over variables in the code will<br> | ||
| + | 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> | ||
| + | using this, even I have been able to locate errors on occasion.<br> | ||
| + | |||
| + | == Search == | ||
| + | To search from VB, click on the Binocular icon on the toolbar.<br> | ||
| + | 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> | ||
| + | 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 == | ||
| + | I need some help with this one. ;) {{User:Griz/sig}} | ||
| + | |||
| + | == what else? == | ||
Revision as of 18:04, 24 December 2006
Contents
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.
- Griztalk 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.
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.
Setting Breakpoints
I need some help with this one. ;) Griztalk
