Fixed font
Subject: Re: Changes made using RDO, visibility in OOM
Author: Ken Slovak Date: 02 Jul 2010
References: 1 2 3 4
Author: Ken Slovak Date: 02 Jul 2010
References: 1 2 3 4
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.
"Mark McGinty" <mmcgintyNG@sSpUaCmKSdeprecatethis.com> wrote in message
news:sw8Xn.5346$OU6.5060@newsfe20.iad...
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.
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm
"Mark McGinty" <mmcgintyNG@sSpUaCmKSdeprecatethis.com> wrote in message
news:sw8Xn.5346$OU6.5060@newsfe20.iad...
>
> "Ken Slovak" <kenslovak@mvps.org> wrote in message
> news:i0ik3o$2q5$2@news.eternal-september.org...
> I used a timer, but an Open event handler might be a little more
> deterministic -- thanks.
>
>
> 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.
>
> 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.
>
> 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
>
>
>
>
> "Ken Slovak" <kenslovak@mvps.org> wrote in message
> news:i0ik3o$2q5$2@news.eternal-september.org...
>> You can instantiate an item.Open() event handler in NewInspector(). When
>> Open() fires you can close the Inspector in that event handler.
>>> 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.
>>> 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.
>>> 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.
>>> 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
>
>
>
>> --
>> Ken Slovak
>> [MVP - Outlook]
>> http://www.slovaktech.com
>> Author: Professional Programming Outlook 2007.
>> Reminder Manager, Extended Reminders, Attachment Options.
>> http://www.slovaktech.com/products.htm
>>
>>
>> "Mark McGinty" <mmcgintyNG@sSpUaCmKSdeprecatethis.com> wrote in message
>> news:LrMWn.13536$dx7.9244@newsfe21.iad...
>>> Ken Slovak
>> [MVP - Outlook]
>> http://www.slovaktech.com
>> Author: Professional Programming Outlook 2007.
>> Reminder Manager, Extended Reminders, Attachment Options.
>> http://www.slovaktech.com/products.htm
>>
>>
>> "Mark McGinty" <mmcgintyNG@sSpUaCmKSdeprecatethis.com> wrote in message
>> news:LrMWn.13536$dx7.9244@newsfe21.iad...
>>> As it turns out, Inspector.Close from inside of NewInspector is ignored.
>>> Also, comparing user properties is unnecessary, LastModificationTime is
>>> enough.
>>>
>>> -MM
>>>
>>>
>>> "Mark McGinty" <mmcgintyNG@sSpUaCmKSdeprecatethis.com> wrote in message
>>> news:svLWn.3195$cO.3062@newsfe09.iad...
>>>
>>>>> Also, comparing user properties is unnecessary, LastModificationTime is
>>> enough.
>>>
>>> -MM
>>>
>>>
>>> "Mark McGinty" <mmcgintyNG@sSpUaCmKSdeprecatethis.com> wrote in message
>>> news:svLWn.3195$cO.3062@newsfe09.iad...
>>>> 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
>>>>
>>>>
>>>>
>>>>>>> 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
>>>>
>>>>
>>>>
>>>
>
