C # links and unexpected results

Question

I am relatively new to C # and Office automation, and recently I discovered that I was trying to get a link to someone from Outlook and sort emails by time of receipt. It did not work until I found a solution elsewhere on the Internet where Inbox is assigned to a local variable like Microsoft.Office.Interop.Outlook.Items, and then sorting is done on the local variable and it works. The question, however, is why? I thought there were links in C # objects and when you declare a new Outlook.Inbox link and then assign it items from the user's inbox, it just serves as an additional pointer to the actual emails and does not actually copy each of the letters to the new collection. So it should be no other than calling Sort by source link, right? Obviously, I am wrong, so I will be grateful for the explanation. Thanx !!

using Outlook = Microsoft.Office.Interop.Outlook; ... Outlook.Folder oInbox = (Outlook.Folder)oApp.Session.GetDefaultFolder(Outlook.OlDefaultFolders.olFolderInbox); oInbox.Items.Sort("[Received]", true); //this doesn't produce expected results Outlook.Items inboxFolder = (Outlook.Items)oInbox.Items; inboxFolder.Sort("[Received]", true); //this DOES sort the items! 

Answer 1

You are throwing (making (Outlook.Items)oInbox.Items ). Casting means that you are referring to an object of type X as type Y This is true in the following scenarios:

• X is inside the Y inheritance hierarchy (meaning that it is either the parent class Y or a child class Y ). In the case where X is the parent class, the cast will be executed only at runtime if the actual object has a value of Y (or a type derived from Y )
• Y is the type of interface that X implements.
• There is an explicit conversion defined from X to Y

Due to polymorphism, casting in the first case usually does not change the behavior of functions (although it can, if a more derived type explicitly hides the implementation of the parent). My suspicion, however, is that this is your scenario; type oInbox.Items is a type that inherits from Outlook.Items but hides the implementation of Outlook.Items.Sort . By explicitly dropping the parent type, you bypass the new child implementation. Please note that this technique only works when the child hides the function, and does not override the virtual function) .

The second case can change the behavior if X explicitly implements the function on Y that you are going to use. By choosing an interface, you explicitly tell the compiler that you want to associate the method call with the implementation of the interface, and not with the usual public-oriented method for the class itself.

The third almost always changes the behavior, since you get a completely different type (and, therefore, a completely different object).

I can’t say which of these cases applies to you, because I don’t have much experience with Office, but this should answer your main question: “How could it be otherwise?”

Answer 2

You are not creating a new Outlook.Inbox - you are creating a new link to an existing mailbox. Thus, the sorting is actually performed on the existing mailbox.