<?xml version="1.0"?><?xml-stylesheet type="text/xsl" href="http://www.codeplex.com/rss.xsl"?><rss version="2.0"><channel><title>MFCMAPI Work Item Rss Feed</title><link>http://www.codeplex.com/MFCMAPI/WorkItem/List.aspx</link><description>MFCMAPI Work Item Rss Description</description><item><title>Closed Task: Sort List Shutdown Spends a Long Time Deleting Columns [9166]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9166</link><description>Problem&amp;#58; Noticed during debug we spent a lot of cycles in DeleteAllColumns.&lt;br /&gt;Fix&amp;#58; We don&amp;#39;t have any specific need to delete the columns. Better to leave them alone and let the control handle the deletion. Presumably the control will be more efficient than manually deleting column by column. Created flag to signal the deletion is happening during shutdown and if so just handle my own memory cleanup.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:54:10 GMT</pubDate><guid isPermaLink="false">Closed Task: Sort List Shutdown Spends a Long Time Deleting Columns [9166] 20091117045410P</guid></item><item><title>Closed Task: People Keep Running Wrong Version of MFCMAPI [9156]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9156</link><description>Problem&amp;#58; People keep pulling the 64 bit build even though they do not have 64 bit MAPI.&lt;br /&gt;Fix&amp;#58; Can&amp;#39;t make people not stupid, but can rework the error dialog to be clearer that they have been stupid. Wrong version error is now customized for 64 and 32 bit builds.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:54:08 GMT</pubDate><guid isPermaLink="false">Closed Task: People Keep Running Wrong Version of MFCMAPI [9156] 20091117045408P</guid></item><item><title>Closed Feature: Smart View is Wicked Cool, but Can I Turn it Off? [9155]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9155</link><description>Problem&amp;#58; Any bug in Smart View parsing can make MFCMAPI crash whenever the props are looked at, making it unusable.&lt;br /&gt;Fix&amp;#58; Add an option to turn the parsing off to mitigate problems after someone discovers a smart view parsing bug.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:54:08 GMT</pubDate><guid isPermaLink="false">Closed Feature: Smart View is Wicked Cool, but Can I Turn it Off? [9155] 20091117045408P</guid></item><item><title>Closed Task: Smart View Column on Non-Smart View MV Props [9154]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9154</link><description>Problem&amp;#58; Most MV props do not have smart view parsing, but this column showed anyway.&lt;br /&gt;Fix&amp;#58; Only display the column for long and binary types.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:54:07 GMT</pubDate><guid isPermaLink="false">Closed Task: Smart View Column on Non-Smart View MV Props [9154] 20091117045407P</guid></item><item><title>Closed Task: Can't Manually Edit CRLF in Properties [9153]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9153</link><description>Problem&amp;#58; Occasionally, we need fine control over the number&amp;#47;location of CR and LF &amp;#40;0xD, 0xA&amp;#41; in a string property. Rich Edit control canonicalizes line endings, eliminating this kind of control.&lt;br /&gt;Fix&amp;#58; Can&amp;#39;t fix the Rich Edit control, but can make sure that if we edit the binary version of the text that this change is kept. Key is not reading final value from the rich edit control but instead reading it from the hex.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:54:05 GMT</pubDate><guid isPermaLink="false">Closed Task: Can't Manually Edit CRLF in Properties [9153] 20091117045405P</guid></item><item><title>Closed Issue: PropTagEditor Can't Do Named Prop Lookup [9152]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9152</link><description>Problem&amp;#58; Opening the dialog and filling out named prop information never got a prop ID.&lt;br /&gt;Fix&amp;#58; This was a bug in my new caching code - CacheGetIDsFromNames was returning the lookup up value in the wrong format. This was the only case that actually hit this lookup.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:54:04 GMT</pubDate><guid isPermaLink="false">Closed Issue: PropTagEditor Can't Do Named Prop Lookup [9152] 20091117045404P</guid></item><item><title>Closed Task: DisplayObject Dialog Confuses People [9151]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9151</link><description>Problem&amp;#58; Even though it&amp;#39;s just informational and not an error, keep getting error reports when people display it.&lt;br /&gt;Fix&amp;#58; Cut it. Replace it with debug spew.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:54:02 GMT</pubDate><guid isPermaLink="false">Closed Task: DisplayObject Dialog Confuses People [9151] 20091117045402P</guid></item><item><title>Closed Issue: Smart View Crash Handling Large Security Descriptor [9150]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9150</link><description>Problem&amp;#58; Large security descriptors tripped a problem FormatMessage has with large strings.&lt;br /&gt;Fix&amp;#58; Massage code not to pass potentially large strings to FormatMessage and instead concatenate them manually.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:54:00 GMT</pubDate><guid isPermaLink="false">Closed Issue: Smart View Crash Handling Large Security Descriptor [9150] 20091117045400P</guid></item><item><title>Closed Feature: OpenStreamOnFileW Not Implemented [9148]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9148</link><description>Problem&amp;#58; Outlook just documented this cool function&amp;#58; http&amp;#58;&amp;#47;&amp;#47;blogs.msdn.com&amp;#47;stephen_griffin&amp;#47;archive&amp;#47;2009&amp;#47;09&amp;#47;29&amp;#47;openstreamonfile-vs-unicode-files.aspx&lt;br /&gt;Fix&amp;#58; Import it, use it in the file dialog Unicode change. Make sure wrapper function, MyOpenStreamOnFile, properly handles case when function is not available.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:53:59 GMT</pubDate><guid isPermaLink="false">Closed Feature: OpenStreamOnFileW Not Implemented [9148] 20091117045359P</guid></item><item><title>Closed Task: New/Missing Props [9147]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9147</link><description>Problem&amp;#58; Tweaking our prop set. PidTagScheduleInfoDelegateNamesW should be MV_UNICODE. PR_ASSOCIATED_SHARING_PROVIDER was missing.&lt;br /&gt;Fix&amp;#58; Fix it.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:53:59 GMT</pubDate><guid isPermaLink="false">Closed Task: New/Missing Props [9147] 20091117045359P</guid></item><item><title>Closed Issue: NULL parent Dialog Clicking Up/Down In Messages [9146]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9146</link><description>Problem&amp;#58; When using the form viewer to look at messages on an Outlook box, clicking the up&amp;#47;down button on the message to move to the next&amp;#47;previous message pops a dialog&amp;#58;&lt;br /&gt;&amp;#34;Form Viewer created with a NULL parent&amp;#33;&amp;#34;&lt;br /&gt;This is fallout from my work to ensure windows were properly parented. This dialog was left in to identify missed cases. Problem was OpenMessageNonModal had no way to pass in an HWND for a parent, so we always had to guess. Opening a message and hitting next message got us into a situation where we could not guess.&lt;br /&gt;Fix&amp;#58; Add an HWND parameter to OpenMessageNonModal and use it.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:53:58 GMT</pubDate><guid isPermaLink="false">Closed Issue: NULL parent Dialog Clicking Up/Down In Messages [9146] 20091117045358P</guid></item><item><title>Closed Issue: Smart View Parsing for MV Binary Props Gets Confused [9145]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9145</link><description>Problem&amp;#58; The hack I put in for parsing MV props last time got confused if we had parsing for two props with the same id, but one was MV and the other wasn&amp;#39;t.&lt;br /&gt;Fix&amp;#58; Broke the Smart View parsing logic out of InterpretProp - it&amp;#39;s out of the SmartView business. Introduced new function, InterpretPropSmartView, to handle SV parsing. New function takes a BOOL to signal if the prop being parsed a row from a MV prop. Added new column to BINARY_STRUCTURE_ARRAY_ENTRY to note whether the structure was an MV prop or not. All this gives us enough information to pick the right parser.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:53:56 GMT</pubDate><guid isPermaLink="false">Closed Issue: Smart View Parsing for MV Binary Props Gets Confused [9145] 20091117045356P</guid></item><item><title>Closed Issue: Aborting Table Load Expensive and Slow [9144]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9144</link><description>Problem&amp;#58; Thread synchronization was poorly handled, using SendMessage to check if we should abort thread load in DwThreadFuncLoadTable.&lt;br /&gt;Fix&amp;#58; Use proper sync logic so we can check a flag for abort, avoiding the SendMessage call. Since the check is much cheaper now, fixed the code to check more often, making the abort more responsive. Also simplified the wait for shutdown loop in OnCancelTableLoad, as part of the code cleanup to fix the message swallowing issue that broke Close All.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:53:55 GMT</pubDate><guid isPermaLink="false">Closed Issue: Aborting Table Load Expensive and Slow [9144] 20091117045355P</guid></item><item><title>Closed Issue: Context Menus on Wrong Screen [9143]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9143</link><description>Problem&amp;#58; On multimon, conext menus were showing on the default monitor, not the screen where they were triggered.&lt;br /&gt;Fix&amp;#58; There&amp;#39;s some voodoo I don&amp;#39;t quite get in parsing the lparam for WM_CONTEXTMENU. Fortunately, we can override OnContextMenu and use the passed in pos, which has been corrected for multimon.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:53:54 GMT</pubDate><guid isPermaLink="false">Closed Issue: Context Menus on Wrong Screen [9143] 20091117045354P</guid></item><item><title>Closed Issue: File Picker Treats Unicode Characters as ? [9142]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9142</link><description>Problem&amp;#58; We&amp;#39;re using the MFC CFileDialog class to select files. This class is ANSI only in non-unicode builds.&lt;br /&gt;Fix&amp;#58; Abandon CFileDialog and my child class CFileDialogEx and reimplement it so we can choose ANSI or UNICODE flavors. Introduce CFileDialogExA&amp;#47;CFileDialogExW and macro CFileDialogEx which behaves like the old class. Reimplementation takes only the core of what we need from CFileDialog. Duplicate implementations for now - will later look at implementing CFileDialogExA as a wrapper around CFileDialogExW.&lt;br /&gt;&lt;br /&gt;Had to chase a number of file handling routines through the code and convert them to Unicode. Note, in particular, wholesale changes to file.cpp.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:53:53 GMT</pubDate><guid isPermaLink="false">Closed Issue: File Picker Treats Unicode Characters as ? [9142] 20091117045353P</guid></item><item><title>Closed Issue: Error Viewing Non Embedded Attachments [9141]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9141</link><description>Problem&amp;#58; When the option is selected to view embedded message attachments as messages, selecting a regular attachment throws an error.&lt;br /&gt;Fix&amp;#58; Check for ATTACH_EMBEDDED_MSG and only attempt to open the PR_ATTACH_DATA_OBJ if this flag is set.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:53:52 GMT</pubDate><guid isPermaLink="false">Closed Issue: Error Viewing Non Embedded Attachments [9141] 20091117045352P</guid></item><item><title>Closed Issue: New Windows Center on Wrong Screen [9140]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9140</link><description>Problem&amp;#58; With multimon, we&amp;#39;re seeing our new windows show up only on the default monitor. They should appear on the same screen as the previous window.&lt;br /&gt;Fix&amp;#58; Override CheckAutoCenter to provide my own centering logic.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:53:51 GMT</pubDate><guid isPermaLink="false">Closed Issue: New Windows Center on Wrong Screen [9140] 20091117045351P</guid></item><item><title>Closed Task: CCH/CCHW Should be Replaced by _countof [9139]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=9139</link><description>Problem&amp;#58; Hand rolled CCH&amp;#47;CCHW macros are finicky and dangerous.&lt;br /&gt;Fix&amp;#58; Replace with built in _countof macro.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:53:50 GMT</pubDate><guid isPermaLink="false">Closed Task: CCH/CCHW Should be Replaced by _countof [9139] 20091117045350P</guid></item><item><title>Closed Task: Eliminate use of strsafe [7786]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=7786</link><description>last update of strsafe header raised warnings not to use strsafe anymore. Need to remove the header and scrub out references.&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:53:50 GMT</pubDate><guid isPermaLink="false">Closed Task: Eliminate use of strsafe [7786] 20091117045350P</guid></item><item><title>Closed Task: RES_COUNT Handling May Not be Correct [7785]</title><link>http://mfcmapi.codeplex.com/WorkItem/View.aspx?WorkItemId=7785</link><description>During code review, had some questions about how I handle this type - need to dig into the code and see if it&amp;#39;s correct&lt;br /&gt;</description><author>sgriffin</author><pubDate>Tue, 17 Nov 2009 16:53:48 GMT</pubDate><guid isPermaLink="false">Closed Task: RES_COUNT Handling May Not be Correct [7785] 20091117045348P</guid></item></channel></rss>