Firstly, yes debug  only has Assert and Print. Considering what debug
is to be used for I think it covers all uses.

Obviously the Print will output any information you think is relevant
to trackdown bugs or odd behaviuor. You can also use the watch window.

The Debug.Assert BoolVar
BoolVar is a variable or result from a conditional test.
So you could also use either the following to go into debug mode when i=6

For i = 0 To 10
Debug.Assert i <= 5
Next i

For i = 0 To 10
Debug.Assert Not(i > 5)
Next i

A guess as to why FALSE should be used to start debug is that
variables that are not dim'd or currently have a value would cause the
debug to start. This is usually a big clue as to why things  are not
working as expected.

Use the contents tab of the vba help  to get a programmers reference
style, for properties, methods, keywords, functions.

It good to see you have an interest in debug. It's usually the last
thing new coders worry about

The reason for the false  value triggering Debug, is that the condition
specified is the normal behaviour you want. Anything else means time to
debug.



The Debug.Assert statement should be read  as though it says "If a condition
arises where the stated condition  is not true then drop into debug"

"variables that are not dim'd " [are assigned a false  value -
implied/understood]. Got it!


> or currently have a value [ of false?] would cause the
> debug  to start.

Typo?

The implication is that bool Vars are "all" used to
indicate "trouble" when in the FALSE state. Not one of my base
assumptions.


> Use the contents tab of the vba help  to get a programmers reference
> style, for properties, methods, keywords, functions.

Sounds like another good thing to know.


> It good to see you have an interest in debug. It's usually the last
> thing new coders worry about :)

Well... I wouldn't say I'm a new coder, just new to VB. I developed
my own laser light show system in the mid 80's on the, ahemm...,
Radio Shack Color Computer - 6809. Basic OS and assembler display
processor...counting processor cycles and all...real time rotates all
at .98 MHz. ! !
It can be a curse going through all the working code  to remove the
file bloat caused by the debugging  print statements, but my mantra is
that test  and comments (and the algorithim phase - I use flowcharts)
take >> time than writing (actually "entering") the code....

From the "Thanks...but" Department...
> ...snip...
> Use the contents tab of the vba help  to get a programmers reference
> style, for properties, methods, keywords, functions.

I went back and looked, but it's the same info I saw by doing my
search for the debug  info. Sorry, but perhaps you didn't catch my
remark:
> > Help seems pretty malodorous as well. ...
a.k.a. stinks as usual.

For Debug.Assert BoolVar, the Help says:
> > "Conditionally suspends execution  ...

> > Conditionally ? What condition? What is the BoolVar for?

Then I speculated:
> > Shouldn't Help say: "When BoolVar (or argument)
> > is FALSE, suspends execution ...

Since I'm not formally schooled in the ways of the Borg (said semi-
affectionately), I wouldn't know that things  happen on a FALSE
condition when they are done "conditinally". At least that is the
implication. I am used to naming things by what happens when the
variable / signal is high or asserted.

Halt -> when high or asserted then STOP
Run -> when high or asserted then GO
Run = *Halt , or HALT bar, or NOT HALT if you prefer. SO I
expected the Debug thingy to be "asserted" (halt execution) when
sumptin' is TRUE.

I should have also said that using the contents tab is a good
suggestion as well because, it is laid out in a more objective
format.