Copy form definition in PF to personal forms registry

[Sriram N A]

I need to have a form which has been published to a public folder copied to
the user's personal forms registry in script.

I am trying to use an "Install" form published to a suitable public folder
for this, so that the form definition of the form to be run is copied to the
local registry, and can be taken offline.

Code along the following lines will not do, because the Add method results
in execution of code in the form being installed. Is there any way of
programmatically replicating what is achieved in Outlook through Tools |
Options | Other | Custom Forms | Manage Forms | Set | Copy?

Set objItem = objFolder.Items.Add(strMsgClass) '<==Executes code in
objItem
Set objFormDescription = objItem.FormDescription
objFormDescription.Name = "Indent"
objFormDescription.PublishForm olPersonalRegistry
objItem.Close olDiscard

Sriram

 

[Eric Legault [MVP - Outlook]]

Unfortunately there is no way to "cleanly" bypass code in a form when it is
opened. In the UI you can get around this by holding down Shift when you
open the form.

What you can do is set a value in the field on the form before you call the
Display method, and check its value in the Item_Open event. If it is not
empty for example, you can exit the event and bypass any other code that
might fire. Note that setting field values will cause the PropertyChange and
CustomPropertyChange events to fire as well.

Otherwise, a better approach to providing access to a form while Offline is
to add the Public Folder to the user's Public Folders\Favorites folder. They
can access all of the items and custom forms published in that folder while
working in Offline mode (provided that Offline mode and Public Folder
Favorites access is enabled via the Advanced tab in the profile settings
pages for the Exchange profile).

BTW, there is a microsoft.public.outlook.program_forms newsgroup dedicated
to these topics.

 

[Sriram N A]

Unfortunately there is no way to "cleanly" bypass code in a form when
it is opened. In the UI you can get around this by holding down
Shift when you open the form.

Well, I would like to avoid opening the form being published at all, if that
is possible. The only reason for invoking the Add method is to instantiate
an Item of the appropriate message class, so that a FormDescription object
can be obtained.

Therefore:
Is there any way to get to the FormDescription of a published form without
calling the Add method?

Sriram

 

[Eric Legault [MVP - Outlook]]

If you have an existing item based on your custom form, you can set a
reference to that item in order to obtain the FormDescription object without
having to create a new item based on an instance of that form.

However, this item may be populated with new data and you may not want to
publish the form associated with this item, as it would differ from the
original.

 

[Sriram N A]

As I understand it, one can get a handle on the published form using the
hidden messages collection in CDO. Any chance of using this object
reference to publish the form? I think not, since there is no Publish
method in CDO...

Sriram

 

[Eric Legault [MVP - Outlook]]

Correct. And you can't copy the hidden message nor recreate them to "fake"
publishing the form.

What I don't understand about your requirements is why this needs to be
automated. Are there any hard obstacles to publishing the form manually or
distributing the form inside a .pst file?

As I said before, if your intent is to enable a public folder form for
offline use, have the users publish the folder to Public Folder\Favorites and
you don't need to write any code whatsoever.

--
Eric Legault - B.A, MCP, MCSD, Outlook MVP
--------------------------------------------------
{Private e-mails ignored}
Job: http://www.imaginets.com
Blog: http://blogs.officezealot.com/legault/

As I understand it, one can get a handle on the published form using the
hidden messages collection in CDO. Any chance of using this object
reference to publish the form? I think not, since there is no Publish
method in CDO...

Sriram

If you have an existing item based on your custom form, you can set a
reference to that item in order to obtain the FormDescription object without
having to create a new item based on an instance of that form.

However, this item may be populated with new data and you may not want to
publish the form associated with this item, as it would differ from the
original.

--

Eric Legault [MVP - Outlook] wrote:
Unfortunately there is no way to "cleanly" bypass code in a form when
it is opened. In the UI you can get around this by holding down
Shift when you open the form.

Well, I would like to avoid opening the form being published at all, if that
is possible. The only reason for invoking the Add method is to instantiate
an Item of the appropriate message class, so that a FormDescription object
can be obtained.

Therefore:
Is there any way to get to the FormDescription of a published form without
calling the Add method?

 

[Sriram N A]

in message

What I don't understand about your requirements is why this needs to be
automated. Are there any hard obstacles to publishing the form manually or
distributing the form inside a .pst file?

The actual problem:
The form (an IPM.Note form) is published to a public folder, and can be
launched from a hyperlink on a web page by the indenter.

Scripting on the Exchange server is disallowed. So the form was designed
(years ago) to work its routing magic through script inside the form. Since
it is an email, it depended on the caching fulctionality of Outlook forms to
render it correctly on the Approver's PC. This worked very well, since any
updates to the centrally published form immediately "took" on all PCs.

With folder-specific forms in Outlook 2003, this functionality is now
broken. The received email form will not open on the approver's machine
unless the form definition is published to the personal forms registry.
This is the requirement. The offline usage requirement is only incidental,
with the increasing number of people working offline.

 

[Eric Legault [MVP - Outlook]]

Ah, I see. Then you need to publish the form to the Organization Forms
library. See this link for more info:

Saving and Publishing Microsoft Outlook Custom Forms:
http://www.outlookcode.com/d/formpub.htm

BTW, the ability to publish forms in a folder library was not introduced
with OL2003; this is functionality related to Exchange that has been present
since Exchange 5.5.

 

[Sriram N A]

The application as originally designed used the fact that a form definition
was cached automatically when a form published to a public folder was
accessed. Any email subsequently received with the same message class would
be rendered using the cached form definition.

Since Outlook 2003 uses a folder-specific forms cache, using this trick to
render the received email form no longer works. Therefore the only
workaround appears to be to cache the folder form definition in the personal
forms registry.

Publishing to the Organizational Forms Library is not an option.

Sriram

 

[Eric Legault [MVP - Outlook]]

Okay, I now understand that you are experiencing some issues as outlined in
this KB article:

How to use the Outlook 2003 forms cache and to troubleshoot forms cache
problems:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;839804

Does this problem remain if you install Office 2003 SP1?

--
Eric Legault - B.A, MCP, MCSD, Outlook MVP
--------------------------------------------------
{Private e-mails ignored}
Job: http://www.imaginets.com
Blog: http://blogs.officezealot.com/legault/

 

[Sriram N A]

The problem persists after installing SP1.

I understand there is a change in the way the forms cache is used.

Let's say there's a form IPM.Note.Indent published to a public folder. The
indenter launches the form through a web page outlook:// URL, fills it out,
and sends it *by email* to the approver.

In Outlook 2000, the form used to display correctly if the approver had
accessed the public folder version of the form at any time, since the form
definition would have been cached.

Now in Outlook 2003, this does not work, since the cached version of the
form is not used to render the email. I understand this is because changes
have been made in order to cache folder-specific form versions; the cached
form is _not_ reused to display email forms.

The only workaround is to publish to the Org. Forms Lib, or failing that, to
the Personal Forms registry.

The latter is the only option I have. There is one obvious disadvantage -
the form definition no longer gets updated on the approver's machine
following changes to the public folder version - but I have no choice now.

Unfortunately, there does not appear to be a simple method of publishing the
form definition to the personal forms registry without a multi-step user
intervention.

 

[Eric Legault [MVP - Outlook]]

Going back a little in our thread, have we now ruled out creating a new
instance of a form and publishing it to the Personal Forms library? When the
Item_Open or other events fire, what is the code doing? Is it possible to
redesign the form to remove this code, or alter it so that it doesn't do
anything undesirable?

BTW, Item_Open doesn't fire until you call the Display method for that item.
If there is code in that event that you want to bypass, set a custom field
to some value (e.g. MyCustomField = True) after you create an instance of the
form in your calling application, and check for an expected value in that
field during Item_Open; if is true for example, exit the procedure before
running any more code.

 

[Sriram N A]

Going back a little in our thread, have we now ruled out creating a new
instance of a form and publishing it to the Personal Forms library? When the
Item_Open or other events fire, what is the code doing? Is it possible to
redesign the form to remove this code, or alter it so that it doesn't do
anything undesirable?

I guess that's what I'm going to do now.

I was just checking whether I could avoid diddling with the form in any way,
because of the likelihood of introducing errors.

Thanks for the inputs.

Sriram