Sync utilities are probably OK, but check with the individual company. Features differ.
Views and forms are different. A form is the layout for a single item. Each item has a MessageClass property that tells it which form layout to use. If you want a different form layout, you have to change the MessageClass for that item.
A view is the layout for multiple items. You can have as many views as you want, showing whatever fields you need.

Signature
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
> Sorry for newbie question.
>
[quoted text clipped - 25 lines]
> it, or the Chapura conduct just access the data altogether without caring
> for the form ?
microsoft.public.outlook.contacts
> Sync utilities are probably OK, but check with the individual company.
> Features differ.
Ok. Thanks for info. I'll test myself. What I would like actually is a form
that mimics the one on the Palm, therefore having *less" fields than the
deafult Oultook contact form, and avoid having any additional data
typically visible not transfered to my palm because of the limitation of
the PalmOs. Example: addresses. Outlook can have many, palmOS only one. I
prefer to have one Contact, one address, and want therefore to avoid an
Outlook form to allow more than address.
> Views and forms are different. A form is the layout for a single item.
> Each item has a MessageClass property that tells it which form layout
[quoted text clipped - 3 lines]
> A view is the layout for multiple items. You can have as many views as
> you want, showing whatever fields you need.
Ok, sorry for confusion in vocabulary! You're right to point that. I knew
that the difference.
I used the "view" word in the general meaning, that is "how I see my data"
(not precising one or many items), and not in the stricter Outlook or
database meaning. My Outlook being in French, I am sometime mixed-up with
corresponding word in English. But I was careless not to respect the
appropriate meaning. I meant of course switching between forms at will for
the same item.
Meanwhile, I precisely and successfully created a form and convert existing
items to it, then back to original form.
Note that from you web page, I tried
1. "O2000 Existing Items Converter" = not direct link to download page and
never worked. It crashed my Outlook XP multiple times.
2. "Update Message Class Form (code28.zip) = was launched ok but didn't
seem to work for me. It did nothing when I click "Proceed" (yes, I followed
instructions, but I might have missed something. Perhaps my Outlook being
in French ?)
3. "Helen Feddema's VB Script method" = did not download as I thought it
was exactly the same as above (same code28.zip), so I thought it was just a
duplicate
4. Word 97 Document to Change Outlook Folder Message Class = knowledge base
article is unavailable
5. How to Update Existing Items to Use a New Custom Form = Ok, but I was
fearful to download it as I use O2002 and it was specified to be used only
with O97. From there I linked to
http://support.microsoft.com/default.aspx?scid=kb;EN-US;201089, but the
page didn't display ok on my browser (Opera), so I couldn't see it.
Finally, I found:
http://support.microsoft.com/default.aspx?scid=kb;en-us;290659
I found out it is as a matter of fact the same omgsclass tool used for 097,
so your first link was okay, the only thing it was just mentionning to O97.
(Newbies like me don't know when differences between versions are important
and when the aren't, so we tend to stick only with tools) specifically
design and display as compatible with our current version.
You might like to update your web page with these info for other visitors.
The omsgclass worked pretty fine.
I was also able to create a view grouping items based on MessageClasse
(pretty useful), but was disappointed to see that a custom form doesn't
display in the preview view which result in having a custom form almost
pointless.
In my testing, I conclude that if I delete a form component on a custom
form and change existing items having information in that form component,
information is not lost (meaning that the *item* is bounded to a form, but
not *data* in the item which can be held (or even modified with VBA?)
without having a form component to display it ?). Anyway, when I switch
back to original form, the data is displayed again. Is there situations
where changing a form might result in loosing data ?
As for custom fields, I succesfully created one in my custom form, then
delete it in both the form design and the view. However, I understand the
only way to get really ride of a custom field in an item that once had the
info in it is to open *each* item one by one and remove the custom field by
hand, or learn VBA and make up a small for..if delete routine. It would
make sense afterall of having a item that carry its data whatever the form
or the view used.
Am I in the right direct up to now ?
Thanks for all the info.
Note that the first page of your presentation "Developing Applications with
Microsoft Outlook" was the most enlightening for me as a newbie to
understand how Outlook handle data internally. Once you get the kick of it,
other information get sense.