user-defined properties in printed emails?

  • Thread starter Thread starter Mark McGinty
  • Start date Start date
M

Mark McGinty

We've just found that, when printing an email that has user-defined
properties added to it, the names and values of those user-defined
properties are dumped-out as additions to the header. Ugly! Is there any
way to make it not do that?

This 'feature' makes no sense to me, the only way to view those properties
in the inspector is to open the form designer (or add code to make the all
fields tab visible.) But whatever defines the way it's formatted for
printing, dumps those properties onto the page as a matter of course?

If it only happened if/when the all fields tab was visible, it would make
some sense, but unfortunately that is not the case.

Any insight would be appreciated!


-Mark McGinty
 
In design mode on a custom form select the control that binds the user
property, and in the Validation tab set the checkbox for Include this field
for Printing and Save As as you want it.

In general if you want properties not to be visible at all in any way in the
UI you'd use MAPI named properties rather than Outlook UserProperties.
 
Ken Slovak - said:
In design mode on a custom form select the control that binds the user
property, and in the Validation tab set the checkbox for Include this
field for Printing and Save As as you want it.

In general if you want properties not to be visible at all in any way in
the UI you'd use MAPI named properties rather than Outlook UserProperties.
Click to expand...

Thanks for the reply. None of the user properties are bound to any form
controls; a decision was made early on to not incorporate any custom forms
into this app. They are used internally by the AddIn. The only way for a
user to display the properties is to add them to a table view in the
explorer. None are particuarly useful to the user on a paper copy of the
item.

I see that task, contact and appointment print-outs are the same way...

Hard for me to imagine a user that would ever want this behavior. (No need
to imagine users that don't want it though, I have already seen some that
occurred naturally.)

I will look into MAPI named properties... I thought UserProperties were MAPI
named properties?


Thanks,
Mark
 
UserProperties are MAPI named properties that are in the PS_PUBLIC_STRINGS
namespace and are also stored in the hidden message in the folder with a
MessageClass of "IPC.MS.REN.USERFIELDS".

MAPI named properties usually are in the PS_PUBLIC_STRINGS namespace
although you can use your own GUID for a namespace instead of using the
PS_PUBLIC_STRINGS namespace, and they aren't added to the hidden message for
UserProperties. They aren't visible to the user at all.

Unless you are using Outlook 2007 only the ways to create MAPI named
properties would rely on Extended MAPI, Redemption
(www.dimastr.com/redemption) or CDO 1.21.
 
Actually only properties that are defined on teh folder level are stored in
the IPC.MS.REN.USERFIELDS hidden message.
If you do not specify AddToFolderFields parameter (optional) as true when
calling UserProperties.Add, the property will nto be added to the folder
fields.
UserProperties definitions are stored in yet another named MAPI property,
while the values are stored as as regular MAPI properties.
You can edit the user properries blob to turn the "print" flag off, but the
blob is as binary as it gets.
<plug> Redemption (url below) exposes that as RDOUserProperty.Printable
property - http://www.dimastr.com/redemption/rdo/rdouserproperty.htm
</plug>

--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-
 
Is there any way to access this blob and change the Print flag using Outlook
Object Model?
 
Thanks Dmitry (and sorry for the delayed response.)

What is the minimum version of RDO with this capability? (We are currently
shipping Redemption 4.2.0.562 with our product.)

Thanks,
Mark McGinty
 
Back
Top