I blogged
yesterday about the issues I’m having with manually repurposing content.
One of the specific issues has to do with the Architecture Strategy
Series. We
provide that content via three channels – DVD, online seminars and
(soon) download. We use
Producer
to create the DVD and download files. However, online seminar system
doesn’t support Producer. The primary issue is that Producer uses the
Save as HTML version of the PPT, but the online seminar system only
supports static images. This means having to manually strip out the
animations, which is a pain in the ass. Since I don’t ever want to have
to do that again, I wrote a PowerPoint add-in to do it for me.
When you invoke the Build Slide Export
add-in
, it will step thru your presentation and screen capture each slide
build to disk. It’s very similar to the built in Save as JPEG/GIF/PNG
feature, except that it creates an image per build, not per slide. So
those complex build slides turn out multiple image files. It’s sort that
you can’t use the machine for anything else while it’s processing, but
it was really easy to write the code. I tested it on a long complex PPT
file with lots of builds (i.e. the one that took me hours to repurpose
on Monday) and it took about 10 minutes.
I’m also providing the
source
to the add-in. It’s not much code: maybe 150 lines of relevant code at
most. I grabbed the screen capture code from Perry Lee on C#
Corner.
There were a couple of gotchas involved with this add-in. For example,
the add-in project type uses version 7.0 of the office.dll that comes
with VS.NET. However, Office 2003 comes with version 11.0 of that DLL
and not 7.0, so the first time I went to deploy on my production
machine, it didn’t work. I had to grab the right version of office.dll
out of the GAC in order to reference it, so it’s included in the lib
directory of the source archive (it looks like
Simon did something similar with
Niobe). Also, PowerPoint’s
object model is a little funky. Specifically, SlideShowView.Next() has
to be called differently depending on the types of builds in the slides.
I handle four different scenarios in the code: no builds, only auto
trigger builds, and manual trigger builds, optionally with a set of auto
trigger builds before the first manual trigger build.
I’m sure there’s other enhancements that could be made – for example,
the directory the images are saved isn’t selectable nor is the image
format. If there’s any interest, I’ll spin up a GDN workspace.
Update: I just noticed a bug, albiet a cut-and-paste bug on my part.
Turns out the screen capture
code that
I used is creating four image objects for each screen capture. To make
matters worse, three of them are never assigned to a variable, so you
can’t call Dispose() on them. So for any real-sized presenation, memory
usage goes thru the roof. It’s relatively easy to fix. Take the code
that looks like this:
Bitmap image = new Bitmap(
Image.FromHbitmap(new IntPtr(hBitmap)),
Image.FromHbitmap(new IntPtr(hBitmap)).Width,
Image.FromHbitmap(new IntPtr(hBitmap)).Height);
image.Save(fileName,imageFormat);
And replace it with this:
Bitmap image = Image.FromHbitmap(new IntPtr(hBitmap));
image.Save(fileName,imageFormat);
image.Dispose();
With the improved code, only one bitmap per screen capture is made, and
it’s explicitly disposed. That keeps memory usage under control.
Another Update: I’ve updated the binary and the code links above
with the new v1.0.1 version that fixes the memory hogging problem.