Re: User defined fields - UDF in Folder Issues

Assuming you don't have any custom formula fields, yes, that code should do what you need -- add a consistent set of user-defined fields to all the folders. You can run it any way you want, but since it only needs to be run once per folder, it's overkill to add it to the form script itself. Easiest implementation, IMO, is to just use VBA.

Glad you like the book, BTW.

--
Sue Mosher, Outlook MVP
Outlook and Exchange solutions at http://www.slipstick.com
Author of
Microsoft Outlook Programming: Jumpstart
for Administrators, Power Users, and Developers
http://www.slipstick.com/books/jumpstart.htm


"Reed Phillips" <reed@phillipsfam.com> wrote in message news:3EFDBBB5.7050806@phillipsfam.com...
> I have one Form "AvconContacts" (a contact form). It is stored in the
> organizational forms library, although it did not start out there. I
> use to save the form with every folder it is associated with. In the
> early days, I would tend to open a form in any of the folders below, add
> the fields, modify the scripts and publish them to each folder that uses
> the form. I don't do that anymore. I now only publish it to the
> organizational forms lib.
>
> I added three tabs to the form; "Project", "Service" & "Service Contracts"
>
> I have three folders in the Public Folders that contain items created
> using this form.
> 1) Shared Contacts - where we use the General and Details tab
> 2) Service Requests - where we use the Service tab
> 3) Service Contracts - where we keep data about each service contract.
>
> I set it up this way to make it easy to copy items from one folder to
> another. Eg. A service call comes in, find the person in Shared
> Contacts and copy it to Service Requests. Cuts down on data entry.
>
> When I look at the "UDF in folder" for each of the above folders, I see
> a different set of Names. I think this is keeping "Find" from working.
>
> How can I make all of the folders see all of the UDFs?
>
> Will Listing 24.2 on page 562 in Sue's book solve the problem? It seems
> to suggest it will
>
> If so, can I add this Sub to my form script and call it from a
> CommandButton? Or does need to run as a seprate VB application?
>
> Sorry for the long winded post.
>
> -reed
>

Yes I do have a few formula fields to calculate tax and produce totals. What
will happen with these fields when I run the application. Remember, I no not
have the form stored with the folder, only in the Org Lib. However, the same
form is used in different ways in different folders.

Yes I really liked the book! It touches on virtually every topic that caused
be problems along the way. -reed



"Sue Mosher [MVP]" <suemvp@slipstick.com> wrote in message
news:ubUWon8PDHA.1556@TK2MSFTNGP10.phx.gbl...
Assuming you don't have any custom formula fields, yes, that code should do
what you need -- add a consistent set of user-defined fields to all the
folders. You can run it any way you want, but since it only needs to be run
once per folder, it's overkill to add it to the form script itself. Easiest
implementation, IMO, is to just use VBA.

Glad you like the book, BTW.

--
Sue Mosher, Outlook MVP
Outlook and Exchange solutions at http://www.slipstick.com
Author of
Microsoft Outlook Programming: Jumpstart
for Administrators, Power Users, and Developers
http://www.slipstick.com/books/jumpstart.htm


"Reed Phillips" <reed@phillipsfam.com> wrote in message
news:3EFDBBB5.7050806@phillipsfam.com...
> I have one Form "AvconContacts" (a contact form). It is stored in the
> organizational forms library, although it did not start out there. I
> use to save the form with every folder it is associated with. In the
> early days, I would tend to open a form in any of the folders below, add
> the fields, modify the scripts and publish them to each folder that uses
> the form. I don't do that anymore. I now only publish it to the
> organizational forms lib.
>
> I added three tabs to the form; "Project", "Service" & "Service Contracts"
>
> I have three folders in the Public Folders that contain items created
> using this form.
> 1) Shared Contacts - where we use the General and Details tab
> 2) Service Requests - where we use the Service tab
> 3) Service Contracts - where we keep data about each service contract.
>
> I set it up this way to make it easy to copy items from one folder to
> another. Eg. A service call comes in, find the person in Shared
> Contacts and copy it to Service Requests. Cuts down on data entry.
>
> When I look at the "UDF in folder" for each of the above folders, I see
> a different set of Names. I think this is keeping "Find" from working.
>
> How can I make all of the folders see all of the UDFs?
>
> Will Listing 24.2 on page 562 in Sue's book solve the problem? It seems
> to suggest it will
>
> If so, can I add this Sub to my form script and call it from a
> CommandButton? Or does need to run as a seprate VB application?
>
> Sorry for the long winded post.
>
> -reed
>

Outlook methods cannot create formula fields programmatically. The subroutine should ignore them, but you'll need to create them manually if you want to see them in folder views.
--
Sue Mosher, Outlook MVP
Outlook and Exchange solutions at http://www.slipstick.com
Author of
Microsoft Outlook Programming: Jumpstart
for Administrators, Power Users, and Developers
http://www.slipstick.com/books/jumpstart.htm

"reed" <reed@avconnc.com> wrote in message news:bdsem8$9h9$1@slb9.atl.mindspring.net...
> Yes I do have a few formula fields to calculate tax and produce totals. What
> will happen with these fields when I run the application. Remember, I no not
> have the form stored with the folder, only in the Org Lib. However, the same
> form is used in different ways in different folders.
>
>
>
> "Sue Mosher [MVP]" <suemvp@slipstick.com> wrote in message
> news:ubUWon8PDHA.1556@TK2MSFTNGP10.phx.gbl...
> Assuming you don't have any custom formula fields, yes, that code should do
> what you need -- add a consistent set of user-defined fields to all the
> folders. You can run it any way you want, but since it only needs to be run
> once per folder, it's overkill to add it to the form script itself. Easiest
> implementation, IMO, is to just use VBA.
>