Toolbar not always showing up

  • Thread starter Thread starter Lars Roland
  • Start date Start date
L

Lars Roland

Hi

I (and some others) have written a small program for figting Spam from
within outlokk (you can download a beta of it from www.olspamcop.org) -
The problem is that this program is a toolbar for outlook and it does not
always showup (although extremly rarly).

The program will install without any problems, and the registry settings
is correcet (eg. the addin is set to load on startup of outlook), the
addin is also in the list of COM addins - but there is no toolbar (it
is not in the list of toolbars).

The problem has only been seen two times, and both times it was with
office 2002 (XP) - does anyone know what this can be ?, or perhaps a
method for debugging this ?.


Regards

Lars Roland
 
As far as debugging it you can set a breakpoint in your code at the point
where the toolbar is created and make sure the code is creating a valid
CommandBar object.

A problem like that which only surfaces at random intervals is the hardest
thing to troubleshoot unless you can find some commonality in setups where
the code fails. Only 2 data samples makes that much harder of course.

It might help if you show the code you are using to create the toolbar,
where you are creating it and anywhere you are enabling/disabling the code.
You might also put up a debugging message dialog that is displayed when the
toolbar is created and try that code on the affected machines to make sure
the code is reaching that point.
 
As far as debugging it you can set a breakpoint in your code at the point
where the toolbar is created and make sure the code is creating a valid
CommandBar object.

Yes - I realize, that if I should crack this problem I will have to
recreate at the office, because I have no idea about how to remotly debug
a program. - This is hard though, because if i install the excact same
version of windows and office as the users has, then the problem does not
happen, so I am floading in the wild here -

My only discovery is that if i change the code that creates the toolbar,
to not create a tempoary toolbar then, there is no problem (this however
introduce the another problem, with uninstalling the addin). A question is
then if it is better to not create the toolbar and the buttons on it as
tempoary objects and instead let the uninstaller delete them from inside
outlook ?
It might help if you show the code you are using to create the toolbar,
where you are creating it and anywhere you are enabling/disabling the code.
You might also put up a debugging message dialog that is displayed when the
toolbar is created and try that code on the affected machines to make sure
the code is reaching that point.

The code to set the commandbar up, is basicly a spin of the ItemCB example
from Microeeye (http://www.microeye.com/resources/itemsCB.htm) - the code
folows:


------------------------------------------------
' Test if the toolbar already exists
On Error Resume Next
Set cbrNewToolbar = golApp.ActiveExplorer.CommandBars(cmdName)
If Err Then
blnNew = True
' Create a new items toolbar.
Set cbrNewToolbar = golApp.ActiveExplorer.CommandBars.Add _
(Name:=cmdName, Position:=msoBarTop, Temporary:=True)
Else
Set CBBTest = cbrNewToolbar.FindControl(Tag:="")
If CBBTest Is Nothing Then
' Do nothing since this toolbar is not from VBAProject.OTM in BAO2K
Else
' Delete existing buttons
Do Until cbrNewToolbar.Controls.Count = 0
cbrNewToolbar.Controls.Item(1).Delete
Loop
End If
End If
------------------------------------------------




Regards

Lars Roland
 
I always use a belt and suspenders approach with all Outlook code.

I always declare any toolbar/menu as temporary and then when the Close event
fires for that Explorer or Inspector I get the toolbar/menu from a
collection I created where I store the Tag property of that toolbar/menu. I
use the Tag as both the collection member and its Key property so I can
locate it in the collection easily. I then delete the toolbar. That way I'm
positive that it's gone.
 
I always use a belt and suspenders approach with all Outlook code.

I always declare any toolbar/menu as temporary and then when the Close event
fires for that Explorer or Inspector I get the toolbar/menu from a
collection I created where I store the Tag property of that toolbar/menu. I
use the Tag as both the collection member and its Key property so I can
locate it in the collection easily. I then delete the toolbar. That way I'm
positive that it's gone.

Seams like the correct way to do this, unfortunatly it also seams that
creating the toolbar tempoary triggers that the toolbar does not show up
in some rare cases. I will let it be this way, beacuse I also, always
create my stuff tempoary, and make sure that it gets deleted -

It is better that the toolbar does not show up in some rare casess,
than not being sure that it gets deleted when/if people uninstall my program.

Thanks for the quick answars


Regards

Lars Roland
 
Hey Lars... first thing I'd do is ditch the On Error Resume Next code. Also
hopefully you're using Option Explicit because I didn't see any Dim's.
Anyway those two things are a common cause for many bugs.

But now onto what I think you might be running into. I also have an Outlook
add in that creates toolbars and I've found that ActiveExplorer is null
(Nothing in VB/VB.NET) if Outlook is opened invisibly. This means if
ActiveSync or OneNote or Word is spawning Outlook then your code will fail
because you can't call members of null ActiveExplorer.

This of course depends on the location of your toolbar creation code. If
you're doing it in the OnConnection then what I'm describing is probably
happening. Your null reference exception may just be getting masked by On
Error Resume Next.

Hope this helps. Reply both in the group and via email if it does/doesn't
since I don't monitor this group often.
 
Back
Top