In summary, I can have no preview with the custom form, or preview with the
regular form. This isn't ideal.

That's all you get unless you move to Outlook 2007 or use a third-party tool (http://www.add-in-express.com/outlook-extension/).
--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx

"Geoff" wrote in message ...
Many thanks for your reply and continued support.

When you designed the form, did you click the Edit Read Layout button and
create a read layout showing your custom fields?

I thought that I had. But to confirm, I have opened my custom form in
design view and I have clicked the "Edit Read Page" and "Edit Compose Page"
buttons. The layout is the same on both pages.

Therefore, I have composed a new custom form with same user-defined fields
and with different layouts for the compose and read pages. This is how a
Post Item behaves when it's created with the new custom form - when there
is, and isn't, a registry string value for the new custom form in:

HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\O utlook\Custom
Forms\Preview

1. Without a registry string value, the Post Item did not display in the
Preview Pane because of its "active content". When the Post Item was
opened, it displayed in the "Read" page layout of the new custom form. When
I then opened the Edit menu and selected Revise Contents, it displayed in
the "Compose" page layout of the custom form.

2. With a registry string value, the Post Item did display in the Preview
Pane. However, when the Post item was opened, it displayed in the regular
Post Item form. And when I then opened the Edit menu and selected Revise
Contents, it continued to be displayed in the regular Post item form.

In summary, I can have no preview with the custom form, or preview with the
regular form. This isn't ideal.

If there is a way round this, that'd be good.

Otherwise, do you think this behaviour is isolated to Outlook 2002? I'm
wondering if, when I distribute the pst file containing the post items
(which is a repository of archive information), I shall need to write a
program to edit the registry on user machines. I'd rather not. I'd prefer
an easier way forward.

That's exactly what you'd see if the item used the regular Post form.
That's the way it's designed to work.

I thought that must be the case.

If you have any further thoughts, they'd be very welcome.

Best regards
Geoff



"Sue Mosher [MVP-Outlook]" wrote in message
...
After posting the Post Item, only the Subject and Bodytext fields appeared
in the Preview Pane. (It would be nice if the other fields appeared too,
but
it's not the end of the world because the custom fields can be still be
seen
in the list of Post Items above the Preview Pane.)

That's exactly what you'd see if the item used the regular Post form. That's
the way it's designed to work.

What's of more concern is that when I now open the custom Post Item, it
shows in the regular Post Item form. Also, if I then open the Edit menu
and
select Revise Contents, it remains in the regular Post Item form. This
means the user does not have access to the custom fields, should they need
to be revised.

When you designed the form, did you click the Edit Read Layout button and
create a read layout showing your custom fields?

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx

Very many thanks for seeing me through this.

On reflection after my last post, I felt that the registry fix wasn't
appropriate. In effect, it seems the registry fix overrides the Post Item's
MessageClass property (if that has been set to display the Post Item in a
custom form) so that the Post Item displays in the regular form. The
(rhetorical) question then arises, why bother to set the MessageClass
property in the first place?

Many thanks for helping me see the trade-offs in Outlook 2002 and for the
tip about Outlook 2007.

Incidentally, your "Jumpstart" book has been a great help in the past. I
have long since adopted your convention of the "obj" prefix in all my Access
coding. It is so sensible from a number of points of view.

Many thanks again - over and out!
Best regards
Geoff




"Sue Mosher [MVP-Outlook]" wrote in message
...
In summary, I can have no preview with the custom form, or preview with
the
regular form. This isn't ideal.

That's all you get unless you move to Outlook 2007 or use a third-party tool
(http://www.add-in-express.com/outlook-extension/).
--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx

"Geoff" wrote in message
...
Many thanks for your reply and continued support.

When you designed the form, did you click the Edit Read Layout button and
create a read layout showing your custom fields?

I thought that I had. But to confirm, I have opened my custom form in
design view and I have clicked the "Edit Read Page" and "Edit Compose
Page"
buttons. The layout is the same on both pages.

Therefore, I have composed a new custom form with same user-defined fields
and with different layouts for the compose and read pages. This is how a
Post Item behaves when it's created with the new custom form - when there
is, and isn't, a registry string value for the new custom form in:

HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\O utlook\Custom
Forms\Preview

1. Without a registry string value, the Post Item did not display in
the
Preview Pane because of its "active content". When the Post Item was
opened, it displayed in the "Read" page layout of the new custom form.
When
I then opened the Edit menu and selected Revise Contents, it displayed in
the "Compose" page layout of the custom form.

2. With a registry string value, the Post Item did display in the
Preview
Pane. However, when the Post item was opened, it displayed in the regular
Post Item form. And when I then opened the Edit menu and selected Revise
Contents, it continued to be displayed in the regular Post item form.

In summary, I can have no preview with the custom form, or preview with
the
regular form. This isn't ideal.

If there is a way round this, that'd be good.

Otherwise, do you think this behaviour is isolated to Outlook 2002? I'm
wondering if, when I distribute the pst file containing the post items
(which is a repository of archive information), I shall need to write a
program to edit the registry on user machines. I'd rather not. I'd
prefer
an easier way forward.

That's exactly what you'd see if the item used the regular Post form.
That's the way it's designed to work.

I thought that must be the case.

If you have any further thoughts, they'd be very welcome.

Best regards
Geoff



"Sue Mosher [MVP-Outlook]" wrote in message
...
After posting the Post Item, only the Subject and Bodytext fields
appeared
in the Preview Pane. (It would be nice if the other fields appeared too,
but
it's not the end of the world because the custom fields can be still be
seen
in the list of Post Items above the Preview Pane.)

That's exactly what you'd see if the item used the regular Post form.
That's
the way it's designed to work.

What's of more concern is that when I now open the custom Post Item, it
shows in the regular Post Item form. Also, if I then open the Edit menu
and
select Revise Contents, it remains in the regular Post Item form. This
means the user does not have access to the custom fields, should they
need
to be revised.

When you designed the form, did you click the Edit Read Layout button and
create a read layout showing your custom fields?

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx

I don't think the registry fix has anything to do with the message class. It just allows custom forms to show in the preview pane.
--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx

"Geoff" wrote in message ...
Very many thanks for seeing me through this.

On reflection after my last post, I felt that the registry fix wasn't
appropriate. In effect, it seems the registry fix overrides the Post Item's
MessageClass property (if that has been set to display the Post Item in a
custom form) so that the Post Item displays in the regular form. The
(rhetorical) question then arises, why bother to set the MessageClass
property in the first place?

I thought the behaviour I experienced (described in two posts back) seemed
to indicate that the registry fix did more than just allow the custom form
to display in the Preview Pane. When the registry fix was in place, the
Post Item that would otherwise display in the custom form did then display
in the Preview Pane, but it also reverted to opening in the regular Post
Item form (when it was opened) and, perhaps as might be expected, in the
regular Post Item form when then being revised. In other words, the
registry fix seemed to be having the effect of saying, if an item is
supposed to be opened and revised in the custom form, then override that
setting and preview, open and revise it in the regular form instead - ie the
registry fix does not just cause the Post Item to be displayed it in the
Preview Pane. I interpreted that as meaning that the registry fix was
overriding the MessageClass property since that property (as I understand
it) forces the Post Item to be opened and revised in the custom form. This
does seem odd because the registry fix implies it would only affect the
preview behaviour (since the new string value is in the Preview key).

In one sense, it doesn't matter too much because (as I understand it)
whichever route I take, I cannot get the behaviour I want from Outlook
2002 - which is to be able to preview, open and edit a Post Item using a
custom form.

Best regards
Geoff




"Sue Mosher [MVP-Outlook]" wrote in message
...
I don't think the registry fix has anything to do with the message class. It
just allows custom forms to show in the preview pane.
--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx

"Geoff" wrote in message
...
Very many thanks for seeing me through this.

On reflection after my last post, I felt that the registry fix wasn't
appropriate. In effect, it seems the registry fix overrides the Post
Item's
MessageClass property (if that has been set to display the Post Item in a
custom form) so that the Post Item displays in the regular form. The
(rhetorical) question then arises, why bother to set the MessageClass
property in the first place?