Merging From Outlook 2003 Using Form or Folder Level Fields

Status
Not open for further replies.
S

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
 
K

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" <shawnmsrm@gmail.com> wrote in message

news:8e0346ed-e248-4f4e-a72d-9b63ce429bfa@q2g2000pre.googlegroups.com...
> 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
 
S

SRM

On Mar 3, 9:50 am, " - " <kenslo...@mvps.org
wrote:
> 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.

> >

> http://www.slovaktech.com

> "SRM" <shawnm...@gmail.com> wrote in message

> news:8e0346ed-e248-4f4e-a72d-9b63ce429bfa@q2g2000pre.googlegroups.com...
>
> > 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:

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

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

______________________

ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr

"""
<kenslovak@mvps.org> wrote in message

news:%23qnNrDuuKHA.6124@TK2MSFTNGP04.phx.gbl...
> 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" <shawnmsrm@gmail.com> wrote in message
> news:8e0346ed-e248-4f4e-a72d-9b63ce429bfa@q2g2000pre.googlegroups.com...
> > 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

>
 
S

SRM

On Mar 4, 3:17 am, "Karl Timmermans" <k...@claxton.com> wrote:
> 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
> > ______________________
>

> ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
> """http://www.contactgenie.com

> " - " <kenslo...@mvps.org> wrote in messagenews:%23qnNrDuuKHA.6124@TK2MSFTNGP04.phx.gbl...
>
> > 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.

>
> > > >

> >

> >

>
> > "SRM" <shawnm...@gmail.com> wrote in message
> >news:8e0346ed-e248-4f4e-a72d-9b63ce429bfa@q2g2000pre.googlegroups.com...
> >> 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


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
 
K

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

______________________

ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr

"""

"SRM" <shawnmsrm@gmail.com> wrote in message

news:0e6be563-b783-4d97-8cb2-414f83561113@u9g2000yqb.googlegroups.com...

On Mar 4, 3:17 am, "Karl Timmermans" <k...@claxton.com> wrote:
> 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
> > ______________________
>

> ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
> "Contact import/export/data management tools for Outlook
> '2000/2010"http://www.contactgenie.com

> " - " <kenslo...@mvps.org> wrote in
> messagenews:%23qnNrDuuKHA.6124@TK2MSFTNGP04.phx.gbl...
>
> > 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.

>
> > > >

> >

> >

>
> > "SRM" <shawnm...@gmail.com> wrote in message
> >news:8e0346ed-e248-4f4e-a72d-9b63ce429bfa@q2g2000pre.googlegroups.com...
> >> 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


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
 
S

SRM

On Mar 4, 10:39 am, "Karl Timmermans" <k...@claxton.com> wrote:
> 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

> > ______________________
>

> ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
> """http://www.contactgenie.com

> "SRM" <shawnm...@gmail.com> wrote in message

> news:0e6be563-b783-4d97-8cb2-414f83561113@u9g2000yqb.googlegroups.com...
> On Mar 4, 3:17 am, "Karl Timmermans" <k...@claxton.com> wrote:

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

> > ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
> > "Contact import/export/data management tools for Outlook
> > '2000/2010"http://www.contactgenie.com

>
> > " - " <kenslo...@mvps.org> wrote in
> > messagenews:%23qnNrDuuKHA.6124@TK2MSFTNGP04.phx.gbl...

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

>
> > > > > >

> > >

> > > > > >

>
> > > "SRM" <shawnm...@gmail.com> wrote in message
> > >news:8e0346ed-e248-4f4e-a72d-9b63ce429bfa@q2g2000pre.googlegroups.com....
> > >> 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


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

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

______________________

ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr

"""

"SRM" <shawnmsrm@gmail.com> wrote in message

news:4910f94e-a02a-484c-a655-7139212a0934@c16g2000yqd.googlegroups.com...

On Mar 4, 10:39 am, "Karl Timmermans" <k...@claxton.com> wrote:
> 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

> > ______________________
>

> ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
> "Contact import/export/data management tools for Outlook
> '2000/2010"http://www.contactgenie.com

> "SRM" <shawnm...@gmail.com> wrote in message

> news:0e6be563-b783-4d97-8cb2-414f83561113@u9g2000yqb.googlegroups.com...
> On Mar 4, 3:17 am, "Karl Timmermans" <k...@claxton.com> wrote:

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

> > ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact
> > Mgr
> > "Contact import/export/data management tools for Outlook
> > '2000/2010"http://www.contactgenie.com

>
> > " - " <kenslo...@mvps.org> wrote in
> > messagenews:%23qnNrDuuKHA.6124@TK2MSFTNGP04.phx.gbl...

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

>
> > > > > >

> > >

> > > > > >

>
> > > "SRM" <shawnm...@gmail.com> wrote in message
> > >news:8e0346ed-e248-4f4e-a72d-9b63ce429bfa@q2g2000pre.googlegroups.com...
> > >> 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


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

SRM

On Mar 4, 4:58 pm, "Karl Timmermans" <k...@claxton.com> wrote:
> #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
> > ______________________
>

> ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
> """http://www.contactgenie.com

> "SRM" <shawnm...@gmail.com> wrote in message

> news:4910f94e-a02a-484c-a655-7139212a0934@c16g2000yqd.googlegroups.com...
> On Mar 4, 10:39 am, "Karl Timmermans" <k...@claxton.com> wrote:
>
> > 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

>
> > > > ______________________
> >

> > ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
> > "Contact import/export/data management tools for Outlook
> > '2000/2010"http://www.contactgenie.com

>
> > "SRM" <shawnm...@gmail.com> wrote in message

>
> >news:0e6be563-b783-4d97-8cb2-414f83561113@u9g2000yqb.googlegroups.com...
> > On Mar 4, 3:17 am, "Karl Timmermans" <k...@claxton.com> wrote:

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


> ...

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

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

______________________

ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr

"""

"SRM" <shawnmsrm@gmail.com> wrote in message

news:967ffefc-1f93-4365-a04b-85e80fe8789f@g28g2000yqh.googlegroups.com...

On Mar 4, 4:58 pm, "Karl Timmermans" <k...@claxton.com> wrote:
> #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
> > ______________________
>

> ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact Mgr
> "Contact import/export/data management tools for Outlook
> '2000/2010"http://www.contactgenie.com

> "SRM" <shawnm...@gmail.com> wrote in message

> news:4910f94e-a02a-484c-a655-7139212a0934@c16g2000yqd.googlegroups.com...
> On Mar 4, 10:39 am, "Karl Timmermans" <k...@claxton.com> wrote:
>
> > 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

>
> > > > ______________________
> >

> > ContactGenie - QuickPort/DataPort/Exporter/Toolkit/Duplicate Contact
> > Mgr
> > "Contact import/export/data management tools for Outlook
> > '2000/2010"http://www.contactgenie.com

>
> > "SRM" <shawnm...@gmail.com> wrote in message

>
> >news:0e6be563-b783-4d97-8cb2-414f83561113@u9g2000yqb.googlegroups.com...
> > On Mar 4, 3:17 am, "Karl Timmermans" <k...@claxton.com> wrote:

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


> ...

> 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
 
Status
Not open for further replies.
Similar threads
Thread starter Title Forum Replies Date
C Merging Word and Access into Outlook Using Outlook 4
H outlook email merging with attachments Using Outlook 4
L Article on merging pst file Using Outlook 1
Diane Poremsky Merging Two Calendar Folders Using Outlook 0
M mail merging contacts and contact groups. can code achieve this? Using Outlook 11
C Managing & Merging .pst files Using Outlook 3
C merging duplicate files Using Outlook 3
T Merging multiple Business Contact Manager files BCM (Business Contact Manager) 0
V Outlook 2003 and Windows 11 Using Outlook 4
J How to import many msg into different public folders in Outlook Outlook VBA and Custom Forms 7
I Outlook for Mac 2019 using on desktop and laptop IMAP on both need help with folders Using Outlook 1
A Reminder duplication Outlook and Outlook.com Using Outlook.com accounts in Outlook 5
F Moving Outlook to new PC Using Outlook 0
mll persistently customise columns in outlook advanced search Using Outlook 3
Ken Pascoe Outlook Categories Quick List Using Outlook 0
M All fonts in Outlook emails display with exaggerated character spacing Using Outlook 1
talla Can't open Outlook Item. Using Outlook 0
C Can't Locate an Unread Message in my Outlook view pane Using Outlook 0
C Outlook 2007 Removing then adding account restores junk email processing Using Outlook 0
P Importing other e-mail accounts into Outlook Using Outlook 1
J Read Outlook Form fields Outlook VBA and Custom Forms 3
B Inconsistent handling of message read/unread status by Outlook Using Outlook 3
R Rogue Outlook Rule ? Using Outlook 2
S vba outlook search string with special characters Outlook VBA and Custom Forms 1
F Wishlist Outlook suddenly began synchronizing deleted items every time I delete a single email. Using Outlook 2
U Outlook 2019 VBA run-time error 424 Outlook VBA and Custom Forms 2
K Outlook 2019 Randomly Disconnecting from Gmail Servers Using Outlook 8
P Outlook calendar and contacts sync problem-outlook disconnects Using Outlook.com accounts in Outlook 2
HarvMan Toggle between calendar and email in Outlook 365 Using Outlook 12
V Outlook error 500 Using Outlook 2
F Email being marked as Spam by Gmail and not being visible in Outlook Using Outlook 5
S Mac Outlook 365 Questions Using Outlook 1
M Outlook calendar is missing Using Outlook 2
G Save and Rename Outlook Email Attachments Outlook VBA and Custom Forms 0
G Trigger script without restaring outlook Outlook VBA and Custom Forms 7
T Have you written an articles about Outlook? Using Outlook 3
V Compound IF, OR, AND in Outlook form Outlook VBA and Custom Forms 4
A Any way to make Outlook Calendar invitations look right to Gmail/Google Calendar users? Using Outlook 3
R Outlook 365 update sets delete from server flag Using Outlook 1
M How to setup outlook after importing old account information - Entering email account info creates with "(1)" after the account! Using Outlook 1
P Prevent Outlook 2016 from using DASL filter Using Outlook 4
I Button PDF in Outlook Contact custom form Outlook VBA and Custom Forms 1
G VBA to save selected Outlook msg with new name in selected network Windows folder Outlook VBA and Custom Forms 1
X Outlook automation pull from PDF Using Outlook 6
O Outlook 365 - How to create / copy a new contact from an existing one? Using Outlook 3
M Gmail address associated with Outlook on new phone Using Outlook 9
D Cannot populate certain UserProperties in Outlook from Excel Outlook VBA and Custom Forms 2
F Excel VBA to move mails for outlook 365 on secondary mail account Outlook VBA and Custom Forms 1
G Outlook 2016: Want IMAP Data Files on My D: Drive and Not C: Drive Using Outlook 1
V Validating Outlook form with "OR" and "AND" Outlook VBA and Custom Forms 1

Similar threads

Top