The immediate window 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 execte 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 varaible 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.
good to know. thanks. I'll try to put this all into a Debugging Guide ...
so any other hints/techniques you can share will be appreciated.
you just got to put them somewhere where I can find and gather them.
hmmmm ... I know of such a place.
Wiki is for static, long lived information. Forum is for dynamic discussion.
that sounds like a pretty good guideline. however, finding things here on the forum
still leaves something to be desired ...
esp if one, such as a newbie, doesn't already know it exists.
I still have a hard time tracking down messages/topics I KNOW are here somewhere ...
they tend to end up being scattered about in different threads ...
and even then have spent a great deal of time searching for them, sometime unsuccessfully.
so I'm still for making it as easy as possible for those folks who haven't been in on all the
discussions from the beginning, to be able to find their way around ...
and hopefully have them aware that there is also such a thing as the wiki available to them.
some may find it easier and less confusing to work there. I certainly do.
at least the search function here seems to now at least sorta work.
there is a search function on the wiki as well.
Most of the league code is in the F1mode module though some is in with the options form
code and a few other places.
ok. thanks. I'll keep looking.
Any assistance that helps narrow down a bug is totally appreciated. The ones with the long repro times are the worst. If someone catches one of these in the debugger, that is gold since they are so hard and time intensive to reproduce. Even just telling me what line it occurs on and nothing else helps tremendously. Non-programmers who are willing to run under VB can really be tremendously helpful even without any understanding of the source code or programming skills. Some bugs can be environment specific and hard to reproduce execpt on a specific machine. Getting someone to run DB under VB on that machine can be serious money and save days of debugging elsewhere. Many thanks!
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, ensuring the error trapping is
commented out, load in the error sim or ideally, 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 varialbles ...
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]
onward
