How do I Set or Clear the Visibility of the BCC Field in a MailItem using Outlook VBA

[NeoPa]

I have developed some code to add an address to the BCC field in an Outlook MailItem :

Private Sub VBAInspectors_NewInspector(ByVal Inspector As Inspector)
    With Inspector.CurrentItem
        If .Class = olMail Then
            ' Note the current visibility of the BCC field
            With .Recipients.Add(conBCC)
                .Type = olBCC
                Call .Resolve
            End With
            'Reset visibility of BCC Field to original setting
        End If
    End With
End Sub

I would like to replace the comments in lines #4 and #9 with code to note, and then reset, the visibility of the BCC field within the MailItem.

conBCC is a string constant that contains a valid address string with an @ within it.

In the window of the MailItem it is easy to see and set this setting using the View menu (in 2003 and other approaches to do a similar job in later versions). I'm interested in finding how to see and set this in VBA specifically.

[Rabbit]

I don't think the BCC field has to visible to add a recipient to it.

So the only case you need to worry about is when they don't have it visible and you want to set it back to invisible after the e-mail is sent. In that particular situation, after they send the e-mail, I don't believe that setting persists.

However, if the goal is to add a BCC and then hide it from user so they don't know a BCC was there in the first place, I don't know of a way to do that.

I know there's a registry setting that controls the default of whether or not to show the BCC field, but I don't know of a method within Outlook that will do so dynamically.

[NeoPa]

Setting the BCC value works fine. That is not at issue. Unfortunately, setting the value has an unfortunate side-effect of setting the visibility too.

My motive for resetting the visibility is not to hide anything from the user at all, but rather to avoid making changes to the user's settings that they have not chosen themselves. I have a fundamental belief in the naffness of software that changes settings on your behalf without your permission and simply don't want my code to be that naff. No more than I would ever consider entering someone's house as a guest and moving their furniture arround to suit my own personal tastes. It's just a wrong thing to do IMHO.

PS. The BCC visibility setting does persist for other emails once set this way, although you won't see it for sent emails (under any circumstances).

[Rabbit]

I tried it in outlook 2007 and adding a recipient to the BCC field doesn't persist the setting for me.

Perhaps it does so for 2003? I am unable to test that as I don't have access to Office 2003 anymore.

You could set the registry value. But that doesn't change it for the currently loaded Outlook processes until it is restarted.

[NeoPa]

Thanks Rabbit.

It certainly does so for 2003. I'll test on 2007 later to ensure we're talking about the same thing.

I found the registry setting you referred to. It's at HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\O utlook\Preferences\ShowBcc. I'm going to look into this as it could well prove a workable solution (The Office version Number in that is pretty easy to get from the interface I expect).

I still prefer the idea of using the Outlook interface if at all possible, but I can at least provide a working version that doesn't have naff side-effects in the mean time, so that's a big step forward.

[NeoPa]

Some info on the Office Version number for Outlook :

Although Access provides the number in X.Y format (as required here), Outlook provides it as A.B.C.D, so the following (or equivalent) is required :

strVersion = Left(Application.Version, InStr(4, Application.Version, ".") - 1)

[Rabbit]

I've yet to find anything in VBA that will allow me to set user preferences. Barring any such functionality, the only option is to use that registry key.

The only drawback is it won't reload that preference until they restart outlook.

[NeoPa]

Rabbit:
The only drawback is it won't reload that preference until they restart outlook.

That's a shame, because it's a complete show-stopper ;-(

I'll do some testing now I have the Registry Read/Write code working (I thought I had that already but found all I had previously developed was some code to read values if they were REG_SZ. Pretty limited really. A bit of a shock as I remembered it as something that enabled reading and writing of the Registry generally.

Never mind. I spent a good number of hours today developing it to handle reading and writing of REG_DWORD, REG_SZ, REG_EXPAND_SZ, REG_MULTI_SZ & REG_BINARY, so I'm happy with that now (I struggled with converting negative numbers into a string and then with write permissions which confused me royally for ages until I realised it wasn't my user permissions - I'm a local Admin of course - that were the issue but the parameters I'd used to open the Registry Key). If the changing of the Registry value doesn't have any effect until after Outlook is restarted, it will not be anything I can use here though unfortunately (as it would never get a chance to have any effect and wouldn't stop the operator irritation that I'm working to avoid). I'll post back when I've confirmed whether or not it can work (but that may be delayed as I'm all thunk out - I've been working solidly at this for a long while and need a break).

[NeoPa]

It seems the Registry setting isn't even changed by Outlook until it closes either, which makes the whole approach unworkable. What a shame.

Don't think it wasn't a good idea to bring up though. It was the best I've had (received) yet. It was just very unfortunate that it led down a blind alley in the end.

[NeoPa]

Jimmy Peña from LinkedIn has offered a suggestion of :

Inspector.CommandBars.FindControl(, 1860).Execute

It's probably the closest yet to what's required, but although it toggles the visibility, it doesn't set it related to what the user has chosen. Indeed there is no way I know of yet even to determine what the user has chosen for this.

[Rabbit]

The registry value should be the setting the user has it at shouldn't it? Assuming you read that registry value before setting anything in code.

[NeoPa]

The Registry setting reflects the value it was at when Outlook was started, but if I use that and the user decides to change their choice for that setting then their choice would be lost if they opened any new emails subsequent to that (because, as mentioned earlier, that change of setting is only saved away to the Registry when the Outlook application terminates).

Having said that, it's something to consider. It can at least approximate to what's required.

Having considered that some more, I believe the confusion that might ensue after a user tried to change the setting but their choice was lost, may well be more of a negative mark against the software even than not being able to make the choice at all. If I'm honest though, I'm still a little torn on this one.

[NeoPa]

I have managed to get closer with the help of Malcolm Dixon from LinkedIn. It's particularly interesting as it provides insight into how to interface with the menu system within Outlook (and probably by extension into other Office apps too).

Unfortunately, I think I must admit defeat here :-( It seems that Microsoft have implemented an interface where doing this task, at the point where it needs to be done, is not possible (I'm always happy to be proven wrong of course).

The .State part of the code seems to be working fine. Where the problem lies is with switching the setting back once it's been set by the fact of setting a value in the BCC field (It doesn't like that until the MailItem is visible and it can't do that until after the event procedure has completed). I tried setting it by creating a new MailItem on the side just to change the setting with (As I could see that it had worked in Malcolm's code that way), but not only had the newly created item not registered that the State had changed in the first place, but changing it in the new item had no effect on the item that had just been created (The one that triggered the event) either.

The latest code I had is shown below. It's the closest I could get to a working version, but line #36 simply has no effect (It runs ok, but changes nothing).

Option Explicit
 
Private Const conBCC As String = "ValidMailAddress"
 
Private WithEvents VBAInspectors As Inspectors
 
Private blnBCCOK As Boolean
 
Private Sub Application_Startup()
    Set VBAInspectors = Application.Inspectors
 
    'Determine if conBCC is usable for use later on
    If conBCC = "" Then Exit Sub
    With Application.CreateItem(olMailItem).Recipients.Add(conBCC)
        blnBCCOK = .Resolve
    End With
    If Not blnBCCOK Then _
        Call MsgBox(Prompt:="Unable to resolve '" & conBCC & "'.", _
                    Buttons:=vbOKOnly, _
                    Title:="Outlook Startup")
End Sub
 
Private Sub VBAInspectors_NewInspector(ByVal Inspector As Inspector)
    Dim blnBCCVis As Boolean
    Dim cbcBCC As CommandBarControl
 
    With Inspector.CurrentItem
        If .Class = olMail _
        And blnBCCOK Then
            Set cbcBCC = Inspector.CommandBars("View").Controls("BCC Field")
            blnBCCVis = cbcBCC.State
            With .Recipients.Add(conBCC)
                .Type = olBCC
                Call .Resolve
            End With
            If Not blnBCCVis Then Call cbcBCC.Execute
        End If
    End With
End Sub

[Rabbit]

Does it work if you make the mail item visible for the duration of the code?

[NeoPa]

NeoPa:
(It doesn't like that until the MailItem is visible and it can't do that until after the event procedure has completed)

I may not have expressed that well in my previous post (#13) but it won't allow me to make the item visible (using Call .Display BTW) while the event is still active. There is also no timer event I can find to enable code to be run afterwards :-(

[Rabbit]

Would it be possible to store the inspector for later use?

[NeoPa]

I'm pretty sure I could manage that (in a global array of such items I expect), but I'm not aware of any way I could trigger processing it later. There appears to be no way of regaining control at an appropriate time. I'm guessing you have some thoughts on that though, perhaps?

[Rabbit]

I think there's an on send event for e-mail?

[NeoPa]

There are various events, which I will look into more deeply. Your post triggered me to find how I could look into events for these other objects (I'm still very green on the Outlook side. The code is structured so differently it seems to me.) and that is my next task. I should say, at this point, that I don't feel the Send event would be particularly helpful as running the code at that time would be more confusing to the operator, and it's the avoidance of such confusion and inconvenience that I'm trying to effect with this code.

Thanks for the trigger for looking deeper though. I feel I should have seen that myself, but somehow avoided realising all these events were available to me.

[NeoPa]

I'm very happy as of right now. It's barely minutes before I need to leave for my appointment, but I've just got time to post the solution I managed to come up with (with no little input from you guys - as well as some from guys on LinkedIn). The solution I found, that I'm confident now does the trick, is :

Option Explicit
 
Private Const conBCC As String = "ValidEmailAddress"
 
Private WithEvents VBAInspectors As Inspectors
Private WithEvents VBAInspector As Inspector
 
Private blnValidAddr As Boolean
 
Private Sub Application_Startup()
    Set VBAInspectors = Application.Inspectors
 
    'Determine if conBCC is valid for use later on
    If conBCC = "" Then Exit Sub
    With Application.CreateItem(olMailItem)
        With .Recipients.Add(conBCC)
            blnValidAddr = .Resolve
        End With
        Call .Close(olDiscard)
    End With
    If Not blnValidAddr Then _
        Call MsgBox(Prompt:="Unable to resolve '" & conBCC & "'.", _
                    Buttons:=vbOKOnly, _
                    Title:="Outlook Startup")
End Sub
 
Private Sub VBAInspectors_NewInspector(ByVal Inspector As Inspector)
    With Inspector.CurrentItem
        If blnValidAddr _
        And .Class = olMail Then _
            Set VBAInspector = Inspector
    End With
End Sub
 
Private Sub VBAInspector_Activate()
    Dim blnBCCVis As Boolean
    Dim cbcBCC As CommandBarControl
 
    If VBAInspector Is Nothing Then Exit Sub
    Set cbcBCC = VBAInspector.CommandBars("View").Controls("BCC Field")
    blnBCCVis = cbcBCC.State
    With VBAInspector.CurrentItem.Recipients.Add(conBCC)
        .Type = olBCC
        Call .Resolve
    End With
    If Not blnBCCVis Then Call cbcBCC.Execute
    Set VBAInspector = Nothing
End Sub

The Activate event of the Inspector occurs on various occasions, but that includes the one immediately after the Inspector has been created. The main benefit being that the item is displayed already by the time the Activate event is triggered. I ensure it is only run on this occasion by tying it to the valid content of the VBAInspector object.

I'm going to go ahead and set this as Best Answer. Not because I deserve the lion's share of the credit in this case, but simply because anyone searching for a similar answer should be able to find it by coming straight to this post.

Thanks again to all for your help and your 'Stick with me' attitude.