I have two methods of determining wether or not the application is running in IDE or not, and please feel free to post your own methods. Here they are:

[code]
Function IsIDE() As Boolean
On Error Goto IDE

Debug.Print 1 / 0
IsIDE = FALSE
Exit Function

IDE:
IsIDE = TRUE
Exit Function
End Function
[/code]

This function uses the known fact that the Debug.Print statement will not be executed in a compiled program, thus the Divide by Zero error is not triggered. In conclusion, it's short and to the point.

However, it has one small drawback, sometimes the programmer may want to run a program in the IDE with the Break on [U]ALL[/U] errors option. The error will obviously be triggered when a call to this function is made.

[code]
Function IsIDE() As Boolean
IsIDE = (App.EXEName = App.Title)
End Function
[/code]

This function is yet another simple but effective method of testing if the program is in the IDE or NOT, and it avoids using error traps!

However, it [U]requires[/U] that the programmer makes sure he compiles to an EXE name that is different from that of the Project name.

hmm, in c/c++ you can do this:
#ifdef DEBUG
// we're in ide
#else
// we aren't
#endif

There might be a similar predefined variable in VB?


And VB actually lets you compile a program that has an obvoius 1/0 in it? Most compilers won't even let you try!

[quote author=iago link=board=31;threadid=3955;start=0#msg32562 date=1070167038]
hmm, in c/c++ you can do this:
#ifdef DEBUG
// we're in ide
#else
// we aren't
#endif

There might be a similar predefined variable in VB?


And VB actually lets you compile a program that has an obvoius 1/0 in it? Most compilers won't even let you try!
[/quote]

Actually, it's

#ifndef NDEBUG
/* debug build */
#endif

This is unrelated to actually having a debugger attached.

That's true, but generally you'll have a debug build well testing and a release bulid otherwise.

There's also IsDebuggerPresent() for Win32.