Understanding "Assert"

[Don Wells]

    I must be particularly thick these days, for I am unable to get my mind wrapped around the Debug.Assert command. Using Excel 2003 VBA the Help file on Assert states:

The following example shows how to use the Assert method. The example requires a form with two button controls on it. The default button names are Command1 and Command2.

When the example runs, clicking the Command1 button toggles the text on the button between 0 and 1. Clicking Command2 either does nothing or causes an assertion, depending on the value displayed on Command1. The assertion stops execution with the last statement executed, the Debug.Assert line, highlighted.

And provides the following code:

Code: Select all

Option Explicit
Private blnAssert As Boolean
Private intNumber As Integer

Private Sub Command1_Click()
    blnAssert = Not blnAssert
    intNumber = IIf(intNumber <> 0, 0, 1)
    Command1.Caption = intNumber
End Sub

Private Sub Command2_Click()
    Debug.Assert blnAssert
End Sub

Private Sub Form_Load()
    Command1.Caption = intNumber
    Command2.Caption = "Assert Tester"
End Sub

    I have been unable to exercise the code and would appreciate someone implementing it in an Excel workbook so that I might step through it and gain a thorough understanding,

T.I.A.

[HansV]

The code is intended for VB6, but it can easily be adapted for a VBA userform. See the attached sample workbook (Excel 97-2003 format).

AssertTest.xls

Download the workbook.
Right-click the file in Windows Explorer and select Properties from the context menu.
If there is an "Unblock" button, click it.
If you're using Excel 2007 or later, it's best to store the workbook in a trusted location.

Open the workbook, enable macros if prompted, and click the big command button to display the form.

Clicking the first command button on the form will toggle its caption between "0" and "1". This has no intrinsic meaning.
If you click the second command button while the first reads "0", code will be paused.
If you click it while the first reads "1", nothing will happen.

[Don Wells]

Thank you Hans

[Don Wells]

Please tell me where I am misunderstanding. The Help file states:

Remarks
Assert invocations work only within the development environment. When the module is compiled into an executable, the method calls on the Debug object are omitted

Yet when I launch Excel, open the workbook and display the form by way of the "Please Click Me!" command button -- believing that I am not in the development environment -- I am surprised to see that the VBE opens with the procedure paused.

[HansV]

That remark applies to VB6, where you can compile a project into an executable (.exe). In an executable, you cannot view or debug the source code any more - it has been removed, and only the compiled machine code remains (more or less). An Excel workbook, when opened in Excel, is not an executable (the Excel application itself is an executable, but a workbook isn't). You can view and debug source code. So in a manner of speaking, you are always in the development environment when working with a workbook. The same holds for Word documents and PowerPoint presentations.

[Don Wells]

Thank you Hans. I could not have asked for a more clear explanation.

[ChrisGreaves]

I must be particularly thick these days,

Speaking as one thicky to another ....
The help files (VB6/VBA) sometimes seem to go out of their way to add unwanted complexities.

Just in case you're struggling with the concept of Debug.Assert ..
... I think of it as an executable IF statement.

When I'm testing a Function procedure that returns a result - and the result is typically a string, Boolean or numeric value - I set up a test that ought, if everything goes well, return a specific value of that type. For example, it might be that a Function of type Long should return the value 6 from a specific set of arguments

My Debug.Assert statement then reads (e.g.)

Code: Select all

Debug.Assert 6=lngMyFunction(arg1, arg2 etc.)

If lngMyFunction has behaved properly with arg1, arg2 etc. and returned the value 6,
then Debug.Assert will find a value TRUE and continue on its merry way.
If Debug.Assert finds FALSE (e.g. the function returned 5 or 7) then the Debug.Assert statement halts execution (yellow highlighting).


In my TEST subroutine that tests a function, a series of Debug.Assert statements will, if everything works well, just execute and end.
But if any one of the Debug.Assert statements finds FALSE, the macro stops (yellow highlighting)

In this way I can "batch" a set of tests on a function.

HTH
Oh, and BTW, NTIAR!

[Don Wells]

• Thank you for that Chris
• NTIAR ???

[ChrisGreaves]

NTIAR ???

No Thanks In Advance required - AIYDK!