none
Cancel move/copy of a MailItem using Quicksteps RRS feed

  • Question

  • Hi,

    i am intercepting Copy/Move-Operations using the BeforeItemPaste event. We have the ability to cancel the operation by setting the Cancel-bool to true.

    This works great except for Items that are copied/moved using QuickSteps or Rules or Contextmenu/Move.

    Could someone tell me how to intercept/abort this operations?

    The reason we need the cancel-functionality is that some items are not allowed to be moved to specific folders on an IMAP-Account.

    Thanks!

    Tuesday, July 10, 2012 2:10 PM

Answers

  • Hi!

    Overall, this scenario has two approaches that can be taken, each with its own set of challenges. #1 is recommended if at all possible since it was specifically designed for these types of scenarios.

    1. Implement the BeforeItemMove event on all folders. This is really the key event that was added in semi-recent versions of Outlook to control item movements. As Ken mentioned, the challenge here is being able to handle many folders, but I know customers who have gotten this work with many, many folders. However, I'm not aware of any hard limits. There were quite a few issues in Outlook 2007 and 2010 with this event that have been fixed, so be sure to use the latest service pack for both versions.

    2. As with the route you are going, you can try to hook into Outlook's UI to prevent users from doing these types of copy/move operations, but as you can see, there are a lot of entry points. I generally would not recommend this approach for two main reasons: A) It tends to fall into the "mousetrap" category and will likely have some scenarios that just can't be covered, and B) Outlook's UI tends to change more than its data-based events in the object model, so the more you integrate with Outlook's UI, the more likely you would need to update this to work with later versions.

    With Outlook's object model, data integration is generally preferred over UI integration approaches. So before we go any further down the #2 route, did you try implementing the BeforeItemMove approach, and if so, what issue did you run into there?

    Also, I presume you need to intercept these items being added to the IMAP folders before the copy/move actually happens?


    Bill Jacob - Microsoft Customer Service & Support - Developer Messaging


    • Edited by Bill Ja - MSFT Friday, August 17, 2012 6:58 PM
    • Marked as answer by Mancom_BWE Tuesday, August 21, 2012 9:19 PM
    Friday, August 17, 2012 6:57 PM

All replies

  • You can't directly intercept those actions. You could handle the Items.ItemAdd() and ItemRemove() events, although neither can be canceled and ItemRemove() fires after the item is deleted/moved.
     
    An alternative might be to use the Folder.BeforeItemMove() event, which can be canceled and which provides the MoveTo folder as an argument. That would be sort of backwards though, as it would be firing on the folder where the items are moved from, not the destination folder.

    --
    Ken Slovak
    [MVP-Outlook]
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
    "Mancom_BWE" <=?utf-8?B?TWFuY29tX0JXRQ==?=> wrote in message news:e36f5cdd-acb8-4c2f-9cd5-cac9aac4f191...

    Hi,

    i am intercepting Copy/Move-Operations using the BeforeItemPaste event. We have the ability to cancel the operation by setting the Cancel-bool to true.

    This works great except for Items that are copied/moved using QuickSteps or Rules or Contextmenu/Move.

    Could someone tell me how to intercept/abort this operations?

    The reason we need the cancel-functionality is that some items are not allowed to be moved to specific folders on an IMAP-Account.

    Thanks!


    Ken Slovak MVP - Outlook
    Tuesday, July 10, 2012 2:22 PM
  • Thank you again for the answer!

    I have to accept that Copy-Actions cannot be intercepted to trigger some business logic - only for Move-Actions exist some limited methods (but they do not trigger if mail rules are executed for example). So i check on regular intervals if there exist some client-side-rules that interfere with my logic and disable them if needed.

    All QuickSteps-Groups i have also disabled (in mail item contextmenu, the read mail inspector ribbon and explorer ribbon).

    But Copy-Actions are still a problem. So i decided to disable the CopyToFolder command too (all other copy-commands can be intercepted using BeforeItemPaste).

    This worked fine for the TabReadMessage/GroupMoveActions which i have made invisible an rebuilt it from scratch:

    <?xml version="1.0" encoding="utf-8"?>
    <customUI onLoad="Ribbon_Load" xmlns="http://schemas.microsoft.com/office/2009/07/customui">
      <ribbon>
        <tabs>
          <tab idMso="TabReadMessage" getVisible="Inspector_GetVisible">
            <group idMso="GroupQuickSteps" visible="false" />
            <group id="TabReadMessageNewGroupMoveActions" label="Move" insertBeforeMso="GroupMessageOptions">
              <menu idMso="MoveToFolderMenu" size="large">
                <button idMso="CopyToFolder" visible="false"/>
                <button idMso="AlwaysMoveConversation" visible="false"/>
                <button idMso="StopMovingConversation" visible="false"/>
              </menu>
              <gallery idMso="AlwaysMoveToFolder" />
              <button idMso="MoveToOneNote"/>
              <menu idMso="MoveActionsMenu">
                <menu idMso="OtherActionsMenu"/>
              </menu>
            </group>
            <group idMso="GroupMoveActions" visible="false"/>
          </tab>
        </tabs>
      </ribbon>
    </customUI>
    

    But it did not work for TabMail and ContextMenuMailItem:

    <?xml version="1.0" encoding="utf-8"?>
    <customUI onLoad="Ribbon_Load" xmlns="http://schemas.microsoft.com/office/2009/07/customui">
      <ribbon>
        <tabs>
          <tab idMso="TabMail" getVisible="Explorer_MailItem_GetVisible">
            <group idMso="GroupQuickSteps" visible="false" />
    
            <group id="TabMailNewGroupMoveActions" label="Move" insertBeforeMso="GroupRss">
               <gallery idMso="MoveToFolderGallery" size="large">
                <button idMso="CopyToFolder" visible="false"/>
                <button idMso="AlwaysMoveConversation" visible="false"/>
                <button idMso="StopMovingConversation" visible="false"/>
              </gallery>
              <gallery idMso="AlwaysMoveToFolder" size="large"/>
              <button idMso="MoveToOneNote" size="large"/>
            </group>
    
            <group idMso="GroupMoveActions" visible="true"/>
          </tab>
        </tabs>
      </ribbon>
      <contextMenus>
        <contextMenu idMso="ContextMenuMailItem">
          <button idMso="Reply" getVisible="Explorer_MailItem_GetVisible"/>
          <button idMso="ReplyAll" getVisible="Explorer_MailItem_GetVisible"/>
          <button idMso="Forward" getVisible="Explorer_MailItem_GetVisible"/>
          <button idMso="AlwaysMoveConversation" visible="false"/>
          <gallery idMso="AlwaysMoveToFolder" visible="false"/>
          <button idMso="CopyToFolder" visible="false"/>
          <gallery idMso="QuickStepsMenuGallery" visible="false"/>
          <gallery idMso="QuickStepsGallery" visible="false"/>
          <gallery idMso="MoveToFolderGallery" visible="false">
          </gallery>
        </contextMenu>
      </contextMenus>
    </customUI>
    

    It always gives me the Outlook-GUI-Error "Some Properties of integrated Controls cannot be modified: CopyToFolder" (translated from german language).

    Some Properties of integrated Controls cannot be modified: CopyToFolder

    The MoveToFolder-functionality is essential because we deal with a lot of folders - we cannot deactivate it.

    I really do not know how to solve this problem - i hope you can help me!

    Thank you!

    Monday, July 16, 2012 12:41 AM
  • I would instead use ribbon command repurposing for that. See http://msdn.microsoft.com/en-us/library/bb462633(v=office.12).aspx for an article about repurposing controls.
     
    You can intercept the click event on a repurposed control and perform some actions before handing over control to the default handler. You can also cancel the default action

    --
    Ken Slovak
    [MVP-Outlook]
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
    "Mancom_BWE" <=?utf-8?B?TWFuY29tX0JXRQ==?=> wrote in message news:75d302ab-267c-487f-8d81-e75cff6daa96...

    Thank you again for the answer!

    I have to accept that Copy-Actions cannot be intercepted to trigger some business logic - only for Move-Actions exist some limited methods (but they do not trigger if mail rules are executed for example). So i check on regular intervals if there exist some client-side-rules that interfere with my logic and disable them if needed.

    All QuickSteps-Groups i have also disabled (in mail item contextmenu, the read mail inspector ribbon and explorer ribbon).

    But Copy-Actions are still a problem. So i decided to disable the CopyToFolder command too (all other copy-commands can be intercepted using BeforeItemPaste).

    This worked fine for the TabReadMessage/GroupMoveActions which i have made invisible an rebuilt it from scratch:

    <?xml version="1.0" encoding="utf-8"?>
    <customUI onLoad="Ribbon_Load" xmlns="http://schemas.microsoft.com/office/2009/07/customui">
      <ribbon>
        <tabs>
          <tab idMso="TabReadMessage" getVisible="Inspector_GetVisible">
            <group idMso="GroupQuickSteps" visible="false" />
            <group id="TabReadMessageNewGroupMoveActions" label="Move" insertBeforeMso="GroupMessageOptions">
              <menu idMso="MoveToFolderMenu" size="large">
                <button idMso="CopyToFolder" visible="false"/>
                <button idMso="AlwaysMoveConversation" visible="false"/>
                <button idMso="StopMovingConversation" visible="false"/>
              </menu>
              <gallery idMso="AlwaysMoveToFolder" />
              <button idMso="MoveToOneNote"/>
              <menu idMso="MoveActionsMenu">
                <menu idMso="OtherActionsMenu"/>
              </menu>
            </group>
            <group idMso="GroupMoveActions" visible="false"/>
          </tab>
        </tabs>
      </ribbon>
    </customUI>
    

    But it did not work for TabMail and ContextMenuMailItem:

    <?xml version="1.0" encoding="utf-8"?>
    <customUI onLoad="Ribbon_Load" xmlns="http://schemas.microsoft.com/office/2009/07/customui">
      <ribbon>
        <tabs>
          <tab idMso="TabMail" getVisible="Explorer_MailItem_GetVisible">
            <group idMso="GroupQuickSteps" visible="false" />
    
            <group id="TabMailNewGroupMoveActions" label="Move" insertBeforeMso="GroupRss">
               <gallery idMso="MoveToFolderGallery" size="large">
                <button idMso="CopyToFolder" visible="false"/>
                <button idMso="AlwaysMoveConversation" visible="false"/>
                <button idMso="StopMovingConversation" visible="false"/>
              </gallery>
              <gallery idMso="AlwaysMoveToFolder" size="large"/>
              <button idMso="MoveToOneNote" size="large"/>
            </group>
    
            <group idMso="GroupMoveActions" visible="true"/>
          </tab>
        </tabs>
      </ribbon>
      <contextMenus>
        <contextMenu idMso="ContextMenuMailItem">
          <button idMso="Reply" getVisible="Explorer_MailItem_GetVisible"/>
          <button idMso="ReplyAll" getVisible="Explorer_MailItem_GetVisible"/>
          <button idMso="Forward" getVisible="Explorer_MailItem_GetVisible"/>
          <button idMso="AlwaysMoveConversation" visible="false"/>
          <gallery idMso="AlwaysMoveToFolder" visible="false"/>
          <button idMso="CopyToFolder" visible="false"/>
          <gallery idMso="QuickStepsMenuGallery" visible="false"/>
          <gallery idMso="QuickStepsGallery" visible="false"/>
          <gallery idMso="MoveToFolderGallery" visible="false">
          </gallery>
        </contextMenu>
      </contextMenus>
    </customUI>
    

    It always gives me the Outlook-GUI-Error "Some Properties of integrated Controls cannot be modified: CopyToFolder" (translated from german language).

    Some Properties of integrated Controls cannot be modified: CopyToFolder

    The MoveToFolder-functionality is essential because we deal with a lot of folders - we cannot deactivate it.

    I really do not know how to solve this problem - i hope you can help me!

    Thank you!


    Ken Slovak MVP - Outlook
    Monday, July 16, 2012 3:42 PM
  • I read about that, but thought that it would not be possible (in that granularity i need). For some reason it is possible to enable/disable items or insert some items to MoveToFolderMenu but not to MoveToFolder Gallery. I don't know the difference - the look exactly the same in the GUI.

    I will try to repurpose for Menu and Gallery next week and report back if it has worked for both.

    Thank you very much!

    Thursday, July 19, 2012 3:32 PM
  • Hi Mancom_BWE,

    Thanks for posting in the MSDN Forum.

    Any update?

    Have a good day,

    Tom


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us

    Tuesday, August 7, 2012 8:57 AM
    Moderator
  • Hi Tom,

    yes, i have tried repurposing the controls, it does not work. Outlook seems to treat this controls as some kind of protected ones.

    It is not possible to enable/disable them, nor can you make them visible/invisible, nor can they be repurposed.

    An error is thrown as posted above...

    Some controls need to be specified with different IDs, this article (http://msdn.microsoft.com/en-us/library/aa722523(office.12).aspx) is for Office 2007, not for 2010 - but there may be such a translation table for Outlook 2010 too?

    I have absolute no solution for that problem - do you have any idea?

    Thanks!

    Tuesday, August 7, 2012 4:51 PM
  • Hi Mancom_BWE,

    I will involve some experts into your issue to see whether they can help you. There might be some time delay, tanks for you patience.

    Have a good day,

    Tom


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us

    Thursday, August 9, 2012 5:24 AM
    Moderator
  • Hi!

    Overall, this scenario has two approaches that can be taken, each with its own set of challenges. #1 is recommended if at all possible since it was specifically designed for these types of scenarios.

    1. Implement the BeforeItemMove event on all folders. This is really the key event that was added in semi-recent versions of Outlook to control item movements. As Ken mentioned, the challenge here is being able to handle many folders, but I know customers who have gotten this work with many, many folders. However, I'm not aware of any hard limits. There were quite a few issues in Outlook 2007 and 2010 with this event that have been fixed, so be sure to use the latest service pack for both versions.

    2. As with the route you are going, you can try to hook into Outlook's UI to prevent users from doing these types of copy/move operations, but as you can see, there are a lot of entry points. I generally would not recommend this approach for two main reasons: A) It tends to fall into the "mousetrap" category and will likely have some scenarios that just can't be covered, and B) Outlook's UI tends to change more than its data-based events in the object model, so the more you integrate with Outlook's UI, the more likely you would need to update this to work with later versions.

    With Outlook's object model, data integration is generally preferred over UI integration approaches. So before we go any further down the #2 route, did you try implementing the BeforeItemMove approach, and if so, what issue did you run into there?

    Also, I presume you need to intercept these items being added to the IMAP folders before the copy/move actually happens?


    Bill Jacob - Microsoft Customer Service & Support - Developer Messaging


    • Edited by Bill Ja - MSFT Friday, August 17, 2012 6:58 PM
    • Marked as answer by Mancom_BWE Tuesday, August 21, 2012 9:19 PM
    Friday, August 17, 2012 6:57 PM
  • Hi Bill!

    Thank you again for your help. Unfortunately we have to deal with much more than thousand folders.

    In the meanwhile the customer accepted the (partly) solution i developed.

    I mya try that later, but i guess that enumerating the folders and subscribing the events will take (at startup) too long - and maybe will not work because of the huge number of folders.

    Thank you very much for helping!

    Tuesday, August 21, 2012 9:19 PM