outcmd.dat and toolbar customizations in Outlook 2000

  • Thread starter Thread starter Joanne
  • Start date Start date
J

Joanne

It's generally known that Outlook 2000 clients prior to Office SP2
have a bug related to the growth of the outcmd.dat file in relation to
toolbar customizations. As many know, if the outcmd.dat file grows too
large in size, the opening of Outlook forms (such as email and contact
items) eventually becomes unbearably slow. To fix this, the outcmd.dat
file would have to be renamed or deleted, and the user would have to
install at least Office SP2, or upgrade to Outlook 2002.

I have a VB com-addin that makes heavy use of toolbar customizations:

1. I create/destroy a custom toolbar whenever an Explorer window is
opened/closed
2. I create/destroy a custom toolbar whenever an Inspector window is
opened/closed
3. I dynamically change the captions and visibility of certain menu
items in my toolbar while a user navigates through Outlook
(note: My toolbar & its controls are all created with the temporary
flag, and are all destroyed once Outlook is closed.)

It's fine and dandy that MS put out a service pack to fix this, but it
makes it rather difficult to deploy my addin to end users, partly
because not all users have Office 2K Sp2 installed, and even if they
take the time to install it, it's not fool-proof because MS asks for
SP1 (if they don't already have it), and it sometimes asks for the
original Office install disks (which the user probably doesn't have
because their installation was done through the corporate network, or
whatever). This makes it a hassle for many users to install our addin
solution, and we're trying to make it as painless as possible.

Has anyone writing such an addin found a way to get around this O2K
bug without forcing an end user install Office SP2 prior to using your
solution?

I'd appreciate any thoughts.
 
Are you using Explorer and Inspector wrapper classes and collections
as shown in the ItemsCB COM addin sample on the Resources page at
www.microeye.com?

Why create/destroy a toolbar every time an Inspector/Explorer is
opened/closed? Why not just check to see if it already exists and
reuse it?

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Lead Author, Professional Outlook 2000 Programming, Wrox Press
Lead Author, Beginning VB 6 Application Development, Wrox Press
Attachment Options
http://www.slovaktech.com/attachmentoptions.htm
Extended Reminders
http://www.slovaktech.com/extendedreminders.htm
 
Hello Ken,
I'm not the original sender of that post, but because it interests me ... :
Your suggestion is good, I use it from the beginning, but ... may you
suggest a way to remove these buttons when you uninstall the addin? I.e.
addin is installed with installshield. After first run addin creates the
buttons, and after that every time it only checks if they exists. But if you
uninstall the addin with Add/Remove programs ... the buttons have to be
removed manually.
So, the only solution I have found is to remove buttons on every close of
Inspector/Explorer and to recreate them on open. So ...?

Thanks
Sunny

Ken Slovak - said:
Are you using Explorer and Inspector wrapper classes and collections
as shown in the ItemsCB COM addin sample on the Resources page at
www.microeye.com?

Why create/destroy a toolbar every time an Inspector/Explorer is
opened/closed? Why not just check to see if it already exists and
reuse it?

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Lead Author, Professional Outlook 2000 Programming, Wrox Press
Lead Author, Beginning VB 6 Application Development, Wrox Press
Attachment Options
http://www.slovaktech.com/attachmentoptions.htm
Extended Reminders
http://www.slovaktech.com/extendedreminders.htm


Joanne said:
It's generally known that Outlook 2000 clients prior to Office SP2
have a bug related to the growth of the outcmd.dat file in relation to
toolbar customizations. As many know, if the outcmd.dat file grows too
large in size, the opening of Outlook forms (such as email and contact
items) eventually becomes unbearably slow. To fix this, the outcmd.dat
file would have to be renamed or deleted, and the user would have to
install at least Office SP2, or upgrade to Outlook 2002.

I have a VB com-addin that makes heavy use of toolbar customizations:

1. I create/destroy a custom toolbar whenever an Explorer window is
opened/closed
2. I create/destroy a custom toolbar whenever an Inspector window is
opened/closed
3. I dynamically change the captions and visibility of certain menu
items in my toolbar while a user navigates through Outlook
(note: My toolbar & its controls are all created with the temporary
flag, and are all destroyed once Outlook is closed.)

It's fine and dandy that MS put out a service pack to fix this, but it
makes it rather difficult to deploy my addin to end users, partly
because not all users have Office 2K Sp2 installed, and even if they
take the time to install it, it's not fool-proof because MS asks for
Click to expand...
SP1 (if they don't already have it), and it sometimes asks for the
original Office install disks (which the user probably doesn't have
because their installation was done through the corporate network, or
whatever). This makes it a hassle for many users to install our addin
solution, and we're trying to make it as painless as possible.

Has anyone writing such an addin found a way to get around this O2K
bug without forcing an end user install Office SP2 prior to using your
solution?

I'd appreciate any thoughts.
Click to expand...
Click to expand...
 
I did indeed pattern my addin after Randy Byrne's wonderful ItemsCB
sample. But in that sample, toolbars are NOT created as temporary. In
my addin (as an improvement, I hope), I created my toolbars and their
controls as temporary, and went about deleting them after their
respective Inspector or Explorer window is closed. I did this for
consistency to make sure I clean up everything I created, and I'm
aware that you can't quite trust the 'Temporary' parameter in Office
because it sometimes doesn't completely clean up the toolbars when
Outlook exits -- which is why (I assume) the outcmd.dat file grows and
grows.

I've found that in order to reuse my custom toolbars when new
explorer/inspector items are opened (as you've suggested), I would
have to create the toolbars with the Temporary:=False parameter. But
in many of your posts, you suggest that toolbars should be created as
temporary. I guess I just don't understand how you are able to reuse a
custom toolbar in different explorer or inspector windows if it was
created as temporary. How do you do this?

Ken Slovak - said:
Are you using Explorer and Inspector wrapper classes and collections
as shown in the ItemsCB COM addin sample on the Resources page at
www.microeye.com?

Why create/destroy a toolbar every time an Inspector/Explorer is
opened/closed? Why not just check to see if it already exists and
reuse it?

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Lead Author, Professional Outlook 2000 Programming, Wrox Press
Lead Author, Beginning VB 6 Application Development, Wrox Press
Attachment Options
http://www.slovaktech.com/attachmentoptions.htm
Extended Reminders
http://www.slovaktech.com/extendedreminders.htm


Joanne said:
It's generally known that Outlook 2000 clients prior to Office SP2
have a bug related to the growth of the outcmd.dat file in relation to
toolbar customizations. As many know, if the outcmd.dat file grows too
large in size, the opening of Outlook forms (such as email and contact
items) eventually becomes unbearably slow. To fix this, the outcmd.dat
file would have to be renamed or deleted, and the user would have to
install at least Office SP2, or upgrade to Outlook 2002.

I have a VB com-addin that makes heavy use of toolbar customizations:

1. I create/destroy a custom toolbar whenever an Explorer window is
opened/closed
2. I create/destroy a custom toolbar whenever an Inspector window is
opened/closed
3. I dynamically change the captions and visibility of certain menu
items in my toolbar while a user navigates through Outlook
(note: My toolbar & its controls are all created with the temporary
flag, and are all destroyed once Outlook is closed.)

It's fine and dandy that MS put out a service pack to fix this, but it
makes it rather difficult to deploy my addin to end users, partly
because not all users have Office 2K Sp2 installed, and even if they
take the time to install it, it's not fool-proof because MS asks for
Click to expand...
SP1 (if they don't already have it), and it sometimes asks for the
original Office install disks (which the user probably doesn't have
because their installation was done through the corporate network, or
whatever). This makes it a hassle for many users to install our addin
solution, and we're trying to make it as painless as possible.

Has anyone writing such an addin found a way to get around this O2K
bug without forcing an end user install Office SP2 prior to using your
solution?

I'd appreciate any thoughts.
Click to expand...
Click to expand...
 
Yes, creating the toolbars and buttons as .Temporary := True is the
way to go. However, I still always check for the toolbar before I
create it and as I recall so does Randy's code. Doing that and making
sure that everything is deleted when UnInitHandler is called hasn't
caused a problem here on any of my test machines with the outcmd.dat
file growing.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Lead Author, Professional Outlook 2000 Programming, Wrox Press
Lead Author, Beginning VB 6 Application Development, Wrox Press
Attachment Options
http://www.slovaktech.com/attachmentoptions.htm
Extended Reminders
http://www.slovaktech.com/extendedreminders.htm
 
I've made some interesting discoveries regarding this issue.

First off, let me start by describing the basic properties of my
custom toolbar. My toolbar contains one command bar control of type
msoControlPopup. This popup menu in turn holds other controls of type
msoControlButton and yet another msoControlPopup. My toolbar and all
its controls are created with the Temporary flag set to true, and I
explicity call the Delete method for all the toolbars/controls I
create once Outlook closes.

The problem I'm experiencing with the outcmd.dat file is that for
every instance where Outlook is opened then closed, extra lines are
added to the outcmd.dat file (comprised of some binary characters and
a discernable string: "Custom Popup 1"). The second time I open/close
Outlook, another line would appear (i.e. "Custom Popup 2"), etc,
etc... So obviously, the popup menu is not getting deleted properly
even though I'm explicitly calling the Delete method on that popup
control (in addition to the Delete method on my custom toolbar). The
temporary flag obviously has no affect here.

So I decided to take the test a little further. I modified my toolbar
creation code so that it would not add a control of type
msoControlPopup, but instead add only controls of type
msoControlButton. Guess what? Opening and closing Outlook no longer
causes the outcmd.dat file to grow with those "Custom Popup X" lines.

Is there supposed to be a proper way to delete a custom popup menu
control from my toolbar without it producing extra lines in the
outcmd.dat file? I don't know any other way other than to explicitly
call the Delete method, which I know at this point isn't working.

I'm also aware that Microsoft fixed this in O2K SP2, but I'm trying to
find a workaround for customers without SP2, because forcing them to
apply SP2 just to use my addin causes deployment headaches, not to
mention an extra nuisance for the customer.


Ken Slovak - said:
Yes, creating the toolbars and buttons as .Temporary := True is the
way to go. However, I still always check for the toolbar before I
create it and as I recall so does Randy's code. Doing that and making
sure that everything is deleted when UnInitHandler is called hasn't
caused a problem here on any of my test machines with the outcmd.dat
file growing.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Lead Author, Professional Outlook 2000 Programming, Wrox Press
Lead Author, Beginning VB 6 Application Development, Wrox Press
Attachment Options
http://www.slovaktech.com/attachmentoptions.htm
Extended Reminders
http://www.slovaktech.com/extendedreminders.htm


Joanne said:
I did indeed pattern my addin after Randy Byrne's wonderful ItemsCB
sample. But in that sample, toolbars are NOT created as temporary. In
my addin (as an improvement, I hope), I created my toolbars and their
controls as temporary, and went about deleting them after their
respective Inspector or Explorer window is closed. I did this for
consistency to make sure I clean up everything I created, and I'm
aware that you can't quite trust the 'Temporary' parameter in Office
because it sometimes doesn't completely clean up the toolbars when
Outlook exits -- which is why (I assume) the outcmd.dat file grows and
grows.

I've found that in order to reuse my custom toolbars when new
explorer/inspector items are opened (as you've suggested), I would
have to create the toolbars with the Temporary:=False parameter. But
in many of your posts, you suggest that toolbars should be created as
temporary. I guess I just don't understand how you are able to reuse a
custom toolbar in different explorer or inspector windows if it was
created as temporary. How do you do this?
Click to expand...
Click to expand...
 
Back
Top