Mailto links and sending immediately

[Fred K]

When I click a mailto link and send the email it doesn't send until the next
time I open Outlook in full. Is there a setting I'm missing to make it send
right away? Outlook 2007 on Windows XP SP3.

 

[Diane Poremsky [MVP]]

Outlook needs to be running to send mail.

--
Diane Poremsky [MVP - Outlook]



Outlook Tips by email:
(e-mail address removed)

EMO - a weekly newsletter about Outlook and Exchange:
(e-mail address removed)

You can access this newsgroup by visiting
http://www.microsoft.com/office/community/en-us/default.mspx or point your
newsreader to msnews.microsoft.com.

 

[Fred K]

Diane,

As a programmer that makes no sense. The classes and methods used to send
the email should still be available. If, for some odd reason, they were
designed not to be I would suggest that this should be changed. As it stands
it makes the user think the email was sent when it wasn't. If I click send
on an email I expect it to go, not wait for further action on my part unless
I specifically tell it to wait.

Thanks for your time to answer.

Outlook needs to be running to send mail.

--
Diane Poremsky [MVP - Outlook]



Outlook Tips by email:
(e-mail address removed)

EMO - a weekly newsletter about Outlook and Exchange:
(e-mail address removed)

You can access this newsgroup by visiting
http://www.microsoft.com/office/community/en-us/default.mspx or point your
newsreader to msnews.microsoft.com.

When I click a mailto link and send the email it doesn't send until the
next
time I open Outlook in full. Is there a setting I'm missing to make it
send
right away? Outlook 2007 on Windows XP SP3.

 

[VanguardLH]

Thanks for your time to answer.

Outlook needs to be running to send mail.

--
Diane Poremsky [MVP - Outlook]



Outlook Tips by email:
(e-mail address removed)

EMO - a weekly newsletter about Outlook and Exchange:
(e-mail address removed)

You can access this newsgroup by visiting
http://www.microsoft.com/office/community/en-us/default.mspx or point your
newsreader to msnews.microsoft.com.

When I click a mailto link and send the email it doesn't send until the
next
time I open Outlook in full. Is there a setting I'm missing to make it
send
right away? Outlook 2007 on Windows XP SP3.

As a programmer that makes no sense. The classes and methods used to send
the email should still be available. If, for some odd reason, they were
designed not to be I would suggest that this should be changed. As it stands
it makes the user think the email was sent when it wasn't. If I click send
on an email I expect it to go, not wait for further action on my part unless
I specifically tell it to wait.

Just because you see a new-mail compose window doesn't mean all of
Outlook has been loaded. Only a stub of Outlook is loaded that is
sufficient to handle the new-mail compose window and to deposit the new
message into the message store (under the Outbox). Items that are
programmatically added to the message store (by any program, included
the Outlook stub) won't result in that new item getting sent because
Outlook itself is not fully loaded to then comply with configuration
settings (like Send Immediately) or to perform scheduled mail polls.

Think if it like a listserver. You might be able to send a new message
or new list of recipients to your listserver service because you want to
spew out a new bulk e-mail but nothing is going to happen if the
listserver itself isn't running. The auxilliary services of updating
your lists doesn't require the listserver is running to perform any
action based on your update of your lists. Or, even simpler, think of
you adding food onto a tray in food line where you are expected to pay
for what's on you tray at the end of the line at the cashier. You are
not supposed to be eating the food off your tray before you get to the
end before which you might've removed items that you couldn't afford or
decided something else was better so you only pay for what's there when
you pay. Microsoft probably had their reason for not sending
immediately everything that could possibly be programmatically added to
the Outbox in its message store, perhaps because Outlook was foremost a
client and not a server.

It doesn't matter that all the same function libraries are available.
Sending e-mail is not the function of the new-mail compose window. Its
function is to add an item to the message store. Its the function of
full program to handle the actual sending of those items.

If you want more help on how Outlook functions, talk to the folks over
at www.outlookcode.com or one of the vba newsgroups. You are
programmatically creating a new item in the message store. That's all.
You're tossing items into an Outbox tray on your desk. That doesn't
mean they go anywhere.

Can you programmatically update the message store and then
programmatically do a send? Maybe (using the SyncObject collection at
http://msdn.microsoft.com/en-us/library/microsoft.office.interop.outlook.syncobjects.aspx).
Does the new-mail compose window do both? No, it just updates of the
message store (using CreateItem). Even the example code at
http://msdn.microsoft.com/en-us/library/ms268749(VS.80).aspx to "send"
mail programmatically only does a CreateItem() to update the message
store but it never actually does a send. If you look at the code at
http://kbalertz.com/220600/Automate-Outlook-Using-Visual.aspx, you'll
see that it actually STARTS Outlook to make sure it is fully loaded so
that when an item is programmatically added to the message store then
the rest of Outlook is available to actually to the send. I'm not sure
you need to load Outlook versus using the Namespace.SyncObjects class.

 

[Fred K]

Hello Vanguard.

Thank you for taking the time to write that lengthy reply. I completely
understand (and did) what function it is performing. However, I am saying
that from a usability perspective it is not functioning well.

As a user I don't care what is under the hood. When I click Send I expect
my email to go. Period. If it isn't getting sent right away then label the
button Queue For Sending Later or Send The Next Time You Open Outlook.

As a programmer I say that there is no reason that the mail sending, with
full rules, etc. cannot be invoked when the user clicks send. The "full
Outlook" is loaded to present a user interface. The rest of it is function
calls which do not (or should not) rely on the user interface being awake or
active.

Make it a listener service which watches for updates in the outbound
folder/file. Make it a shared function the new email ui can call. I don't
care how it is accomplished but I know that it is not optimal from a
usability perspective. I was hoping there was a built in option to make it
perform the way it should. There isn't.

Thanks.

Thanks for your time to answer.

Outlook needs to be running to send mail.

--
Diane Poremsky [MVP - Outlook]



Outlook Tips by email:
(e-mail address removed)

EMO - a weekly newsletter about Outlook and Exchange:
(e-mail address removed)

You can access this newsgroup by visiting
http://www.microsoft.com/office/community/en-us/default.mspx or point your
newsreader to msnews.microsoft.com.

When I click a mailto link and send the email it doesn't send until the
next
time I open Outlook in full. Is there a setting I'm missing to make it
send
right away? Outlook 2007 on Windows XP SP3.

As a programmer that makes no sense. The classes and methods used to send
the email should still be available. If, for some odd reason, they were
designed not to be I would suggest that this should be changed. As it stands
it makes the user think the email was sent when it wasn't. If I click send
on an email I expect it to go, not wait for further action on my part unless
I specifically tell it to wait.

Just because you see a new-mail compose window doesn't mean all of
Outlook has been loaded. Only a stub of Outlook is loaded that is
sufficient to handle the new-mail compose window and to deposit the new
message into the message store (under the Outbox). Items that are
programmatically added to the message store (by any program, included
the Outlook stub) won't result in that new item getting sent because
Outlook itself is not fully loaded to then comply with configuration
settings (like Send Immediately) or to perform scheduled mail polls.

Think if it like a listserver. You might be able to send a new message
or new list of recipients to your listserver service because you want to
spew out a new bulk e-mail but nothing is going to happen if the
listserver itself isn't running. The auxilliary services of updating
your lists doesn't require the listserver is running to perform any
action based on your update of your lists. Or, even simpler, think of
you adding food onto a tray in food line where you are expected to pay
for what's on you tray at the end of the line at the cashier. You are
not supposed to be eating the food off your tray before you get to the
end before which you might've removed items that you couldn't afford or
decided something else was better so you only pay for what's there when
you pay. Microsoft probably had their reason for not sending
immediately everything that could possibly be programmatically added to
the Outbox in its message store, perhaps because Outlook was foremost a
client and not a server.

It doesn't matter that all the same function libraries are available.
Sending e-mail is not the function of the new-mail compose window. Its
function is to add an item to the message store. Its the function of
full program to handle the actual sending of those items.

If you want more help on how Outlook functions, talk to the folks over
at www.outlookcode.com or one of the vba newsgroups. You are
programmatically creating a new item in the message store. That's all.
You're tossing items into an Outbox tray on your desk. That doesn't
mean they go anywhere.

Can you programmatically update the message store and then
programmatically do a send? Maybe (using the SyncObject collection at
http://msdn.microsoft.com/en-us/library/microsoft.office.interop.outlook.syncobjects.aspx).
Does the new-mail compose window do both? No, it just updates of the
message store (using CreateItem). Even the example code at
http://msdn.microsoft.com/en-us/library/ms268749(VS.80).aspx to "send"
mail programmatically only does a CreateItem() to update the message
store but it never actually does a send. If you look at the code at
http://kbalertz.com/220600/Automate-Outlook-Using-Visual.aspx, you'll
see that it actually STARTS Outlook to make sure it is fully loaded so
that when an item is programmatically added to the message store then
the rest of Outlook is available to actually to the send. I'm not sure
you need to load Outlook versus using the Namespace.SyncObjects class.

 

[VanguardLH]

Thank you for taking the time to write that lengthy reply. I completely
understand (and did) what function it is performing. However, I am saying
that from a usability perspective it is not functioning well.

As a user I don't care what is under the hood. When I click Send I expect
my email to go. Period. If it isn't getting sent right away then label the
button Queue For Sending Later or Send The Next Time You Open Outlook.

As a programmer I say that there is no reason that the mail sending, with
full rules, etc. cannot be invoked when the user clicks send. The "full
Outlook" is loaded to present a user interface. The rest of it is function
calls which do not (or should not) rely on the user interface being awake or
active.

Make it a listener service which watches for updates in the outbound
folder/file. Make it a shared function the new email ui can call. I don't
care how it is accomplished but I know that it is not optimal from a
usability perspective. I was hoping there was a built in option to make it
perform the way it should. There isn't.

Actually I'm not disagreeing with you. I would also prefer that a
message composed in the new-mail compose window would also get sent
immediately. Of course, this means it would be pretty easy to write
malware that did the same thing. I wouldn't doubt that Microsoft chose
that Outlook behaves this way due to some security reason or to enforce
the precept that Outlook is a client and not a server although I've
never seen them explain their choice.

 

[Fred K]

Security is a good point. However, malware could just as easily look for the
Outlook process and start it up in the background to send email if it wasn't
already running if the malware had gotten into a place to be able to start a
process. Phew, long sentence. Forcing the UI to open is not a barrier to
that. I guess that's my issue ... I can't think of a valid architectural or
security reason to do it the way it's done so it just looks like laziness.
It certainly looks like poor usability.

Thanks again for responding.