I was by no means satisfied with such state of things and started looking for solutions to fix the situation, but none of the proposed solutions provided satisfactory results and in the end I had to abandon the idea of interoperating with PowerPoint directly through COM. So the constructor for ApplicationClass must always be called with the argument MsoTriState.msoTrue. Source= " Microsoft Office PowerPoint 2007"Īt .t_Visible(MsoTriState Visible) Hiding the application window is not allowed." Message= " Application (unknown member) : Invalid request. It was a great disappointment to find that although PowerPoint’s COM interface and its managed wrapper seem to provide the ability to run the application invisibly, the feature is not indeed supported by PowerPoint 2007. Apparently the best way for the purposes of our application was to do it quietly, so that the user wouldn’t see the PowerPoint application window opening in the background and then closing in a few seconds. While that’s absolutely right, but there are some peculiar features which in the end made it necessary to look for alternative solutions.įirst, in order to acquire data from a presentation, it must be opened in PowerPoint. NET wrapper assemblies for COM interfaces which can be used to implement interaction with office applications like opening presentations programmatically, acquiring data from a presentation, launching slideshow etc. This task seems quite straightforward at first sight as there are.
It was important to find a way to acquire relevant information about a given presentation (number of slides, their names and thumbnail images) to build workflow for it. The real challenge of our project was to work out how we were going to import and, more important, play presentations. Re-hosting of workflow designer is not that straightforward, but it has already been described in details by Bruce Bukovics in his book and I guess I couldn’t add any valuable information to it. Actually the job of creating custom workflow activity classes is pretty straightforward and there’s not much to discuss. Also we decided to re-host the Visual Studio workflow designer in our application along with our custom classes for the workflow and its activities. We chose to create a WPF application to have access to the rich set of GUI development features provided by this technology. We were not sure whether this feature could be implemented by introducing an add-on for PowerPoint (you may argue if that’s not true, I’m still not sure) and for us that was another important argument in favor of building a separate application.
POWERPOINT VIEWER OFFICE XP WINDOWS
Also he wanted the application to display the presentation in two separate windows simultaneously one window was supposed to act as a controller form for switching between slides and the other just a non-interactive slideshow view. But our customer wanted to have a separate application rather than a customized version of PowerPoint.
I’m sure they are right, as the latest versions of the Microsoft Office applications provide rich API for extending their features moreover, nowadays add-ons for Office applications can be developed either in C#, VB.NET or any other CLR-compliant language. Some reader may reasonably suggest that customization of slide display order could be implemented by introducing an add-on module to the PowerPoint. Our customer wanted to have an application that would allow its users to customize the order in which slides are displayed by designing a workflow with conditional points and branching. This task emerged as part of a project which my teammates and I developed at Reliable Systems. On one occasion I came across an interesting and, I can even say, challenging task of building a customized player of PowerPoint presentations.