Setting Outlook Application to nothing causes Access to crash

[darbid]

I have objApp declared as an Outlook.Application object for a form. (I mean at the top so that it has scope for the whole form)

During the use of the form people may or may not set objApp to be the Outlook Application and get other objects like a mailitem object or appointment object. They use this in other parts of the form so I do not set the objects to nothing.

In the close event I thought this would be good housekeeping

if not objApp is nothing then
      set objApp = nothing
end if

When Access closes down (and compacts on close down) I get that Access has a problem and I have a check box to back up the MDB.

Irrespective of the choice. When I reopen the MDB I cannot get into the VB Editor. But it still runs.

If I copy the form object and rename it then the form is ok and I can open it with VB Editor.

One other interesting thing is that if I delete the form object I get an extra request about information on the clipboard. This does not usually happen when you delete a form.

 

[ajetrumpet]

putting this problem to logic i would say this....

your variable is declared behind the FORM and not just certain procedures, therefore it is initialized whenever that form is being run or is loaded. if you set the obj to NOTHING while the form is loaded, that would be like telling a car to STOP and GO at the same time (i would think), or, as another example, using the INCLUDE() statement in PHP when all you want is a variable from the other file.. it's just a spitball approach that i am using, so don't take these comments to heart....but i would seriously consider dimming the obj in every procedure rather than behind one whole object. dimming var's that are never set to nothing is not a problem because they are simply to small to have any impact on your program's operting capability. for example, you would never set this variable to NOTHING:

dim i as integer

Why? i really have no idea, but that's really irrelevant to me. bottom line, from this man's perspective, i would dim signifcant var's, like applications, in their own procedures, and kill them at the end to make sure the memory is dumped...

 

[darbid]

Thanks for picking up this thread which I thougt I would not get any thoughts on.

I also think that by the time the "Close" event has come around for a form the form is kinda already closed. If this were to work I might need to put in in the unload routine.

The form finds the right Appointment item in one routine and then it is used in another routines in the same form. So I thought that declaring it as a form variable would save time as I find it once and then when users want to use it I just check to make sure it is not nothing.

But my problems seem to be more fundamental and coming from Outlook. If outlook is not open and I have to CreateObject then Outlook will not close properly. And remains in Memory, I thought I was on top of this but obviously not.

Set OutApp = GetObject(, "Outlook.Application")

If Err.Number = 429 Then
    Err.Clear
    Set OutApp = CreateObject("Outlook.Application")
    Set OutNS = OutApp.GetNamespace("MAPI")
    Set OutFolder = OutNS.GetDefaultFolder(olFolderInbox)
    OutFolder.display
    OutApp.ActiveExplorer.WindowState = 0
    OutApp.ActiveExplorer.WindowState = 1

Set OutNS = Nothing
Set OutFolder = Nothing
Set OutApp = Nothing