During its development, we targeted BPC Logic Filter – our Add-In for analyzing project schedules – for use with Microsoft Project (MSP) 2010. After all, we developed the Add-In essentially for our own use, and MSP 2010 has been a regular tool for us (in Windows 7 boxes) since its inception. Our most recent computer purchase brought with it necessary upgrades to 2016 versions of MS Office and MSP, all running the 64-bit flavor on a Windows 10 Workstation.
Now that I’ve had a chance to directly test BPC Logic Filter in an MSP 2016 environment, I must apologize to those users of our software who have suffered in silence with their MSP 2016 (and also MSP 2013) installations. My initial testing experience with the filter functions was horribly slow, and I was finally able to repeat some crashing behavior – not encountered in MSP 2010 – that had been reported by a lone user. No wonder the representative feedback from users on MSP 2013 and 2016 has been, love the Task Logic Inspector! (but silent on the other stuff).
With recent updates, we’ve managed to speed up the filter functions while completely eliminating the particular crashing issue. As a result, with bar-coloring disabled, the new machine can complete a comprehensive Near-Longest Path Filter of a typical ~1000-task schedule in under 8 seconds. This compares to an 11-second analysis of the same schedule on the old machine; I attribute the improvement primarily to the increased processing speed of the new machine.
Bar-coloring, however, remains sub optimal. This is already time-consuming – manipulating Gantt bars and bar styles using essentially “foreground” processes. As a result, the time to generate our comprehensive Near-Longest Path Filter on the old (MSP 2010) machine increases from 11 seconds to 33 seconds when bar-coloring with auto-ranging is selected. Such an increase is justified by the improved communication that bar coloring allows. Unfortunately, the time to perform the same task on the new (MSP 2016) machine increased from 8 seconds to 46 seconds, even after our optimizations and adjustments. I would expect users with slower computers to have much worse experience. It seems that manipulating graphic display objects involves substantially more processing power in MSP 2016 than in MSP 2010. This is ironic in light of the general degradation in graphical output beginning with MSP 2013. Unfortunately, we have not yet found a way around this problem.
Finally, there seems to be a bug in MSP 2016’s handling of the GanttBarFormat method when a) the method originates in a VSTO (Visual Studio Tools for Office) Add-In rather rather than in a native VBA (Visual Basic for Applications) procedure; and b) there is actual progress on the task. (The GanttBarFormat method is used to apply format exceptions to a particular bar style of a particular task; like right-clicking on a bar and choosing “format bar”.) Unfortunately, MSP 2016 ignores the selected bar style and applies the exception to the “Task Progress” bar if one exists. This makes for some odd-looking outputs from our Add-In for schedules showing actual progress. I’ll have to figure out a way to raise this issue and get it fixed.