On 12/6/05, Charles Wyble <[EMAIL PROTECTED]> wrote: > Mark Slater wrote: > > I've just finished the framework of the Message Transport. > Very nice. > > I started > > over when someone (maybe that was Charles? I can't find the email now) > > pointed me to a much better, and recent, MessageTransport provider > > example on one of the MDSN blogs. > Don't go implicating me in your wild schemes to take over the world! > And yes it may have been me. I think I posted about some of the MSDN > blogs. I know Kervin has as well. > > It had a few advantages: cleaner > > code, modern code, well documented. I think my new version will also > > have fewer copyright issues, if any, because none of the actual code > > was copied verbatim (though I used their logging system, but that's > > somewhat easy to replace once this is installed in the OpenConnector > > codebase). > See what happens when M$ marketing doesn't dictate how the engieers > operate? You get clean succint code that actually works without bugs. > > > > I'm at the point where Outlook starts up, tells it to flush its inbound > > and outbound messages, and then it seems to shutdown. > Sounds like progress. > > I'd like to watch > > the status change, and I've implemented a MAPIStatus subclass, but I'm > > not sure where in Outlook I can actually observe the status of the > > message transport, and what state its in (part of the status row > > includes human-readable text associated with the current status code). You could watch transports status rows only under Outlook 2000 In Outlook XP and upper this part is broken. Outlook 2000 is the most MAPI compliant client. > Well. You could use SapiMapi: http://openconnector.org/sapimapi/ or > MapiSPY: http://mapispy.blogspot.com/ to watch it possibly. Or use > OutlookSpy: http://www.dimastr.com/outspy/ > > > > Starting next week, I'll be working on adding CalDAV calls to the code. > > If anyone has more insights into how Outlook deals with calendar data, > > especially in terms of addressability, this is the time to share them. There is undocumented COM component that converts iCalendar to MAPI and vice versa. Its interface is available in tlb. Function names are rather self exlanatory.
component is located in MIMEDIR.DLL. I've added spying of IMDCvt_iCal interface to MAPISpy. To see logs you neeed to enable spying CoCreateInstance function. > Well the last time you asked about it > (http://sourceforge.net/mailarchive/forum.php?thread_id=8949876&forum_id=14055) > I posted this URL > http://support.microsoft.com/default.aspx?scid=kb;en-us;899919 . > > Not sure if it helped at all. Don't ask me how I found that article. I > have no clue! > > > :) The only thing we suspect at this point is that they are CDO > > objects, but I haven't seen Outlook ever try to send them through a > > Message Transport. That may be a function of where the transport is > > placed in the MAPISVC file... haven't tried playing with that yet. > It appears that both CDO and Extended MAPI are used. The MSDN/KB article > has example code for each. Let me know if I can be of further assistance. Actualy we need Transport provider only for sending/receving meeting requests. As for appointments it is up to MsgStore to process storing/retreiving. > > Charles > > -- With best regards Henry ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ otlkcon-devel mailing list otlkcon-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
