by Jim Karabatsos - GUI Computing
If you are at all like me, you will spend a lot of time working through administrivia screens in your applications while testing them. It seems you spend half your time looking at the splash screen, then typing the userid/password, clicking the OK button, and selecting the screen that corresponds to the area of the application you are working on. What I really want is for the application to let me bypass all this when I am in test mode and just have the application start up and get me into the area I am interested in as quickly as possible.
I have for a long time standardised on a secret command line switch that the application would look for and, if it found it, would use special start-up logic. I would do something like this in the Sub Main or the Form_Load event of my start-up form:
If Instr(Command$, "/DEBUG=ON") Then DoSpecialSetupForDevelopment Else DoNormalSetup End If
This actually works fine. All you need to do is set up the VB5 IDE to have the value "/DEBUG=ON" (in addition to anything else you might have) in the command line and you are done. However, you do need to remove or disable this code before you ship your application. While most users would not even know how to set up a command line in a shell link, there's always the chance that someone will play with it and inadvertently trigger your debug code. In my applications, that could be disasterous because I often set SuperDooper Admin Mode in that code. <P>You could of course minimise the chances of that actually happening by using a really obscure string on the comamnd line, like this:
If Instr(Command$, "hU8sP" & "98242" & "jp0mk") Then DoSpecialSetupForDevelopment Else DoNormalSetup End If
I would suspect that's safe enough for anyone. Use a totally separate magic string for each app, and you are done. Note also that I have split the string into three separate constants so that the complete string does not appear in the EXE.
I recently came across another idea that I like a lot. Here is a function that lets you determine if your program is executing under the control of the IDE or as a compiled executable:
Public Function InIDE() As Boolean On Error Resume Next InIDE = False Err.Clear Debug.Print 1 / 0 If Err.Number <> 0 Then InIDE = True End If End Function
This function use the fact that Debug.Print statements are not executed at all unless the code is running under the control of the IDE. By placing an expression that is guaranteed to generate a run-time error in a Debug.Print statement, we can use the fact that an error has occurred (or not, as the case may be) to determine if we are running in the IDE or not.
To use this function, just place it in any module and forget about it. Note that you cannot compile it into an ActiveX utility DLL because it will then return the InIDE status of that DLL, not your project as a whole.
I really like this approach because it does not just test to see if the VB IDE is running but tests specifically that THIS app is running in the IDE.
I found this idea (with a slightly different implementation) at a new site I discovered that I like a lot. Check out http://www.vb-helper.com for a small but nice collection of VB-specific tips and tricks.