none
Data exposure

    Question

  • Hi All

    I have been "wrestling" with this problem both programmatically and conceptually.  When the "Ribbon Level" Reply function is selected (message only selected not opened) the address fields in the mailitem are not exposed.  I can get to the mailitem via the inspector_activate event and checking for "RE:" in the subject field but the ability to expose the address fields is nonexistent.  I have tried using both the safemailitem and the RDOmail item - no cigar.  The selection_change event does not provide and further "drilling" capability it is just simply another pathway to reach the mailitem.  If, however, I display the mailitem, i.e. ml.display (where ml is the mailitem object) I see the form with the address data!  This raises the following questions:  what "container" is being used to supply the data to the form in this case?  Also what "container" is being used to supply the data to the normally produced form?  Is this "clandestine" reservoir exposed if the mailitem is opened instead of simply selected?  I guess I am ultimately wondering why the model designers chose to implement this "analog data" exposure so prolific throughout the Outlook Object Model!  So would someone please tell me how to expose the address fields in the mailitem when the mailitem is only selected.  Thanks mucho in advance.

    Respectfully,

    Gordon Haas


    Gordon Haas

    Wednesday, February 27, 2013 2:53 PM

Answers

  • Hi All again

    I found the answer to this riddle after doing a lot of searching - actually it was while I was looking at a solution using MAPIUtils the savoir assignment line appeared:

           Set ml = Application.ActiveExplorer.Selection(1)

    where ml is the outlook mailitem.  The MAPIUtils solution was not needed once I implemented this new "retrieval" of the item data.  The part that is so frustrating with this solution is if I specify

    set ml = thisinspector.currentitem 

    where thisinspector is the active, current inspector, the mailitem is not populated!  But if I go back to the top level and work my way back to where I am - it does!  I have to assume that it is the "selection" hook that is making all the difference - if anybody knows I would appreciate confirmation on that.  It should be noted that the mailitem was saved in both cases.

    Respectfully,

    Gordon Haas


    Gordon Haas

    Wednesday, February 27, 2013 7:14 PM

All replies

  • Hi All again

    I found the answer to this riddle after doing a lot of searching - actually it was while I was looking at a solution using MAPIUtils the savoir assignment line appeared:

           Set ml = Application.ActiveExplorer.Selection(1)

    where ml is the outlook mailitem.  The MAPIUtils solution was not needed once I implemented this new "retrieval" of the item data.  The part that is so frustrating with this solution is if I specify

    set ml = thisinspector.currentitem 

    where thisinspector is the active, current inspector, the mailitem is not populated!  But if I go back to the top level and work my way back to where I am - it does!  I have to assume that it is the "selection" hook that is making all the difference - if anybody knows I would appreciate confirmation on that.  It should be noted that the mailitem was saved in both cases.

    Respectfully,

    Gordon Haas


    Gordon Haas

    Wednesday, February 27, 2013 7:14 PM
  • Hi Gordon,

    Glad to hear that you've solved your issue.

    Thank you for sharing your solution which might be very helpful to other community members.

    Best regards,


    Quist Zhang [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, March 01, 2013 7:20 AM
    Moderator