Sean,
Yegor can answer in greater detail, I know he has been looking into
the OLE embedding within HSLF. It is an interest of ours.
The thing to know is that the PPT file format is a binary format that
includes offsets to objects, and you can't just insert something into
the middle without fixing up these references.
So, if all you did was change an attribute you can get away with
hacking "in place" - but if you add or subtract bytes you are out of
luck as powerpoint loses its references.
Again I think your needs are right on the edge of what is being
developed and if you brought this over to the developer list you would
get a lot of help if you wanted to contribute to this.
Regards,
Dave
On May 2, 2008, at 12:19 PM, Sean Eby wrote:
Hi,
I've been working with hslf reading/writing .PPT files with some
success.
However, I want to change a property of an embedded Flash ActiveX
control.
PowerPoint binary format stores this as a docfile stream inside the
PowerPoint file within a record of type ExOleObjStg (record type
#4113). You
can get at the uncompressed stream, of course, by calling getData()
on the
specific record object.
I can get at the data that represents the ActiveX Flash control just
fine
and can see using a hex editor some various properties. However,
when I try
to update any characters in-place and save the .PPT back out, it
often will
open with an error (strangely, sometimes changing a single byte does
not
result in an error).
Here is a sample of a stream that is storing the ActiveX data that
that
Flash OCX apparently reads:
http://skitch.com/speby/k1s3/a
The above example shows a part of the data inside after calling
getData() on
an ExOleObjStg which is the embedded Flash ActiveX (.OCX) data. The
Movie
property, in the above example is set to lowercase 'a' for the
curious.
I have gone through a few basic reverse-engineering trials whereby I
save a
.PPT with a single Flash ActiveX control and only change the movie
property.
One .PPT with a Flash Movieproperty 'a', one with Movie property
'b', and so
on for a few more.
The only differences in the output I see above between each of those
successive iterations is in the 4 bytes at offset 1008 (2A 55 00 00)
and the
4 bytes right after at offset 100C (B4 3A 00 00). That's all
thatchanges.
Given this and the very small changes I was making in each, the
values that
were being saved out at those two offsets are wildly different. My
only
conclusion, thus far, is that those 8 bytes represent some kind of
checksum,
perhaps, but have no way to practically verify that in any
reasonable amount
of time. What I don't know is whether those are specific to the
Flash OCX
control itself or are they specific to the ActiveX IStorage
interface on
Windows or something else entirely?
I was hoping, maybe, just maybe, someone here knew enough about and
could
provide any inside as to what is going on here. I realize there is not
specific record type for these and it might even be outside the
realm of the
POI project if this is Flash-specific data.
Any ideas? I know it's a stretch but any feedback is welcome.
Thanks.
Sean
p.s.
I am aware that one can use COM interop and get effect I am after
but I
would like to avoid that if I can.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
