Merging From Outlook 2003 Using Form or Folder Level Fields

[SRM]

I'm using Outlook 2003 and using a custom form. In this custom form I
have the same item level fields as I do in the form level fields. I
have no folder level fields.

I want to be able to merge starting with Outlook and selecting a Word
document to merge into.

The only way I can see that this will work is with folder level
fields. Word does not see item level fields nor does it see form level
fields for merging. Am I correct in this assumption?

What I think I need to do is for each form level field I need to
create the equivalent folder level field. Basically duplicating each
field at the folder level that I already have at the form level. Is
there a better option?

The fields that I had already created based off the original contact
form (via the form designer) appear in the form and item level fields,
but not the folder level fields. However, if I add a new field using
the form designer (basically modify the form), that field by default
ends up as a folder level field and not a form level field. It seems
the results differ based on when you add the field which I can't
figure out why.

So my questions are why do fields appear in different levels based on
when they are added, and is there any way to get the form levels
fields to also be folder level fields without recreating them?

Thanks

Shawn

 

[Ken Slovak - [MVP - Outlook]]

The pre-programmed merges started from Word or from Outlook will not use
custom fields. For that you need to completely program the merge yourself
using code. That's the way it's always been.

For an explanation of form fields and where they are located and what
effects that has look at the forms information at www.outlookcode.com.

 

[SRM]

The pre-programmed merges started from Word or from Outlook will not use
custom fields. For that you need to completely program the merge yourself
using code. That's the way it's always been.

For an explanation of form fields and where they are located and what
effects that has look at the forms information atwww.outlookcode.com.

Ken:

Thanks. When I have fields at the folder level, Word does see those
custom fields (at the folder level) for a merge. I have added those
custom fields to my Word file to complete merges. I have been using
this format but recently had to update my PST file and lost all my
folder level fields. Am I miss-understanding your reply?

Concerning the fields, I have read through Sue's book and reviewed the
site. Unless I just plain missed it, I cannot find answers to the
questions I posted in those locations.

Thanks again for your help.

 

[Karl Timmermans]

After going back and forth on this with Shawn regarding an issue of
"deleted" fields in a prior thread - finally nailed the exact "anomaly"
where a newly added field is accessible in a merge. Going to provide the
step-by-step details if any one cares to replicate (everything that follows
was done in O'2007)

Part 1
------------------------------------------------------
- New contact folder created
- Custom form (used one provided by Shawn but any will do) published to
Pers Lib (only because it was going to be used in multiple folders)
- Custom form made default for folder
- New contact created
- No UDFs listed in Folder group (as expected)

*** Mail-merge started from Outlook - no custom fields accessible (as
expected)
------------------------------------------------------

Part 2
------------------------------------------------------
- In the same folder - design custom form
- Added a new field to the custom form
- Re-Publish the form
- New field is added to the "UDFs in Folder Group" (not expected)
- New field does NOT appear in form field list in field chooser during
design but under the surface - the field has been added to the custom form

*** Mail-merge started from Outlook - new field is accessible in merge
because it was added to the Folder list during the custom form design
process - no other custom form user-defined fields are accessible that were
part of the original form

What seems to be happening is that when the form is being designed and a
field is being added, in O'2007 it gets added to the Folder Group in the
same way that a field gets added to a standard contact item (IPM.Contact)
------------------------------------------------------

Part 3
------------------------------------------------------
- Create another new contact folder
- Make the same form (with the added field from Part 2) the default for the
folder
- No user-defined fields from the custom form appear in the folder list (as
expected)
- Custom form shows all fields including newly added one in Field Chooser
(as expected)

*** No user-defined fields accessible via Mail merge started from Outlook
(as expected)
------------------------------------------------------

Part 4 - Beyond Mail-Merge
------------------------------------------------------
- Create yet another new contact folder and make the custom form the
default
- Create 2 contacts using this form
- Change the value of one of the user-defined form fields in each contact
(same field for each contact)
- Change the default message class for the folder to IPM.Contact
- Change the message class for the 2 contact items to IPM.Contact
- Add a user-defined field to the item using the same user-defined field
name as used in the custom form
- The field will be added to the Folder List group (expected)
- Open each contact item separately and review the UDF in Folder group -
you will find that the value for this field is the value entered in the
custom form but the field does not appear in the "User-defined fields in
this item" list. Exporting this UDF field will show the correct value for
each contact
- Change the value of the Folder Group UDF and the field then gets added to
the "UDF in this item" list (as expected)

*** Mail-merge started in Outlook will pick up fields added to the Folder
Group
-------------------------------------------------------

There are many more parts to this but the rest go beyond this topic.The
results can be summarily described as "Let's count the ways" that Outlook
data can get (or APPEAR to get) messed up especially once you include
moving items from one location to another, adding identical user-defined
field names with different properties, repeatedly adding/deleting fields
etc etc.

Or to get back to the original question - when using a custom form in a
folder and you want to make user-defined fields accessible to a mail-merge
started in Outlook - just add the desired fields to the folder group - only
need to do that once for the entire folder with the single most important
thing to remember - when using a custom form - "new fields" should ALWAYS
be added via the custom form designer and not directly to the folder group.

Karl
--
____________________________________________________________
Karl Timmermans - The Claxton Group
ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
"Contact import/export/data management tools for Outlook '2000/2010"
http://www.contactgenie.com

 

[SRM]

After going back and forth on this with Shawn regarding an issue of
"deleted" fields in a prior thread - finally nailed the exact "anomaly"
where a newly added field is accessible in a merge. Going to provide the
step-by-step details if any one cares to replicate (everything that follows
was done in O'2007)

Part 1
------------------------------------------------------
- New contact folder created
- Custom form (used one provided by Shawn but any will do) published to
Pers Lib (only because it was going to be used in multiple folders)
- Custom form made default for folder
- New contact created
- No UDFs listed in Folder group (as expected)

*** Mail-merge started from Outlook - no custom fields accessible (as
expected)
------------------------------------------------------

Part 2
------------------------------------------------------
- In the same folder - design custom form
- Added a new field to the custom form
- Re-Publish the form
- New field is added to the "UDFs in Folder Group" (not expected)
- New field does NOT appear in form field list in field chooser during
design but under the surface - the field has been added to the custom form

*** Mail-merge started from Outlook - new field is accessible in merge
because it was added to the Folder list during the custom form design
process - no other custom form user-defined fields are accessible that were
part of the original form

What seems to be happening is that when the form is being designed and a
field is being added, in O'2007 it gets added to the Folder Group in the
same way that a field gets added to a standard contact item (IPM.Contact)
------------------------------------------------------

Part 3
------------------------------------------------------
- Create another new contact folder
- Make the same form (with the added field from Part 2) the default for the
folder
- No user-defined fields from the custom form appear in the folder list (as
expected)
- Custom form shows all fields including newly added one in Field Chooser
(as expected)

*** No user-defined fields accessible via Mail merge started from Outlook
(as expected)
------------------------------------------------------

Part 4 - Beyond Mail-Merge
------------------------------------------------------
- Create yet another new contact folder and make the custom form the
default
- Create 2 contacts using this form
- Change the value of one of the user-defined form fields in each contact
(same field for each contact)
- Change the default message class for the folder to IPM.Contact
- Change the message class for the 2 contact items to IPM.Contact
- Add a user-defined field to the item using the same user-defined field
name as used in the custom form
- The field will be added to the Folder List group (expected)
- Open each contact item separately and review the UDF in Folder group -
you will find that the value for this field is the value entered in the
custom form but the field does not appear in the "User-defined fields in
this item" list. Exporting this UDF field will show the correct value for
each contact
- Change the value of the Folder Group UDF and the field then gets added to
the "UDF in this item" list (as expected)

*** Mail-merge started in Outlook will pick up fields added to the Folder
Group
-------------------------------------------------------

There are many more parts to this but the rest go beyond this topic.The
results can be summarily described as "Let's count the ways" that Outlook
data can get (or APPEAR to get) messed up especially once you include
moving items from one location to another, adding identical user-defined
field names with different properties, repeatedly adding/deleting fields
etc etc.

Or to get back to the original question - when using a custom form in a
folder and you want to make user-defined fields accessible to a mail-merge
started in Outlook - just add the desired fields to the folder group - only
need to do that once for the entire folder with the single most important
thing to remember - when using a custom form - "new fields" should ALWAYS
be added via the custom form designer and not directly to the folder group.

Karl
--
____________________________________________________________
Karl Timmermans - The Claxton Group
ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
"Contact import/export/data management tools for Outlook '2000/2010"http://www.contactgenie.com

Karl:

Thanks so much for this reply and time. Had a few questions (but I'm
guessing you expected that - smile) !!!

For my custom form in which the fields are currently only at the
form / item level, how do I get them to the folder level? You noted
the following:

- Add a user-defined field to the item using the same user-defined
field name as used in the custom form
- The field will be added to the Folder List group (expected)

One of my custom fields is called "Announcements" that is only at the
form level / item level. I go to the form designer. I go to the "All
Fields" tab / User-defined fields in this item. I click New and enter
"Announcements". By default, Outlook takes me to the User-defined
fields in folder and adds the field at that location. That new field
is now available in the User-defined fields in folder listing, in the
Field Chooser, and Control Toolbox / Properties / Choose Field.

I also tried adding the field via first the Field Chooser and then the
Control Toolbox and the results are all the same.

At this point, do I now have two fields called "Announcements" or is
it the same field in two locations? The data in the field is reflected
the same.

So am I correct in stating if I have a field only at the form / item
level and I need the field to merge with Word, I need to recreate the
field at the folder level using one of the above steps?

Also, since I have multiple contact folders, I should update my
contact folder and then copy the contact folder. If I just create a
new contact folder, I will need to recreate all the folder level
fields again for that new contact folder at the folder level. Correct?

Lastly, any idea when creating a new form and adding fields they only
appear at the form level, however, if you modify a form, add a new
field it appears at the folder level and as you stated -- "but under
the surface - the field has been added to the custom form."

Shawn

 

[Karl Timmermans]

If you contact folder is using a custom form AND you want to use one or
more of the user-defined fields in a merge then

#1 - Make sure you write down the "exact" user-defined field names used in
the custom form (field names not case-sensitive for this purpose)

#2 - DO NOT use the form designer for the rest of this - if you do - you
are altering the structure/contents of the custom form (adding a UDF to an
item is not the same as adding a UDF to a form which adds the UDF
for ALL items). The result will appear to be the same in terms of the
field being added to the Folder list but not completely sure of what the
implications are "under the surface" for the UserProperty collection
(which really becomes something of interest at the programmatic level
versus the UI level).

#3 - Open any contact in the folder - add the user-defined field desired -
these will be automatically add to the Folder list if you do nothing else
(just as if you add a UDF to a contact that uses IPM.Contact (standard
form) - make sure all the properties are the same for each field added
#4 - close your contact - the folder list of fields has what you want for
the merge

The above is specific to a given folder. Rinse and repeat the exact steps
for each and every folder in question.

As stated originally, start moving items depending on what and how things
were done to a folder can result in different behaviours BUT
- #1 - creating a new folder,
- #2 - assigning it the cutom form as the default and
- #3 - copying contacts from another folder created with the same form
will retain all data but the target folder will not have any "Folder
Fields" until you repeat the above steps for the new folder.

For those that need to deal with multiple versions of Outlook in a given
custom solution where UDF names are "dynamically" determined/extracted
at run-time versus being "hard coded" into the solution, as is the case in
most code snip examples - strongly recommend using a reasonably current
version of Redemption (http://www.dimastr.com) and potentially save untold
hours of misery. The last time OOM and Redemption (RDO) items were used
in the same ContactGenie solution (years ago) - Redemption proved more
reliable/easier to deal with than what was returned by OOM when it came
to user-defined fields (depending of course on how exactly the user
properties were created and how the UserProperty collection was accessed
for an OOM item). As Shawn has come to find out via a 3rd party export tool
being used - an erroneous set of "current" user-defined fields can get
reported as a result.

Karl

--
____________________________________________________________
Karl Timmermans - The Claxton Group
ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
"Contact import/export/data management tools for Outlook '2000/2010"
http://www.contactgenie.com

After going back and forth on this with Shawn regarding an issue of
"deleted" fields in a prior thread - finally nailed the exact "anomaly"
where a newly added field is accessible in a merge. Going to provide the
step-by-step details if any one cares to replicate (everything that
follows
was done in O'2007)

Part 1
------------------------------------------------------
- New contact folder created
- Custom form (used one provided by Shawn but any will do) published to
Pers Lib (only because it was going to be used in multiple folders)
- Custom form made default for folder
- New contact created
- No UDFs listed in Folder group (as expected)

*** Mail-merge started from Outlook - no custom fields accessible (as
expected)
------------------------------------------------------

Part 2
------------------------------------------------------
- In the same folder - design custom form
- Added a new field to the custom form
- Re-Publish the form
- New field is added to the "UDFs in Folder Group" (not expected)
- New field does NOT appear in form field list in field chooser during
design but under the surface - the field has been added to the custom
form

*** Mail-merge started from Outlook - new field is accessible in merge
because it was added to the Folder list during the custom form design
process - no other custom form user-defined fields are accessible that
were
part of the original form

What seems to be happening is that when the form is being designed and a
field is being added, in O'2007 it gets added to the Folder Group in the
same way that a field gets added to a standard contact item (IPM.Contact)
------------------------------------------------------

Part 3
------------------------------------------------------
- Create another new contact folder
- Make the same form (with the added field from Part 2) the default for
the
folder
- No user-defined fields from the custom form appear in the folder list
(as
expected)
- Custom form shows all fields including newly added one in Field Chooser
(as expected)

*** No user-defined fields accessible via Mail merge started from Outlook
(as expected)
------------------------------------------------------

Part 4 - Beyond Mail-Merge
------------------------------------------------------
- Create yet another new contact folder and make the custom form the
default
- Create 2 contacts using this form
- Change the value of one of the user-defined form fields in each contact
(same field for each contact)
- Change the default message class for the folder to IPM.Contact
- Change the message class for the 2 contact items to IPM.Contact
- Add a user-defined field to the item using the same user-defined field
name as used in the custom form
- The field will be added to the Folder List group (expected)
- Open each contact item separately and review the UDF in Folder group -
you will find that the value for this field is the value entered in the
custom form but the field does not appear in the "User-defined fields in
this item" list. Exporting this UDF field will show the correct value for
each contact
- Change the value of the Folder Group UDF and the field then gets added
to
the "UDF in this item" list (as expected)

*** Mail-merge started in Outlook will pick up fields added to the Folder
Group
-------------------------------------------------------

There are many more parts to this but the rest go beyond this topic.The
results can be summarily described as "Let's count the ways" that Outlook
data can get (or APPEAR to get) messed up especially once you include
moving items from one location to another, adding identical user-defined
field names with different properties, repeatedly adding/deleting fields
etc etc.

Or to get back to the original question - when using a custom form in a
folder and you want to make user-defined fields accessible to a
mail-merge
started in Outlook - just add the desired fields to the folder group -
only
need to do that once for the entire folder with the single most important
thing to remember - when using a custom form - "new fields" should ALWAYS
be added via the custom form designer and not directly to the folder
group.

Karl
--
____________________________________________________________
Karl Timmermans - The Claxton Group
ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
"Contact import/export/data management tools for Outlook
'2000/2010"http://www.contactgenie.com

Karl:

Thanks so much for this reply and time. Had a few questions (but I'm
guessing you expected that - smile) !!!

For my custom form in which the fields are currently only at the
form / item level, how do I get them to the folder level? You noted
the following:

- Add a user-defined field to the item using the same user-defined
field name as used in the custom form
- The field will be added to the Folder List group (expected)

One of my custom fields is called "Announcements" that is only at the
form level / item level. I go to the form designer. I go to the "All
Fields" tab / User-defined fields in this item. I click New and enter
"Announcements". By default, Outlook takes me to the User-defined
fields in folder and adds the field at that location. That new field
is now available in the User-defined fields in folder listing, in the
Field Chooser, and Control Toolbox / Properties / Choose Field.

I also tried adding the field via first the Field Chooser and then the
Control Toolbox and the results are all the same.

At this point, do I now have two fields called "Announcements" or is
it the same field in two locations? The data in the field is reflected
the same.

So am I correct in stating if I have a field only at the form / item
level and I need the field to merge with Word, I need to recreate the
field at the folder level using one of the above steps?

Also, since I have multiple contact folders, I should update my
contact folder and then copy the contact folder. If I just create a
new contact folder, I will need to recreate all the folder level
fields again for that new contact folder at the folder level. Correct?

Lastly, any idea when creating a new form and adding fields they only
appear at the form level, however, if you modify a form, add a new
field it appears at the folder level and as you stated -- "but under
the surface - the field has been added to the custom form."

Shawn

 

[SRM]

If you contact folder is using a custom form AND you want to use one or
more of the user-defined fields in a merge then

#1 - Make sure you write down the "exact" user-defined field names used in
the custom form (field names not case-sensitive for this purpose)

#2 - DO NOT use the form designer for the rest of this - if you do - you
are altering the structure/contents of the custom form (adding a UDF to an
item is not the same as adding a UDF to a form which adds the UDF
for ALL items). The result will appear to be the same in terms of the
field being added to the Folder list but not completely sure of what the
implications are "under the surface" for the UserProperty collection
(which really becomes something of interest at the programmatic level
versus the UI level).

#3 - Open any contact in the folder - add the user-defined field desired -
these will be automatically add to the Folder list if you do nothing else
(just as if you add a UDF to a contact that uses IPM.Contact (standard
form) - make sure all the properties are the same for each field added
#4 - close your contact - the folder list of fields has what you want for
the merge

The above is specific to a given folder. Rinse and repeat the exact steps
for each and every folder in question.

As stated originally, start moving items depending on what and how things
were done to a folder can result in different behaviours BUT
   - #1 - creating a new folder,
   - #2 - assigning it the cutom form as the default and
   - #3 - copying contacts from another folder created with the same form
will retain all data but the target folder will not have any "Folder
Fields" until you repeat the above steps for the new folder.

For those that need to deal with multiple versions of Outlook in a given
custom solution where UDF names are "dynamically" determined/extracted
at run-time versus being "hard coded" into the solution, as is the case in
most code snip examples - strongly recommend using a reasonably current
version of Redemption (http://www.dimastr.com) and potentially save untold
hours of misery. The last time OOM and Redemption (RDO) items were used
in the same ContactGenie solution (years ago) - Redemption proved more
reliable/easier to deal with than what was returned by OOM when it came
to user-defined fields (depending of course on how exactly the user
properties were created and how the UserProperty collection was accessed
for an OOM item). As Shawn has come to find out via a 3rd party export tool
being used - an erroneous set of "current" user-defined fields can get
reported as a result.

Karl

--
____________________________________________________________
Karl Timmermans - The Claxton Group
ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
"Contact import/export/data management tools for Outlook '2000/2010"http://www.contactgenie.com

















Karl:

Thanks so much ...

read more »

Karl:

Thanks. Just to confirm since this is different than what I previously
understood.

"DO NOT use the form designer for the rest of this"

1. So for my contacts folder that has form level fields only, do not
use the form designer. Open a contact, All Fields, User-defined fields
in folder and add a new field at that point. Correct?

2. For my new contact folders, DO NOT copy the contacts folder. Create
a new contact folder, assign the custom form, copy contacts that I
want and follow Step 1 for the folder level fields. Correct?

3. Just to add some more interest, what if on my custom form I want to
add a new field to my form and merge it with Word (which I probably
will need to). Since its added at the folder level and the "under the
surface" for the form, what do I do?

4. OK, one more. If I create a new form, when I first add fields via
the form designer they are only added to the form level. Do I then
follow Step 1 (and possibly step 3 if I need to add more fields
later).?

Shawn

Shawn

 

[Karl Timmermans]

#1 - if the fields you want already appear in the "Folder Group" - no
action required

#2 - If you copy the "folder" - folder level fields will "tag along" since
those are part of the folder being copied. If you create a new folder and
then make the custom form the default - fields will be need to be added to
the folder level (again - outside of Forms Designer)

#3 - Adding a new field via the Forms Designer automatically adds it to the
folder level in the folder where this field addition occured. No further
action required to use it in a mail-merge for <that specific folder>

#4 - Creating a new form in a folder and publishing it already has the
fields at the form level - no action required. Making the same form the
default in another folder will require the addition of the fields to the
Folder Group as previously outlined (outside of the Forms Design process)
but here's a caveat - keep creating different forms in the same folder and
your folder group is going to be a mess since it will contain the fields
from all forms and you're not going to know which field was created by
what form - not that it matters. Fields will just come up empty in a merge
if data doesn't exist for it in a given contact however adding a field
created by one form to a contact created by and still associated with
another form will "one-off" the info for that specific contact

In short, fields in the "Folder Group" are accessible to the merge started
from within Outlook. If the fields that you want are there - no action
required. The only time you need to be in the Forms Designer is to a)
design a new form or b) modify a form and in all cases, the underlying
information for the published form can be properly retrieved
programmatically. It's in the UI where things behave/appear differently.

One very simple way to know exactly what UDFs belong to any "existing
published" custom form -
- create a new folder,
- make the form the default for the folder,
- create a new contact
the fields you see in the "user-defined fields in this item" group are the
fields that belong to the form - PERIOD. There will be no fields at the
Folder Group level. Any other fields reported by any other program as being
part of the UserProps group are "mis-reporting". None of these fields can
be used in an Outlook based merge without first being added to the folder
UDF group. Adding a field in one folder to the folder UDF group has nothing
to do with another folder regardless of where the form has been published.

Something that bears repeating for the world at large who may be reading
this - "DO NOT <PUBLISH> THE SAME FORM USING THE SAME
<FORM NAME> TO <MULTIPLE> FOLDERS UNLESS YOU ARE A
SELF-PROCLAIMED MASOCHIST" (or sadist depending on who has to
deal with the potential problems) - use either the Personal or Exch Org
Forms
lib in these cases. Making the same form the "default" for multiple folders
is
not the same thing as "publishing" it to multiple folders (applies to all
item
types - not just contacts).

Karl
--
____________________________________________________________
Karl Timmermans - The Claxton Group
ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
"Contact import/export/data management tools for Outlook '2000/2010"
http://www.contactgenie.com

If you contact folder is using a custom form AND you want to use one or
more of the user-defined fields in a merge then

#1 - Make sure you write down the "exact" user-defined field names used
in
the custom form (field names not case-sensitive for this purpose)

#2 - DO NOT use the form designer for the rest of this - if you do - you
are altering the structure/contents of the custom form (adding a UDF to
an
item is not the same as adding a UDF to a form which adds the UDF
for ALL items). The result will appear to be the same in terms of the
field being added to the Folder list but not completely sure of what the
implications are "under the surface" for the UserProperty collection
(which really becomes something of interest at the programmatic level
versus the UI level).

#3 - Open any contact in the folder - add the user-defined field
desired -
these will be automatically add to the Folder list if you do nothing else
(just as if you add a UDF to a contact that uses IPM.Contact (standard
form) - make sure all the properties are the same for each field added
#4 - close your contact - the folder list of fields has what you want for
the merge

The above is specific to a given folder. Rinse and repeat the exact steps
for each and every folder in question.

As stated originally, start moving items depending on what and how things
were done to a folder can result in different behaviours BUT
- #1 - creating a new folder,
- #2 - assigning it the cutom form as the default and
- #3 - copying contacts from another folder created with the same form
will retain all data but the target folder will not have any "Folder
Fields" until you repeat the above steps for the new folder.

For those that need to deal with multiple versions of Outlook in a given
custom solution where UDF names are "dynamically" determined/extracted
at run-time versus being "hard coded" into the solution, as is the case
in
most code snip examples - strongly recommend using a reasonably current
version of Redemption (http://www.dimastr.com) and potentially save
untold
hours of misery. The last time OOM and Redemption (RDO) items were used
in the same ContactGenie solution (years ago) - Redemption proved more
reliable/easier to deal with than what was returned by OOM when it came
to user-defined fields (depending of course on how exactly the user
properties were created and how the UserProperty collection was accessed
for an OOM item). As Shawn has come to find out via a 3rd party export
tool
being used - an erroneous set of "current" user-defined fields can get
reported as a result.

Karl

--
____________________________________________________________
Karl Timmermans - The Claxton Group
ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
"Contact import/export/data management tools for Outlook
'2000/2010"http://www.contactgenie.com

















Karl:

Thanks so much ...

read more »

Karl:

Thanks. Just to confirm since this is different than what I previously
understood.

"DO NOT use the form designer for the rest of this"

1. So for my contacts folder that has form level fields only, do not
use the form designer. Open a contact, All Fields, User-defined fields
in folder and add a new field at that point. Correct?

2. For my new contact folders, DO NOT copy the contacts folder. Create
a new contact folder, assign the custom form, copy contacts that I
want and follow Step 1 for the folder level fields. Correct?

3. Just to add some more interest, what if on my custom form I want to
add a new field to my form and merge it with Word (which I probably
will need to). Since its added at the folder level and the "under the
surface" for the form, what do I do?

4. OK, one more. If I create a new form, when I first add fields via
the form designer they are only added to the form level. Do I then
follow Step 1 (and possibly step 3 if I need to add more fields
later).?

Shawn

Shawn

 

[SRM]

#1 - if the fields you want already appear in the "Folder Group" - no
action required

#2 - If you copy the "folder" - folder level fields will "tag along" since
those are part of the folder being copied. If you create a new folder and
then make the custom form the default - fields will be need to be added to
the folder level (again - outside of Forms Designer)

#3 - Adding a new field via the Forms Designer automatically adds it to the
folder level in the folder where this field addition occured. No further
action required to use it in a mail-merge for <that specific folder>

#4 - Creating a new form in a folder and publishing it already has the
fields at the form level - no action required. Making the same form the
default in another folder will require the addition of the fields to the
Folder Group as previously outlined (outside of the Forms Design process)
but here's a caveat - keep creating different forms in the same folder and
your folder group is going to be a mess since it will contain the fields
from all forms and you're not going to know which field was created by
what form - not that it matters. Fields will just come up empty in a merge
if data doesn't exist for it in a given contact however adding a field
created by one form to a contact created by and still associated with
another form will "one-off" the info for that specific contact

In short, fields in the "Folder Group" are accessible to the merge started
from within Outlook. If the fields that you want are there - no action
required. The only time you need to be in the Forms Designer is to a)
design a new form or b) modify a form and in all cases, the underlying
information for the published form can be properly retrieved
programmatically. It's in the UI where things behave/appear differently.

One very simple way to know exactly what UDFs belong to any "existing
published" custom form -
 - create a new folder,
 - make the form the default for the folder,
 - create a new contact
the fields you see in the "user-defined fields in this item" group are the
fields that belong to the form - PERIOD. There will be no fields at the
Folder Group level. Any other fields reported by any other program as being
part of the UserProps group are "mis-reporting". None of these fields can
be used in an Outlook based merge without first being added to the folder
UDF group. Adding a field in one folder to the folder UDF group has nothing
to do with another folder regardless of where the form has been published..

Something that bears repeating for the world at large who may be reading
this - "DO NOT <PUBLISH> THE SAME FORM USING THE SAME
<FORM NAME> TO <MULTIPLE> FOLDERS UNLESS YOU ARE A
SELF-PROCLAIMED MASOCHIST" (or sadist depending on who has to
deal with the potential problems) - use either the Personal or Exch Org
Forms
lib in these cases. Making the same form the "default" for multiple folders
is
not the same thing as "publishing" it to multiple folders (applies to all
item
types - not just contacts).

Karl
--
____________________________________________________________
Karl Timmermans - The Claxton Group
ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
"Contact import/export/data management tools for Outlook '2000/2010"http://www.contactgenie.com












...

read more »

Karl:

I think I got everything working OK thanks to your assistance. I
greatly appreciate all your help.

I think I have a good understanding of when fields are added and
where, but not sure why it is how it is. I'm sure there is a good
reason why Outlook works in this manner.

Shawn

 

[Karl Timmermans]

Re: "......but not sure why it is how it is. I'm sure there is a good
reason why Outlook works in this manner"

There is one absolute certainty when it comes to Outlook,
and that is that there are all kinds of things that in polite company
would be referred to as "really hard (impossible?) to find
answers to all sorts of undocumented, unexpected <features>"
(I have been known to use a different set of adjectives every so often)
Decided to stop worrying about many of the "why's" a long time ago
and just work with (around) everything "the way it actually functions"
and move on leaving the "why's, should's, shouldn't's" etc to others

As for the good reason(s) - my guess that for many things there is
no specific "reason" other than just being a by-product of
something else with the whole Folder level UDFs and custom form
design topic being one such example.

Karl
--
____________________________________________________________
Karl Timmermans - The Claxton Group
ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
"Contact import/export/data management tools for Outlook '2000/2010"
http://www.contactgenie.com

#1 - if the fields you want already appear in the "Folder Group" - no
action required

#2 - If you copy the "folder" - folder level fields will "tag along"
since
those are part of the folder being copied. If you create a new folder and
then make the custom form the default - fields will be need to be added
to
the folder level (again - outside of Forms Designer)

#3 - Adding a new field via the Forms Designer automatically adds it to
the
folder level in the folder where this field addition occured. No further
action required to use it in a mail-merge for <that specific folder>

#4 - Creating a new form in a folder and publishing it already has the
fields at the form level - no action required. Making the same form the
default in another folder will require the addition of the fields to the
Folder Group as previously outlined (outside of the Forms Design process)
but here's a caveat - keep creating different forms in the same folder
and
your folder group is going to be a mess since it will contain the fields
from all forms and you're not going to know which field was created by
what form - not that it matters. Fields will just come up empty in a
merge
if data doesn't exist for it in a given contact however adding a field
created by one form to a contact created by and still associated with
another form will "one-off" the info for that specific contact

In short, fields in the "Folder Group" are accessible to the merge
started
from within Outlook. If the fields that you want are there - no action
required. The only time you need to be in the Forms Designer is to a)
design a new form or b) modify a form and in all cases, the underlying
information for the published form can be properly retrieved
programmatically. It's in the UI where things behave/appear differently.

One very simple way to know exactly what UDFs belong to any "existing
published" custom form -
- create a new folder,
- make the form the default for the folder,
- create a new contact
the fields you see in the "user-defined fields in this item" group are
the
fields that belong to the form - PERIOD. There will be no fields at the
Folder Group level. Any other fields reported by any other program as
being
part of the UserProps group are "mis-reporting". None of these fields can
be used in an Outlook based merge without first being added to the folder
UDF group. Adding a field in one folder to the folder UDF group has
nothing
to do with another folder regardless of where the form has been
published.

Something that bears repeating for the world at large who may be reading
this - "DO NOT <PUBLISH> THE SAME FORM USING THE SAME
<FORM NAME> TO <MULTIPLE> FOLDERS UNLESS YOU ARE A
SELF-PROCLAIMED MASOCHIST" (or sadist depending on who has to
deal with the potential problems) - use either the Personal or Exch Org
Forms
lib in these cases. Making the same form the "default" for multiple
folders
is
not the same thing as "publishing" it to multiple folders (applies to all
item
types - not just contacts).

Karl
--
____________________________________________________________
Karl Timmermans - The Claxton Group
ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
"Contact import/export/data management tools for Outlook
'2000/2010"http://www.contactgenie.com












...

read more »

Karl:

I think I got everything working OK thanks to your assistance. I
greatly appreciate all your help.

I think I have a good understanding of when fields are added and
where, but not sure why it is how it is. I'm sure there is a good
reason why Outlook works in this manner.

Shawn