David, Thanks, I appreciate that. I have tried editing in place without adding or subtracting bytes (trying to keep things as simple as possible) but no luck.
I will re-post this on the Developer thread. Thanks for recommending that. Sean On Fri, May 2, 2008 at 1:00 PM, David Fisher <[EMAIL PROTECTED]> wrote: > 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] > >
