none
Wrong signature applied when using multiple Outlook accounts RRS feed

  • Question

  • I am using Outlook 2010. I have 2 exchange accounts. My "main" personal one and then a 'shared' one.

    I have a default signature file for each. When working directly in Outlook, when I create a new email, the correct signature is provided (sig1 for account1 and sig2 for account2).

    However, when I create a new message programmatically, the signature file for my "personal" account (sig1) is added to the Body of the message when I set the SendUsingAccount field of the mail object to the "shared" account (account2). I know I have the account properly set, as when I send the mail, it is correctly sent from the "shared" mailbox.

    Could you explain this to me please? 

    Code snippet below:

             

    Set olApp = CreateObject("Outlook.Application")		' Create Outlook object    
    For Each olAccount In olApp.Session.Accounts			' Find the Shared account in the list        
       If olAccount.SmtpAddress = SenderAddress Then
          GotIt = 1            
          Exit For        
       End If   
    Next   
    
    Dim olMail As Outlook.MailItem   
    Set olMail = olApp.CreateItem(olMailItem)   ' Body is empty at this point   
    olMail.SendUsingAccount = olAccount   
    
    ' Body now contains the signature of my "personal" account, *not* the account specified by olAccount.

    Monday, March 24, 2014 4:06 PM

All replies

  • Hello Paul,

    Did you try to debug the code? Is the olAccount valid when you set the SendUsingAccount property?

    The scope of the olAccount object is limited by the for each loop. Instead, I'd recommend to declare a local variable. Also I'd suggest calling the Save method after you assigned a new account. Try the code shown in MSDN:

    Sub SendUsingAccount()  
     Dim oAccount As Outlook.account  
     For Each oAccount In Application.Session.Accounts  
     If oAccount.AccountType = olPop3 Then  
     Dim oMail As Outlook.MailItem  
     Set oMail = Application.CreateItem(olMailItem)  
     oMail.Subject = "Sent using POP3 Account"  
     oMail.Recipients.Add ("someone@example.com")  
     oMail.Recipients.ResolveAll  
     oMail.SendUsingAccount = oAccount  
     oMail.Send  
     End If  
     Next  
    End Sub 
    


    Monday, March 24, 2014 4:13 PM
  • Thanks Eugene.

    Yes - I have debugged this to the point of pulling my hair out!

    The olAccount object is a local variable, defined before the for-loop, so it is not going out-of-scope - and it is good when its value is used - otherwise the final email would not be sent from the correct address (I only use the SendUsingAccount setting to control this. I also have debug Windows showing the content of olAccount to be good at the time of the assignment.

    I added an olMail.SAVE after setting the account, but this has made no difference.

    Here's a reword of the code, that fails in the same way:

       Dim olMail As Outlook.MailItem
       Dim olAccount As Outlook.Account
       For Each olAccount In olApp.Session.Accounts
             
            If olAccount.SmtpAddress = SenderAddress Then
               
                 Set olMail = olApp.CreateItem(olMailItem)
                 If olMail Is Nothing Then
                    MsgBox "Failed to create olMail object"
                    Set olApp = Nothing
                    Exit Sub
                End If
            
                olMail.SendUsingAccount = olAccount
                olMail.SAVE
                Exit For
            End If
       Next
    

     

    Monday, March 24, 2014 4:45 PM
  • Hi Paul,

    Did you try to run a sample code provided in my previous message? Does it work?

    Does the end recipient get the "correct" message?

    Monday, March 24, 2014 5:07 PM
  • Eugene

    I have made a test using as close as possible to the sample code and I get the same error:

    It can't replicate it exactly as I am not using a pop3 account.

    Also, I can't see what the "Application" object is in your example - I am assuming that it is a global instance of an Outlook.APPLICATION object, created by Set Application = CreateObject("Outlook.Application").

    Other than this, I'm doing exactly the same thing. Do you have a way to test this yourself? All you need is 2 exchange accounts...

    Monday, March 24, 2014 5:42 PM
  • Hi Paul,

    Actually, there is no need to check the account type. It is up to you which condition is to use.

    Just try to send a message instead of saving. Does the recipient get the correct message?

    Monday, March 24, 2014 5:51 PM
  • Eugene

    Yes - that is what I did and the symptoms are the same. The wrong signature is contained in the message received.

    Paul.

    Monday, March 24, 2014 6:49 PM
  • Paul,

    What account was used? What code did you use?

    Do you have any other add-ins installed for Outlook?

    Could you please specify the Outlook version including its build number? Is it x64 or x86 based application?

    Monday, March 24, 2014 7:44 PM
  • Apologies for the delay- more urgent work took over yesterday.

    Outlook version is 14.0.7116.5000 (32-bit). It's a 32-bit (x86) application. There are no other Outlook add-ins in use.

    The code is as per my entry at 4:45 on Monday - replacing the olMail.SAVE with:

    olMail.Subject = "Text"
    olMail.To = EmailAddress
    olMail.SEND
    

    That should result in a message body that just contains the signature for the matching account (remember both accounts configured within Outlook are Exchange accounts).

    If you can test this, please run a test for each account - for me the problem shows when trying to use the second account loaded in the olApp.Session.Accounts structure.

    In the end I gave up trying to get this to work and now access the signature file directly from its location under the %appdata% folder and this is working fine, but I shouldn't need to do this!

    Thursday, March 27, 2014 9:38 AM
  • I'd be curious to see if creating the email differently would make a difference in what signature is added.

    When you create an email manually in the UI that works correctly, do you first go to the secondary mailbox and then use the New button to create a new email? If not what steps do you use?

    I'd see if getting the secondary mailbox as an Outlook.Store object and using Store.GetDefaultFolder() to get the Inbox or Drafts folders in that store, then using Items.Add() on the Items collection of the folder would get Outlook to use the correct mailbox-based signature when the item was created.


    Ken Slovak MVP - Outlook

    Friday, March 28, 2014 2:50 PM
    Moderator
  • Ken - thanks for the reply.

    Re Manual / UI: The following works:

    1. Make account1 active (e.g. by clicking on its inbox).
    2. Click on "new email" button. The signature for account1 is displayed as expected.
    3. Click on the "from" drop-down, and choose "account2".
    4. The signature automatically changes to the account2 signature, as expected.

    I'm afraid I won't be trying out your "Store" options. I have it working now directly accessing the sig file and I don't have time to go back and endlessly test code rewrites to see if something else works. It should work the way I did it, and it doesn't!

    What I would like is for Microsoft to take ownership of this, run some tests and if a bug is found, fix it so that customers who try to use this feature in future don't have to go through the pain I have experienced.

    Has anyone in MS made any tests to see whether this happens for you too?

    Paul

    Tuesday, April 1, 2014 12:54 PM
  • In general that's not the way it works. Someone has to open a support case for a potential bug and if it is one then depending on the severity of the bug and whether it causes data loss or a crash it's triaged. If there's no business case for a hot fix or immediate fix for an update or service pack the bug is left in the database until version next is worked on. Then it's evaluated as to whether or not to fix it.

    Ken Slovak MVP - Outlook

    Tuesday, April 1, 2014 2:00 PM
    Moderator
  • Paul,

    I'd suggest using the Submit Feedback form in such cases.

    Tuesday, April 1, 2014 2:39 PM