Mathimagics
11-13-2003, 11:21 AM
Here are 3 different methods of testing whether a program is running in the IDE or as an EXE. We define a function IsEXE which returns True if running as EXE, False if running in IDE.
Method #1Private Function IsEXE() As Boolean
On Error GoTo IDE
Debug.Print 1 / 0
IsEXE = True
IDE: Exit Function
End Function
This uses the fact that the Debug.Print statement will not be executed in a compiled program, so the "Divide by Zero" error is not triggered.
It's concise, and almost a perfect solution.
It has one minor drawback - sometimes you want to run a program in the IDE with the "Break on ALL errors" option. You'll obviously get the error triggered when you call this function.
A very minor deficiency, really, so this function should suit MOST requirements.
I rate it a 99% solution, losing 1 mark for the minor deficiency.
Method #2Private Function IsEXE() As Boolean
IsEXE = App.EXEName <> App.Title
End Function
This is another simple but effective method, and it avoids using error traps.
It DOES require you to ensure that you compile to an EXE name that is different to the Project name.
The EXE name can be established the first time you compile, and thereafter no further intervention should be required.
But this restriction, however minor, still costs 1 mark, so this solution also scores just 99%
For purists, or obsessive-compulsive types like the author, I also present the 100% solution:
Method #3Private Function IsEXE() As Boolean
Dim AppEXEpath As String
AppEXEpath = App.Path & "\" & App.Exename & ".exe"
IsEXE = StrComp(AppEXEpath, ExePathFromWindow(Me.hWnd), 1) = 0
End Function
The EXEpathFromWindow function is from another demo I posted somewhere, its method is well-known. I'll post it below, but for now just assume it does what it says - given any window handle, it returns the full pathname of the executable file from which the window was created.
If we are in the IDE, that file will be VB6.exe (in whichever folder VB was installed).
If we are in the EXE, it should of course match the App object's Path & EXEname (minus the .exe extension). The use of StrComp avoids any problems caused by compiling to ".EXE" or ".Exe" or ".exe".
Method #1Private Function IsEXE() As Boolean
On Error GoTo IDE
Debug.Print 1 / 0
IsEXE = True
IDE: Exit Function
End Function
This uses the fact that the Debug.Print statement will not be executed in a compiled program, so the "Divide by Zero" error is not triggered.
It's concise, and almost a perfect solution.
It has one minor drawback - sometimes you want to run a program in the IDE with the "Break on ALL errors" option. You'll obviously get the error triggered when you call this function.
A very minor deficiency, really, so this function should suit MOST requirements.
I rate it a 99% solution, losing 1 mark for the minor deficiency.
Method #2Private Function IsEXE() As Boolean
IsEXE = App.EXEName <> App.Title
End Function
This is another simple but effective method, and it avoids using error traps.
It DOES require you to ensure that you compile to an EXE name that is different to the Project name.
The EXE name can be established the first time you compile, and thereafter no further intervention should be required.
But this restriction, however minor, still costs 1 mark, so this solution also scores just 99%
For purists, or obsessive-compulsive types like the author, I also present the 100% solution:
Method #3Private Function IsEXE() As Boolean
Dim AppEXEpath As String
AppEXEpath = App.Path & "\" & App.Exename & ".exe"
IsEXE = StrComp(AppEXEpath, ExePathFromWindow(Me.hWnd), 1) = 0
End Function
The EXEpathFromWindow function is from another demo I posted somewhere, its method is well-known. I'll post it below, but for now just assume it does what it says - given any window handle, it returns the full pathname of the executable file from which the window was created.
If we are in the IDE, that file will be VB6.exe (in whichever folder VB was installed).
If we are in the EXE, it should of course match the App object's Path & EXEname (minus the .exe extension). The use of StrComp avoids any problems caused by compiling to ".EXE" or ".Exe" or ".exe".