DOCUMENT:Q201741 11-JAN-2001 [vbwin] TITLE :INFO: Differences of Behavior in Debug Mode and Compile Mode PRODUCT :Microsoft Visual Basic for Windows PROD/VER:WINDOWS:4.0,5.0,6.0 OPER/SYS: KEYWORDS:kbCompiler kbDebug kbThread kbVBp kbVBp400 kbVBp500 kbVBp600 kbIDEProject kbGrpDSVB kbD ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Visual Basic Standard Edition, 32-bit, for Windows, version 4.0 - Microsoft Visual Basic Professional Edition, 16-bit, for Windows, version 4.0 - Microsoft Visual Basic Professional Edition, 32-bit, for Windows, version 4.0 - Microsoft Visual Basic Enterprise Edition, 16-bit, for Windows, version 4.0 - Microsoft Visual Basic Enterprise Edition, 32-bit, for Windows, version 4.0 - Microsoft Visual Basic Control Creation Edition for Windows, version 5.0 - Microsoft Visual Basic Learning Edition for Windows, version 5.0 - Microsoft Visual Basic Professional Edition for Windows, version 5.0 - Microsoft Visual Basic Enterprise Edition for Windows, version 5.0 - Microsoft Visual Basic Learning Edition for Windows, version 6.0 - Microsoft Visual Basic Professional Edition for Windows, version 6.0 - Microsoft Visual Basic Enterprise Edition for Windows, version 6.0 ------------------------------------------------------------------------------- SUMMARY ======= For the same piece of code, a Visual Basic application's behavior can be different when running as a compiled EXE and when running in debug mode in the IDE. This article explains the most common reasons why an application's behavior can be different and recommend ways to handle these situations. MORE INFORMATION ================ Focus issues ------------ This is the most common reason for differences in behavior. While running in Debug mode, the focus change exists between the forms and Visual Basic IDE, and such foucs changes are not possible while running as an EXE. In addition, using message boxes in focus intensive applications will cause huge differences in behavior between compiled and debug modes. Recommendations: - Avoid using message boxes for debug purposes. Use "Debug.Print" statements instead. In the compiled EXE, use file input/output for debuging. - When shifting focus between Visual Basic application and the Visual Basic IDE, make sure that the focus stays in the desired location. Interpreter Vs Compiler issues ------------------------------ When running in Debug mode, the code is interpreted, while in run mode, the code is compiled and executed. The behavior difference may be because of the difference in the way the Interpreter and Compiler handle some code. Recommendations: - Compile the application in P-code instead of Native code. P-code bahavior is similar to that of interpreter while Native code may behave differently. - If the application is compiled using Native code, use VC++ to debug your compiled application. See the first two articles in the REFERENCES section for a detailed description. Issues with yielding to other processes --------------------------------------- When running in Debug mode and stepping each line of code, the processor gets enough time to yield to other processes and it is somewhat similar to calling DoEvents each time you enter into Debug mode. A compiled application may not yield to the processor at the expected line of code. Recommendations: - Put DoEvents before the line where the behavior is different for a compiled EXE. This may give the same bahavior as running in Debug mode. - Avoid putting break points in lines of code, where you do not want to yield to other processes. Use Debug.print or file input/output to debug in such situations. Threading --------- The IDE has only two threads running at a time. A background thread allows Visual Basic to process the Control-Break while running code that is not yielding time. To be able to access DataMembers and allow for compile on demand Visual Basic restricts all components running in Debug mode to a single thread of execution. This is especially important when debugging ActiveX components. For example, adding an ActiveX DLL project to a Standard EXE project for debugging may not work the same as when you debug the EXE using the compiled DLL. This also effects any programs that depend on name space seperation to function properly. For example, if you reference a variable defined in a standard bas module, this variable will be shared across every module running on the same thread. So in the IDE, if you change this variable in one class other classes will also see the change. This can lead to the mistaken impression that variables in base modules are global when they are really only thread global. When your application runs in compiled mode the variable may no longer be shared. To learn more about how data is shared in a multithreaded environment, please look for the topic "Apartment-Model Threading in Visual Basic" in MSDN Help or Books Online. Recommendations: - Use Visual C++ to debug the compiled application. See the first two articles in the REFERENCES section for a detailed description. - In addition to using the VC debugger, you can also debug ActiveX components by running the client in one session of the Visual Basic IDE and running the server in another session. - Do not reply on Public variables in standard bas Modules when using multiple threads. If you need static shared variables, search MSDN Help, or Books Online, for the topic "Static Class Data." Other Causes: ------------- Usually, the issues with differences in bahavior can be resolved by following the recommandations given earlier. You may experience differences due to other reasons also. Contact developer support at this stage. REFERENCES ========== For additional information, please click the article numbers below to view the articles in the Microsoft Knowledge Base: Q166275 HOWTO: Debug a Native Code Visual Basic Component in VC++ Q193133 HOWTO: Compile VB Programs with Debug Symbols Embedded Q161153 HOWTO: Use the Assert Method for Debugging Q192549 INFO: VBCE: Overview of Debugging VBCE Applications Q138521 INFO: Program Compiles in Background w/Compile On Demand Set Additional query words: automation error F8 F5 interface development running outcome path ====================================================================== Keywords : kbCompiler kbDebug kbThread kbVBp kbVBp400 kbVBp500 kbVBp600 kbIDEProject kbGrpDSVB kbDSupport Technology : kbVBSearch kbAudDeveloper kbZNotKeyword6 kbZNotKeyword2 kbVB500Search kbVB600Search kbVBA500Search kbVBA500 kbVBA600 kbVB500 kbVB600 kbVB400Search kbVB400 kbZNotKeyword3 kbVB16bitSearch Version : WINDOWS:4.0,5.0,6.0 Issue type : kbinfo ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2001.