Clever Geek Handbook

VB6 crashes while debugging with an active Windows connection

One of our largest legacy VB6 applications has some code in it to allow other applications (including some dotNETs) to pass an ID to it via a Windows message - this ID is then used by the VB6 application to load the record into a regular Windows form. The message hook is added after the user logs in and is authenticated and removed after logging out.

Public Sub HookClaimFinderCall()
    lpPrevWndProc = SetWindowLong(gHW, GWL_WNDPROC, AddressOf WindowProc)
End Sub

Public Sub UnhookClaimFinderCall()
    Dim temp As Long
    If gHW <> 0 Then temp = SetWindowLong(gHW, GWL_WNDPROC, lpPrevWndProc)
End Sub

Private Function WindowProc(ByVal hw As Long, ByVal uMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
    If uMsg = WM_FINDCLAIM Then
        MasterFindClaim lParam
    End If
    WindowProc = CallWindowProc(lpPrevWndProc, hw, uMsg, wParam, lParam)
End Function

However, there are two questions. The first is for Visual Studio 6. If the code is being debugged and an error occurs to open the Continue to End Debugging dialog, pressing End exits Visual Studio instantly (losing any unsaved changes). This does not happen if the error message has not yet been activated. What is causing this, and is there anything I can do to stop it without commenting out the code that loads the hook?

Second, if users leave the application without logging out properly (by whatever means), what happens to the error message?

Hopefully I have all the conditions right in the above ...

+2


source to share


2 answers


  • If you initiate a global hook and try to debug in VB6, you get a crash (or VB6 disappeared). VB6 is like a simulator, it doesn't exactly duplicate the execution time of a VB6 application, and interception is one area where it fails (although it really can't be blamed if you understand what's going on). For all the global hooks that we use in our applications, we check if VB6 is running in IDE mode (there are several ways to do this), and if so, do not fire a global hook. If you absolutely need to start a global capture, do not stop the application in the debugger - use debug.print or some other means, but do not stop the application, otherwise you will have milliseconds per second before it "quits".
  • While you must unhook before exiting the application when the message pump is hooked and the application descriptor where the hook occurs no longer exists, it's a fairly straightforward operation to ignore that hook. Now, if you've run the app and exited thousands of times, it will probably build up, but I think this is the least of your problems.


+5


source


Chris's answer is correct. A few extra points.



  • This is strictly a subclass, not a message binding.
  • It's also good practice in yours WindProc

    to detect WM_NCDESTROY and unhook when this message is received. The message means that the window should be destroyed - it should be received if the user leaves the application, no matter how they do it.
  • There are several API calls in Windows 2000 and later that make the subclass easier to manage. As always, Karl Peterson has a great article with great VB6 code here .
+3


source






More articles:


All Articles