Good point....

However, I too have heard there is a performance issue when Set Assert is left On.

As for using compiler directives, why not just have a line of code at the beginning of your app like this:

If "EXE"$Version(1)
Set Assert On
Else
Set Assert Off
Endif

Or better yet:

If _VFP.StartMode = 0 && a development version of VFP
Set Assert On
Else
Set Assert Off
Endif

At least this way - you do not have to keep recompiling things. So, if a client has a problem, you can get his/her EXE - drop it into your dev environment - and automatically have assertions available. I just don't like the idea of having to recompile to get to a certain state. We have all of these ways to tell if we are in or not in dev mode. Why not use them????




>Hi John,
>
>>Assertions are for developers only. What good does it do for an end-user to see a dialog that displays as a result of a failed assertion. Craig is 100% correct here in that when distributing your application - Set Assert should be off.
>
>May I disagree here with you? ;-) ASSERT is ignored by the runtime library, since there's no debugger that can be shown up. So there's no real reason to handle SET ASSERT differenly when distributing your application. Nevertheless, I'd remove them entirely when building the distribution application, either via
>
> #DEFINE ASSERT NOTE
>
>or by surrounding them with an #IF...#ENDIF statement.
>
>Christof