Weird issue publishing forms

[eselk]

I have an OFT file and some code which runs from a COM add-in that
does:

1. CreateItemFromTemplete

2. Get FormDescription from the template item

3. Call PublishForm on the FormDescription, asking to publish to the
personal registry.

My code is in C++ and I use the COM objects directly at the IDispatch
level, so posting all of the code would be a mess.

PublishForm fails with error code 9 (deleted item). However, if I go
to Tools->Options->Other->Advanced, then just click the "Custom
Form..." button (I then cancel out of all screens, so I didn't make
any changes), the same code works.

My PublishForm code will also work if there is an item in the inbox
which uses that custom form (has that message class), but only if I
restart Outlook after the item is added... so I can't just fix the
issue by adding an item, then publishing my forms, because I'd have to
restart Outlook between the add and publish.

I'm able to recreate this problem on Outlook 2000 and 2003, both are
running on XP. I've recreated on 4 different PCs now.

I suspect Outlook loads something when I go into the custom forms
options, or open an item which uses custom forms, something which must
be loaded before PublishForm will succeed. Any ideas what that could
be, and how I can force Outlook to do that in my code?

 

[eselk]

Incase it helps, I translated my code into VBA and was able to
recreate the exact same problem:

Sub duh()
Dim i As Object
Set i = Application.CreateItemFromTemplate("c:\somefile.oft")
Dim fd As FormDescription
Set fd = i.FormDescription
fd.PublishForm olPersonalRegistry
End Sub

From VBA in Outlook I run that sub. When it gets to the last line

(PublishForm) it fails with "Internal Application Error". If I just
open the Custom Forms area from Tools->Options, then run the same
function again, it works. I can then restart Outlook and the function
fails again, until I go into the options, then it works again.

I tried a detect and repair and also reinstalled Outlook on 2 of the 4
PCs I'm having this problem on, but no change.

 

[Ken Slovak - [MVP - Outlook]]

See if it works any better if you set the Name and DisplayName properties of
the form before you publish it. I also generally add an item to a folder of
that type and set the MessageClass of the added item to the MessageClass of
the custom form and then delete or don't save the item to cache the form.

 

[eselk]

See if it works any better if you set the Name and DisplayName properties of
the form before you publish it. I also generally add an item to a folder of
that type and set the MessageClass of the added item to the MessageClass of
the custom form and then delete or don't save the item to cache the form.

Tried setting the Name (I'll try DisplayName today and let you know if
it works), and also copied some sample code from MSDN:

http://msdn2.microsoft.com/en-us/library/aa613050(office.10).aspx

------
Set myOlApp = CreateObject("Outlook.Application")
Set myItem = myOlApp.CreateItem(olAppointmentItem)
Set myForm = myItem.FormDescription
myForm.Name = "Interview Scheduler"
myForm.PublishForm olPersonalRegistry
-------

Even that fails with the same error at PublishForm, but then I go into
the Custom Forms from Tools->Options, and right after that it works
(same as my real code).

I applied all of the service updates for the Outlook 2000 and 2003 PCs
that are having the problem, but that didn't help.

Maybe I'll try a complete uninstall, then install, instead of just an
in-place reinstall. I've tried creating new PST files. I'll probably
also try creating a new user on the PC, since a lot of registry keys
and app data is per user/profile. Really weird problem, I was really
surprised that I was able to recreate on over half the PCs in the
office, but it could be that we all installed some other software
(like anti-virus) that caused the problem. I did try turning off the
anti-virus (Avast) also, and all other add-ons.

My real code actually does something like I think you do. It creates
an item (using Add to the default inbox items collection) using my
message class, then gets the form description to see if my custom
forms are already published, then publish if they aren't (my add-on
does that at startup everytime it loads, to make sure forms are always
published). The call to Add also fails with the same error code.
However, the code that I actually use to dump messages into the inbox
uses MAPI, and that code doesn't fail. But even after that code adds
some messages, I still can't publish my forms (unless I open the
message, or go to the custom forms options, in both cases I think that
is when Outlook initializes something so I can publish forms after
that point).

 

[eselk]

Looks like it is something my add-in is doing at startup which is
causing the weird issues. I disabled my add-in, and now I can't
recreate the error with the VBA script. Thanks for the help anyway,
but now that I know it is something I'm doing at startup, should be
easy enough to comment out code until I find the problem -- and
hopefully easy to fix without a major design change.

 

[eselk]

Looks like it is something my add-in is doing at startup which is
causing the weird issues. I disabled my add-in, and now I can't
recreate the error with the VBA script. Thanks for the help anyway,
but now that I know it is something I'm doing at startup, should be
easy enough to comment out code until I find the problem -- and
hopefully easy to fix without a major design change.

And incase anyone was wondering... I was calling SetDllDirectory
(Win32 API function) when my add-in loads, which was causing the
problem. I added that call because my add-in DLL used delay-loading
to load some other DLLs which where in the same folder as my add-in
DLL, and under Vista Microsoft changed the DLL loading so it no longer
looks in the same folder as the DLL itself. Anyway, I'll probably
just call SetDLLDirectory again to set it back to the previous folder
after I load my DLLs (and I can't just specify a path for loading my
DLLs, because the real problem is that those DLLs are linked to other
DLLs).

Outlook loads OUTEX.DLL during the PublishForm call, which fails if
I've changed the DLL path using SetDLLDirectory. But I guess when you
go into the custom form options they must load OUTEX.DLL using a
different method than when I call PublishForm, so in that case they
can load OUTEX.DLL, then after that PublishForm works. So another
option would be for me to load OUTEX.DLL before calling
SetDLLDirectory, but I'm better off just not calling SetDLLDirectory
(or at least setting it back before I return) so that any other DLLs
will not have issues as well.