Changes made using RDO, visibility in OOM

[Mark McGinty]

Is it possible to add/change a UserProperty on an item using RDO, in such a
way that said addition/change is visible in the corresponding OOM item
(i.e., same EntryID) *without* having to restart Outlook?

And on a note that may seem entirely unrelated, but actually isn't (from
inside my head, if from nowhere else): how is it that RDOMail.Display does
not cause Inspectors.NewInspector to fire, even though [AddIn App
Instance/Application].ActiveInspector returns the expected Inspector
immediately after... oh wow, here's the undeniable tie-in: that
ActiveInspector (as opened by RDOMail.Display) has, of course, a CurrentItem
property, which, of course again, returns a reference to an OOM item
object -- *BUT* the RDO-altered UserProperties *ARE* visible within it!
However, if you close it and re-open by double-clicking in the Explorer,
those same UserProperties changes are *not* there! Wow... that is...
interesting...

I think it's time for 3 Excedrin Extra Strength's and a tripple gin and
tonic (no garbage... hold the ice... hell, hold the tonic too. Yep, a juice
glass full of straight gin... Not just for breakfast anymore...)

So... say I wanted to do something really quirky and niche, like making sure
my users never see my AddIn's user properties printed on paper, even when
they do quirky niche stuff like opening an item in the Explorer, and even
when they have the audacity to do so without having restarted Outlook
between emails (my users are funny like that, the bastards!) When
NewInspector fires, it's a safe bet that RDOMail.Display was not involved,
so, in that event handler I acquire an RDO object reference to the item,
compare its UserProperties against those in CurrentItem, and if they are
different, close the just-opened Inspector and re-open it by calling
RDOMail.Display... and manually create a wrapper and add it to the
collection, so my AddIn UI stuff is there too (no other AddIn's stuff will
be, but at least mine will, what else matters?) Oh yeah, can't forget to
move the new Inspector, since it will be at the old inspector's client 0,0
(not its window 0,0.)

What are the chances that would work? Can you call Inspector.Close from
within NewInspector? Sounds like something that will work on my system, but
nut-up intermittently in the wild -- oh man I *can't* *wait* to explain all
this to my division manager when we meet today! (It's what I live for.)


-MM

 

[Mark McGinty]

As it turns out, Inspector.Close from inside of NewInspector is ignored.
Also, comparing user properties is unnecessary, LastModificationTime is
enough.

-MM

 

[Ken Slovak]

You can instantiate an item.Open() event handler in NewInspector(). When
Open() fires you can close the Inspector in that event handler.

Outlook doesn't know about RDO* items until they are saved and you then open
an Outlook item based on the saved RDO* item.

When you do something like outlookMail.Subject = outlookMail.Subject you
tell Outlook something has changed in the item. Save it and then it should
be updated.

What I do if I don't want users to see, screw with or print properties I've
added to items is I bypass the UserProperties collections completely
(Outlook as well as RDO). I create a named MAPI property with RDO using a
name, the GUID for PS_PUBLIC_STRINGS and an item type (PT_STRING8,
PT_BOOLEAN, etc.). That PS_PUBLIC_STRINGS namespace is what's used for the
UserProperties collection, but since you aren't adding your property to that
binary blob the property is invisible to the UI elements. You can only see
it using a MAPI viewer like OutlookSpy or MFCMAPI.

As it turns out, Inspector.Close from inside of NewInspector is ignored.
Also, comparing user properties is unnecessary, LastModificationTime is
enough.

-MM

Is it possible to add/change a UserProperty on an item using RDO, in such
a way that said addition/change is visible in the corresponding OOM item
(i.e., same EntryID) *without* having to restart Outlook?

And on a note that may seem entirely unrelated, but actually isn't (from
inside my head, if from nowhere else): how is it that RDOMail.Display
does not cause Inspectors.NewInspector to fire, even though [AddIn App
Instance/Application].ActiveInspector returns the expected Inspector
immediately after... oh wow, here's the undeniable tie-in: that
ActiveInspector (as opened by RDOMail.Display) has, of course, a
CurrentItem property, which, of course again, returns a reference to an
OOM item object -- *BUT* the RDO-altered UserProperties *ARE* visible
within it! However, if you close it and re-open by double-clicking in the
Explorer, those same UserProperties changes are *not* there! Wow... that
is... interesting...

I think it's time for 3 Excedrin Extra Strength's and a tripple gin and
tonic (no garbage... hold the ice... hell, hold the tonic too. Yep, a
juice glass full of straight gin... Not just for breakfast anymore...)

So... say I wanted to do something really quirky and niche, like making
sure my users never see my AddIn's user properties printed on paper, even
when they do quirky niche stuff like opening an item in the Explorer, and
even when they have the audacity to do so without having restarted
Outlook between emails (my users are funny like that, the bastards!)
When NewInspector fires, it's a safe bet that RDOMail.Display was not
involved, so, in that event handler I acquire an RDO object reference to
the item, compare its UserProperties against those in CurrentItem, and if
they are different, close the just-opened Inspector and re-open it by
calling RDOMail.Display... and manually create a wrapper and add it to
the collection, so my AddIn UI stuff is there too (no other AddIn's stuff
will be, but at least mine will, what else matters?) Oh yeah, can't
forget to move the new Inspector, since it will be at the old inspector's
client 0,0 (not its window 0,0.)

What are the chances that would work? Can you call Inspector.Close from
within NewInspector? Sounds like something that will work on my system,
but nut-up intermittently in the wild -- oh man I *can't* *wait* to
explain all this to my division manager when we meet today! (It's what I
live for.)


-MM

 

[Mark McGinty]

You can instantiate an item.Open() event handler in NewInspector(). When
Open() fires you can close the Inspector in that event handler.

I used a timer, but an Open event handler might be a little more
deterministic -- thanks.

Outlook doesn't know about RDO* items until they are saved and you then
open an Outlook item based on the saved RDO* item.

I'm not really having any problems with RDO-created items, the problems
arise when manipulating the UserProperties collection of an item in RDO,
with expectation of seeing the effects of that manipulation in OOM.

When you do something like outlookMail.Subject = outlookMail.Subject you
tell Outlook something has changed in the item. Save it and then it should
be updated.

If the item has been changed/saved in RDO, and then you change it in OOM,
Outlook will refuse to save it and prompt the user to either create a copy,
or cancel.

In this instance I was most focused on inbox emails, that are somewhat
oblivious to changes; setting the follow-up flag causes the item to be
implicitly saved (though LastModificationTime is not updated) immediately
upon closing the dialog. If the item can't be saved, that implicit save
fails silently, Saved is set to false, and the user is prompted to save
changes when the item is closed, and then prompted again about being unable
to save/offer to make a copy.

Hmm it just occurred to me that this might only be a problem with inbox (or
maybe sent = true) emails. RDO-manipulated UserProperties on contacts,
tasks and calendar items are fine.

What I do if I don't want users to see, screw with or print properties
I've added to items is I bypass the UserProperties collections completely
(Outlook as well as RDO). I create a named MAPI property with RDO using a
name, the GUID for PS_PUBLIC_STRINGS and an item type (PT_STRING8,
PT_BOOLEAN, etc.). That PS_PUBLIC_STRINGS namespace is what's used for the
UserProperties collection, but since you aren't adding your property to
that binary blob the property is invisible to the UI elements. You can
only see it using a MAPI viewer like OutlookSpy or MFCMAPI.

Other than the extra code overhead of that approach, there is utility value
to the user to be able to see the user props in some cases, though
practically none of it applies to what a user might want to print. So the
RDOUserProperty.Printable property is a perfect fit here (it seems
unconscionable to me that OOM has no parallel mechanism, and that Outlook
offers no way to turn-off inclusion of user props in print-out, but I
digress.)

A perfect fit except, of course, for this little visibility glitch. I got
it to work, the close/re-open flash is a little chunky but probably
acceptable. I would surely love a peek under the hood at RDOMail.Display,
there must be some serious voodoo in there, to come up with an OOM item that
reflects all RDO property changes.


-MM

As it turns out, Inspector.Close from inside of NewInspector is ignored.
Also, comparing user properties is unnecessary, LastModificationTime is
enough.

-MM

Is it possible to add/change a UserProperty on an item using RDO, in
such a way that said addition/change is visible in the corresponding OOM
item (i.e., same EntryID) *without* having to restart Outlook?

And on a note that may seem entirely unrelated, but actually isn't (from
inside my head, if from nowhere else): how is it that RDOMail.Display
does not cause Inspectors.NewInspector to fire, even though [AddIn App
Instance/Application].ActiveInspector returns the expected Inspector
immediately after... oh wow, here's the undeniable tie-in: that
ActiveInspector (as opened by RDOMail.Display) has, of course, a
CurrentItem property, which, of course again, returns a reference to an
OOM item object -- *BUT* the RDO-altered UserProperties *ARE* visible
within it! However, if you close it and re-open by double-clicking in
the Explorer, those same UserProperties changes are *not* there! Wow...
that is... interesting...

I think it's time for 3 Excedrin Extra Strength's and a tripple gin and
tonic (no garbage... hold the ice... hell, hold the tonic too. Yep, a
juice glass full of straight gin... Not just for breakfast anymore...)

So... say I wanted to do something really quirky and niche, like making
sure my users never see my AddIn's user properties printed on paper,
even when they do quirky niche stuff like opening an item in the
Explorer, and even when they have the audacity to do so without having
restarted Outlook between emails (my users are funny like that, the
bastards!) When NewInspector fires, it's a safe bet that RDOMail.Display
was not involved, so, in that event handler I acquire an RDO object
reference to the item, compare its UserProperties against those in
CurrentItem, and if they are different, close the just-opened Inspector
and re-open it by calling RDOMail.Display... and manually create a
wrapper and add it to the collection, so my AddIn UI stuff is there too
(no other AddIn's stuff will be, but at least mine will, what else
matters?) Oh yeah, can't forget to move the new Inspector, since it
will be at the old inspector's client 0,0 (not its window 0,0.)

What are the chances that would work? Can you call Inspector.Close from
within NewInspector? Sounds like something that will work on my system,
but nut-up intermittently in the wild -- oh man I *can't* *wait* to
explain all this to my division manager when we meet today! (It's what
I live for.)


-MM

 

[Ken Slovak]

I've often used timers for things like that. In the opening case I felt an
event handler was better.

If you save an RDO item and then release all instances of it, and then get
the Outlook item you shouldn't have the problem of saving the Outlook item.
I haven't had problems in adding UserProperties to either Outlook or RDO
items in the Inbox, or after making items look sent when I do that.

You can instantiate an item.Open() event handler in NewInspector(). When
Open() fires you can close the Inspector in that event handler.

I used a timer, but an Open event handler might be a little more
deterministic -- thanks.

Outlook doesn't know about RDO* items until they are saved and you then
open an Outlook item based on the saved RDO* item.

I'm not really having any problems with RDO-created items, the problems
arise when manipulating the UserProperties collection of an item in RDO,
with expectation of seeing the effects of that manipulation in OOM.

When you do something like outlookMail.Subject = outlookMail.Subject you
tell Outlook something has changed in the item. Save it and then it
should be updated.

If the item has been changed/saved in RDO, and then you change it in OOM,
Outlook will refuse to save it and prompt the user to either create a
copy, or cancel.

In this instance I was most focused on inbox emails, that are somewhat
oblivious to changes; setting the follow-up flag causes the item to be
implicitly saved (though LastModificationTime is not updated) immediately
upon closing the dialog. If the item can't be saved, that implicit save
fails silently, Saved is set to false, and the user is prompted to save
changes when the item is closed, and then prompted again about being
unable to save/offer to make a copy.

Hmm it just occurred to me that this might only be a problem with inbox
(or maybe sent = true) emails. RDO-manipulated UserProperties on
contacts, tasks and calendar items are fine.

What I do if I don't want users to see, screw with or print properties
I've added to items is I bypass the UserProperties collections completely
(Outlook as well as RDO). I create a named MAPI property with RDO using a
name, the GUID for PS_PUBLIC_STRINGS and an item type (PT_STRING8,
PT_BOOLEAN, etc.). That PS_PUBLIC_STRINGS namespace is what's used for
the UserProperties collection, but since you aren't adding your property
to that binary blob the property is invisible to the UI elements. You can
only see it using a MAPI viewer like OutlookSpy or MFCMAPI.

Other than the extra code overhead of that approach, there is utility
value to the user to be able to see the user props in some cases, though
practically none of it applies to what a user might want to print. So the
RDOUserProperty.Printable property is a perfect fit here (it seems
unconscionable to me that OOM has no parallel mechanism, and that Outlook
offers no way to turn-off inclusion of user props in print-out, but I
digress.)

A perfect fit except, of course, for this little visibility glitch. I got
it to work, the close/re-open flash is a little chunky but probably
acceptable. I would surely love a peek under the hood at RDOMail.Display,
there must be some serious voodoo in there, to come up with an OOM item
that reflects all RDO property changes.


-MM

As it turns out, Inspector.Close from inside of NewInspector is ignored.
Also, comparing user properties is unnecessary, LastModificationTime is
enough.

-MM


Is it possible to add/change a UserProperty on an item using RDO, in
such a way that said addition/change is visible in the corresponding
OOM item (i.e., same EntryID) *without* having to restart Outlook?

And on a note that may seem entirely unrelated, but actually isn't
(from inside my head, if from nowhere else): how is it that
RDOMail.Display does not cause Inspectors.NewInspector to fire, even
though [AddIn App Instance/Application].ActiveInspector returns the
expected Inspector immediately after... oh wow, here's the undeniable
tie-in: that ActiveInspector (as opened by RDOMail.Display) has, of
course, a CurrentItem property, which, of course again, returns a
reference to an OOM item object -- *BUT* the RDO-altered UserProperties
*ARE* visible within it! However, if you close it and re-open by
double-clicking in the Explorer, those same UserProperties changes are
*not* there! Wow... that is... interesting...

I think it's time for 3 Excedrin Extra Strength's and a tripple gin and
tonic (no garbage... hold the ice... hell, hold the tonic too. Yep, a
juice glass full of straight gin... Not just for breakfast anymore...)

So... say I wanted to do something really quirky and niche, like making
sure my users never see my AddIn's user properties printed on paper,
even when they do quirky niche stuff like opening an item in the
Explorer, and even when they have the audacity to do so without having
restarted Outlook between emails (my users are funny like that, the
bastards!) When NewInspector fires, it's a safe bet that
RDOMail.Display was not involved, so, in that event handler I acquire
an RDO object reference to the item, compare its UserProperties against
those in CurrentItem, and if they are different, close the just-opened
Inspector and re-open it by calling RDOMail.Display... and manually
create a wrapper and add it to the collection, so my AddIn UI stuff is
there too (no other AddIn's stuff will be, but at least mine will, what
else matters?) Oh yeah, can't forget to move the new Inspector, since
it will be at the old inspector's client 0,0 (not its window 0,0.)

What are the chances that would work? Can you call Inspector.Close
from within NewInspector? Sounds like something that will work on my
system, but nut-up intermittently in the wild -- oh man I *can't*
*wait* to explain all this to my division manager when we meet today!
(It's what I live for.)


-MM