I know I've had this before but I can't remember how to get around it.
I built a managed code add-in that works fine apart from one thing. When I try to close the Access application the application window still persists unless I end task it. When I'm debugging the add-in using Visual Studio 2010 it closes fine when I stop debugging.
I am setting all variables to nothing as part of the on disconnect event.
Public Sub OnDisconnection(ByVal RemoveMode As Extensibility.ext_DisconnectMode, ByRef custom As System.Array) Implements Extensibility.IDTExtensibility2.OnDisconnection
'On Error Resume Next
If Not MenuCommandControls Is Nothing Then MenuCommandControls.Delete()
If Not MenuCommandDimensionVariable Is Nothing Then MenuCommandDimensionVariable.Delete()
If Not MenuCommandFields Is Nothing Then MenuCommandFields.Delete()
If Not MenuCommandForms Is Nothing Then MenuCommandForms.Delete()
If Not MenuCommandParseSQL Is Nothing Then MenuCommandParseSQL.Delete()
If Not MenuCommandQueries Is Nothing Then MenuCommandQueries.Delete()
If Not MenuCommandReports Is Nothing Then MenuCommandReports.Delete()
If Not MenuCommandTables Is Nothing Then MenuCommandTables.Delete()
If Not MenuCommandVariables Is Nothing Then MenuCommandVariables.Delete()
If Not searchForm Is Nothing Then searchForm.Close() : searchForm = Nothing
If Not ObjectSetting Is Nothing Then ObjectSetting = Nothing
If Not AccessInst Is Nothing Then AccessInst = Nothing
If Not addInInstance Is Nothing Then addInInstance = Nothing
'If Not FormParseSQL Is Nothing Then FormParseSQL = Nothing
applicationObject.Quit(Access.AcQuitOption.acQuitPrompt)
If Not applicationObject Is Nothing Then applicationObject = Nothing
End Sub
add x as optional integer to the subroutine
Create a Quit app button and
setting x=1
call your subroutine, and pass the Optional x value to it.
putting the application.quit commmand
at bottom of subroutine, if x=1 then application.quit.
call ONdisconnect subroutine thru the quit app button.
disable all other ways to exit your application.
easy, simple and functional.
this way the Ondisconnect will work when a disconnect occurs or your closing the application.
Related
I've created a small daemon which allows me to control my external display's brightness via DDC. The thing is, after it's been running for ~30 mins or so, it inexplicably closes.
My main.swift is very straightforward:
import Foundation
let application = NSApplication.shared
let applicationDelegate = AppDelegate()
application.delegate = applicationDelegate
application.activate(ignoringOtherApps: true)
application.run()
The strange thing is, it seems to exit with exit code 0, and when in the debugger Xcode says it ended normally. Yet if I print something after application.run() or add a breakpoint there, it never seems to fire.
I've tried adding various symbolic breakpoints to exit, but it never manages to catch where it's happening, and I've got no calls to exit in the codebase anyway.
Why might my application be closing by itself? What can I do to work out the cause?
I have an application that interacts with another one, suspending it while not used. If I end the debugging abruptly the suspended process will stay alive in the background and needs to be terminated.
I did some research and looks like none of the people found a solution that is applicable to Visual Studio 2015, in particular the macro solution will not work since looks like a dropped feature since VS2010...
My current solution is to run the proper taskkill command as a post-build action and within the startup code of the program.
I'm looking for a more elegant way of killing it, so a "post-debug" event like the one portrayed by the macro below would be perfect:
Private Sub DebuggerEvents_OnEnterBreakMode(
ByVal Reason As EnvDTE.dbgEventReason,
ByRef ExecutionAction As EnvDTE.dbgExecutionAction) Handles DebuggerEvents.OnEnterBreakMode
If (Reason = dbgEventReason.dbgEventReasonStopDebugging) Then
KillLeftoverProgram()
End If
End Sub
So is there any way to execute a cleanup shell command after using the stop button?
Bizarre problem.
I am using Excel VBA to control IE and download data from web sites. Pretty vanilla.
I experience an error that only happens when I am running Windows 8.1 and IE 10. On a second PC, which is running Windows 7 and IE 8, the code works fine.
Here is the behavior.
I call the following code to open a web page:
Set appIE = CreateObject("InternetExplorer.Application")
With appIE
.navigate sURL 'Where sURL is a valid web address
End With
This works fine, and opens a browser.
Shortly afterwards, I call the following:
With appIE
.navigate sURL'a different valid web address
End With
An error message pops up at the .navigate line. The message says:
Run-time Error '-2147024726(800700aa)'
Method 'Navigate' of object 'IEWebBrowser2' Failed
I have looked up this error message and the only thing that I can find is that it may relate to spyware. But I completely reinstalled the OS and all apps on the system and the same thing happened.
Another very strange phenomenon is that if I put a trace point in-between the above two sections and pause the code, then manually start the code again, everything works fine. But if, instead of me putting in a trace point I put in a wait loop, I get the same failure. That is, if I manually pause and then resume the code, the code works, but if I automate a pause and resume, the code does not work.
As you consider this situation, please remember that everything works fine under Windows 7 and IE 8, and everything works fine if I manually pause and restart.
Does any of this make sense?
1- Please Check sURL (if you check, please check again compiled folder)
2- Delete WebBrowser Control and Add New
Me forget copy original file App.Path + "\error.html" and see this problem.
I have a VB6 app that has a ton of 3rd party components. The app works well, but on exit (and only when running as a standalone EXE, e.g. not in the IDE), it pops up an error message:
I've seen errors like these before but typically it says which component is missing dependencies or is not registered properly.
I ran it through Process Monitor and got the following files that it cannot find:
And then it quits. I googled the file names that it cannot find and can't seem to find anything. It seems like its searching for a variation of MSComENU, MSComEN and MSCOENU dlls.
I checked and rechecked to make sure that all the the 3rd party components are there and they are - the application functions fine, it wouldn't if they weren't there.
It is worth noting that error occurs after the last line of VB6 code (in Form_Unload event) has fired. I know this because the last line is a message box that does appear.
Much, much later EDIT: I finally got back to dealing with the problem and figured it out by process of elimination (and it was a loooong process). In the end it had nothing to do with any MSCOMM*.dll entries. In fact, I do not know why they still show up in Process Monitor. The problem was much simpler.
I had several 3rd party controls on the main form. In an effort not to pollute the main form with a ton of event handling code, I delegated these controls to a new class, like so:
' declaration code in main form'
Private WithEvents moDelegateObject as clsDelegateObject
' still in the main form, after initialization'
Set moDelegateObject = new clsDelegateObject
With moDelegateObject
Set .ThirdPartyCtlHandler1 = me.ThirdPartyCtl1
Set .ThirdPartyCtlHandler2 = me.ThirdPartyCtl2
Set .ThirdPartyCtlHandler3 = me.ThirdPartyCtl3
end with
' declarations and properties inside of clsDelegateObject'
Private WithEvents moThirdPartyCtlHandler1 as ThirdPartyCtl
Private WithEvents moThirdPartyCtlHandler2 as ThirdPartyCtl
Private WithEvents moThirdPartyCtlHandler3 as ThirdPartyCtl
Public Event FooEvent() ' other various events as well '
Public Property Set ThirdPartyCtlHandler1(o as ThirdPartyCtl)
moThirdPartyCtlHandler1 = o
End Property
Public Property Get ThirdPartyCtlHandler1() as ThirdPartyCtl
ThirdPartyCtlHandler1 = moThirdPartyCtlHandler1
End Property
' ... Repeat for each handler ...'
What was missing was code to explicitly deallocate these objects prior to closing. This is something that Visual Basic typically does. So I added the following in the Form_QueryClose in the main form:
With moDelegateObject
Set .ThirdPartyCtlHandler1 = Nothing
Set .ThirdPartyCtlHandler2 = Nothing
Set .ThirdPartyCtlHandler3 = Nothing
End with
Set moDelegateObject = Nothing
Last line turned out to be superflous, but I threw it in there for completeness sake. I think it was a combination of delegating controls to a delegate class and receiving events from it in the Main form and using a good number of really obscure 3rd party controls which contributed to this problem. It is probable that the 3rd party control does not cleanly deallocates itself. Anyway, lesson learned.
This could be a DLL_PROCESS_DETACH or CoUninitialize problem. Raymond Chen's blog "The Old New Thing" has a couple of relevant articles:
When DLL_PROCESS_DETACH tells you that the process is exiting, your best bet is just to return without doing anything
Do you know when your destructors run? Part 1.
Quick overview of how processes exit on Windows XP
How you might be loading a DLL during DLL_PROCESS_DETACH without even realizing it
The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification
As you said these are 3rd party components. You could try to make smaller test cases until the problem disappears to pinpoint the buggy component. You could also try a native code debugger and analyze what code created the error message.
The simplest solution however to work around the issue is trying to force a specific load-order of all those components. In the Main() or startup form, try to use some functionality of each 3rd party component in a fixed order. If the bug still appears, change the order until the problem vanishes. That might work.
You could try using dependency walker on the list of references in the project file to see if any of those third party files are missing dependencies. If no dependencies are missing then try registering the files again using regsvr32. If any of the regsvr32 commands fail then you may have found the component with missing dependencies.
I'm having an issue referencing public procedures of User Controls that I've created within a VB6 project.
A simple example (exe), I have a form with a button and a user control:
Option Explicit
Private Sub Command1_Click()
UserControl1.updateMessage ("TIME NOW: " & DateTime.Time)
End Sub
The User Control code is as follows:
Option Explicit
Public Sub updateMessage(ByVal newMessage As String)
Label1.Caption = newMessage
End Sub
This exe compiles and works fine, and when I'm typing updateMessage in the Form, it appears in the intellisense list with the appropriate requirements. The issue I have is when I'm wanting to "go to the definition" of updateMessage, instead of going to the appropriate section of the code within the User Control, the message always returns with:
"Cannot jump to 'updateMessage' because it is in the library 'Unknown1' which is not currently referenced."
where the numbered suffix of "Unkown1" changes from time to time.
It seems that if there were no reference to this procedure, then it would not appear in the intellisense and the project shouldn't compile. When running this with MZTools (though the error appears regardless of this plug-in being installed), I can go into the updateMessage procedure, and use it to find all procedures calling this function, so the link between the two should exist (although I'm not sure if MZTools just finds using a text-matching pattern).
If anyone out there could shed some light on this matter, it would be very much appreciated, and save this poor VB6 developer a lot of hassle!
I have SP6 installed (build 9782) of VB6 and am running XP SP3 on an HP dx2400.
Yes, this is extremely annoying and I'm convinced it's a bug in VB6. I say this because, if you locate the updateMessage method in the object browser and double-click on it, you are taken to the definition. So, the compiler actually does know where the definition is, it just refuses to take you there with Shift+F2.