Force open Outlook (1 Viewer)

Gasman

Enthusiastic Amateur
Local time
Today, 10:28
Joined
Sep 21, 2011
Messages
6,003
I'm a bit curious on why you believe this is the case. Given a few seconds of time to be open, why would it not send the email, once the appropriate code to send it has fired?
Ah, OK. I am talking about a home outlook setup and I have mine setup for a regular Send and Receive every 30 mins.
That way I either manually send and receive (normally the case) or wait until the time period has expired.
That allows me to correct an email if need be, unlike in a coporate environment with Exchange where it disappears as soon as Send is clicked.

Again Bad Memory. :)

I've just tested with my DB and that is what happens in my environment.
However it raises an issue, if you do not test if it is open or not, how do you decide to set the object to Nothing or not.?
I think that was the reason for fIsOutlookRunning flag originally being used, but I must have been having problems with GetObject() as you mentioned to change the logic.?

Long time ago now, so cannot remember why.:(
 
Last edited:

Isaac

Well-known member
Local time
Today, 02:28
Joined
Mar 14, 2017
Messages
1,023
Gotcha.

However it raises an issue, if you do not test if it is open or not, how do you decide to set the object to Nothing or not.?
(Well if I am following your meaning correctly), if you code to open a new instance of the app, then you code to quit that instance as well. You can set your app instance variable to nothing if you'd like, although unnecessary as VBA destroys objects when they go out of scope anyway.

I see what you mean about your particular environment and the Send. Mine just sends right away.
 

Gismo

Registered User.
Local time
Today, 12:28
Joined
Jun 12, 2017
Messages
483
i used the code in post #8
it seems to work just fine
not sure why it did not work in the first place
the only thing is, I placed it in a module but i do not call for it in any form or macro
 

Gasman

Enthusiastic Amateur
Local time
Today, 10:28
Joined
Sep 21, 2011
Messages
6,003
Gotcha.


(Well if I am following your meaning correctly), if you code to open a new instance of the app, then you code to quit that instance as well. You can set your app instance variable to nothing if you'd like, although unnecessary as VBA destroys objects when they go out of scope anyway.

I see what you mean about your particular environment and the Send. Mine just sends right away.
Ok, thinking more on how mine works (Outlook normally open)
I was (in this thread at least) thinking that if Outlook was open, then it would use that instance, and then setting it to Nothing would close an already open Outlook.?
This is not the case as my Outlook is 99.99% open all the time, so CreateObject creates another instance which is set to Nothing at the end.
If Outlook is not open, it opens and then closes it, leaving the user with the same state of Outlook as before the code was run.
 

Isaac

Well-known member
Local time
Today, 02:28
Joined
Mar 14, 2017
Messages
1,023
No, I don't think setting it to nothing (again something unnecessary, as vba cleans garbage when scope is out) will have any effect. Using the quit command, yes.
 

Gasman

Enthusiastic Amateur
Local time
Today, 10:28
Joined
Sep 21, 2011
Messages
6,003
No, I don't think setting it to nothing (again something unnecessary, as vba cleans garbage when scope is out) will have any effect. Using the quit command, yes.
I've heard that, but still do it. :) yet I stick by the single EOF test on opening a recordset. :)

Actually no ,no Quit just
Code:
Proc_Exit:
    Set objOutlook = Nothing
    Set objOutlookMsg = Nothing
    Set objOutlookRecip = Nothing
    Set objOutlookAttach = Nothing
    Set rs = Nothing
    Set rsCW = Nothing
    Set db = Nothing
    SetStatusBar (" ")
    Exit Sub
and I have just checked my outlook options and the Send/receive every n minutes is even deselected. :) So manual only.
 

Isaac

Well-known member
Local time
Today, 02:28
Joined
Mar 14, 2017
Messages
1,023
That should leave the app open
 

Isaac

Well-known member
Local time
Today, 02:28
Joined
Mar 14, 2017
Messages
1,023
I'm having trouble following, but I think we agree.
I don't think setting an application variable object to Nothing will have any effect on the application staying open, whether using GetObject or CreateObject. Sorry Gismo to hijack your thread with our side conversation LOL
 

Gasman

Enthusiastic Amateur
Local time
Today, 10:28
Joined
Sep 21, 2011
Messages
6,003
I'm having trouble following, but I think we agree.
I don't think setting an application variable object to Nothing will have any effect on the application staying open, whether using GetObject or CreateObject. Sorry Gismo to hijack your thread with our side conversation LOL
Probably learning a lot from this. :) However the initial question was to Force Outlook open, and as always there are various ways to do it.
As I mentioned I initially had the test if open, use , else open outlook logic, but reverted to the simple one line I have now and it suits me fine. I send emails every other day, if not every day using this method, without any problems.
Saying that now, something will go wrong tomorrow, you watch. :)
 

The_Doc_Man

Happy Retired Curmudgeon
Local time
Today, 04:28
Joined
Feb 28, 2001
Messages
17,059
In all cases where the app object in question is managed by an external task, Excel and Outlook and Word being prime candidates in this list, setting the object variable to nothing breaks the link between Access and the other task but doesn't terminate the task. It leaves that task in a "hanging" state because it is not under control of a keyboard - it is under control of a now-dead internal link. The task "remembers" how it was opened and its input channels reflect the connection, which was probably via SMB protocol.

It is correct that if you create a local object variable in a subroutine (including event routines) that the "End Sub" or "Exit Sub" will clean up all local variables. However, one thing that some folks do (including me) is put object variables in the declaration area of a general module that contains a whole bunch of support code for that specific type of object. If you do that, though, exiting a particular support routine won't kill the object variable because it isn't local. This is why you should always clean up what you messed with. And if it has a life of its own (but you don't want it to) then again, remember to clean up the messes you make outside of Access.

Not only that, but we had a discussion with a member of the Access developer team once. The thread should still be around but I can never find it. In passing he commented that there are times due to optimizations in SMB v2 and v3 protocols that even cleaning up a recordset by formally closing it is a good idea even if the recordset object was locally declared. Something to do with attempting to hold back the automatic writeback behavior of a recordset because of the higher network traffic implied for network-accessible back ends and the formal rs.Close operation forces the writebacks despite the protocol change. The person offering that post linked to an external article on the SMB v2/v3 changes. With Win10, SMB v1 is no longer the default protocol for Access connections so it becomes important.

Therefore, it is a good idea that for objects, you should close before you set the object to nothing OR before you leave scope. And it would be OK if you leave scope without first setting objects to nothing if you have at least closed or terminated them.
 

Isaac

Well-known member
Local time
Today, 02:28
Joined
Mar 14, 2017
Messages
1,023
yes I was pretty much just talking about when you create it locally. I don't generally use objects from outside procedures, but that's a good reminder on that part of it
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Top Bottom