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

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.

--
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" wrote:

> 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] 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

>> 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 | Advanced Options | 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

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 - B.A, MCP, MCSD, Outlook MVP
--------------------------------------------------
{Private e-mails ignored}
Job: http://www.imaginets.com
Blog: http://blogs.officezealot.com/legault/

"Sriram N A" wrote:

> 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
>
> >> 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 | Advanced Options | 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
>
>
>

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]" <(E-Mail Removed)> wrote in
message news:6F0E4C34-45ED-4F08-A896-(E-Mail Removed)...
> 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?

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/

"Sriram N A" wrote:

> 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]" <(E-Mail Removed)> wrote in
> message news:6F0E4C34-45ED-4F08-A896-(E-Mail Removed)...
> > 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?
>
>
>

"Eric Legault [MVP - Outlook]" wrote in message
news:008AE792-DE4E-41FE-B79C-(E-Mail Removed)...
> 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.

> 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.

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.

--
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" wrote:

>
> "Eric Legault [MVP - Outlook]" wrote in message
> news:008AE792-DE4E-41FE-B79C-(E-Mail Removed)...
> > 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.
>
> > 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.
>
>
>

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

As for the "Eric Legault [MVP - Outlook]" <(E-Mail Removed)>
wrote in message newsC74969F-21E2-413A-B855-(E-Mail Removed)...
> 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.

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...B;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" wrote:

> 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
>
> As for the "Eric Legault [MVP - Outlook]" <(E-Mail Removed)>
> wrote in message newsC74969F-21E2-413A-B855-(E-Mail Removed)...
> > 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.
>
>
>