DSOFile bug?

[Gorgoroth]

I have been using the DSOFile.dll for some time now to extract and modify
extended document properties. Lately however I noticed a problem: Whenever I
tried to write to a Property of a file that had no properties yet (a file
that my application had just created from a bytestream in this case), I would
get an Access Violation error.
With real OLE files (office documents mostly) this wasn't a problem, since
those always seem to have at least one property, however my current project
requires extended properties to be available in textfiles and other formats
as well.
If I used the Windows property-window to modify an extended property
(author, title, etc.), saved the changes and then ran my program everything
worked fine, this seemed to indicate that what I tried to do should in fact
be possible, using DSOFile however, it wasn't.
Luckily the dsofile installer provides you with the DLLs sourcecode, so I
was able to look through there and see if I found any obvious reasons for the
strange behavior.
When you open up the project and take a look at
CDsoSummaryProperties::GetPropertyFromList and
CDsoCustomProperties::GetPropertyFromList you will notice there is a
difference between these functions in the way they handle adding new items to
the list.
SummaryProperties (the one that didn't work for me) only allows adding new
items to the list if there is a previous item that can be linked to,
otherwise it would throw an E_ACCESSDENIED, exactly the error I was seeing.
I altered the sourcecode to simply pass NULL if no previous item existed,
however I was unsure if there was a reason for this limitation.
After compiling and including the new DSOFile.dll, my software seemed to
work fine, the problem was gone.
Now I wanted to head back and alter the CustomProperties GetPropertyFromList
as well, however on opening the file I noticed that that function already
does what I did as well, it checks wether a predecessor exists, otherwise it
passes NULL.
After some more testing it still appears that my changes are valid, the code
works as intended and no new errors have shown up, I'm still a little baffled
though. Why would CustomProperties include the (apperantly) right way of
adding a first item to a list, while SummaryProperties (in the same project)
did not?

Does anyone know if this behavior was intended and if my change will cause
further problems down the road that I'm not seeing at the moment? I don't
want to release a potentially dangerous, modified version of a Microsoft DLL
to my customers, however right now it seems to be the most feasible solution.

Sincerely,
Kevin Wienhold

 

[Jonathan West]

Hi Kevin

I rather suspect that you are using DSOFile for purposes it was never
intended for. I understand that it was really only ever intended for reading
& writing document properties in Office documents - Word, Excel and PPT.
Anything else you use it for is really at your own risk, and you will be on
your own as regards any problems you meet and workarounds you find. I've
never heard of any use of DSOFile for any other purpose.

In order to get closer to the metal and have more control over all this, you
might like to take a look at this article

How To Read Compound Document Properties Directly with VC++
http://support.microsoft.com/kb/186898/

As regards your question on SummaryProperties vs customProperties, in Office
documents, the SummaryProperties is a fixed list for any particular Office
file type. They aren't expecting you to add to it. The CustomProperties are
just that (custom) and you can add as many properties as you want.


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org

 

[Gorgoroth]

Thank you for your reply.
I know that DSOFile is intended to be used with compound documents only,
however it works with many other formats as well.
I have been using my own implementation of
IStream/IStorage/IPropertySetStorage etc. for some time, however I mainly
work in C# and the marshalling became a real hassle.
When I discovered that DSOFile could pretty much do anything I needed (even
though it was not officially supported), I felt that it would be a waste of
time to continue work on my own implementation.
While I do realize there is a logical difference between Summary- and
CustomProperties, from a technical point of view, they are the same thing.
You could even add to the SummaryProperties (using the API Functions
mentioned before), although you would run a high risk of messing up the GUIDs
or causing other problems for other programs.
However, even with that difference in mind, the different implementations in
the DSOFile-classes make no sense. While the SummaryProperties are clearly
defined, they are not always there either, the set gets created when the
first property is added, just like for CustomProperties (according to the
MSDN-Library at least).
So it should be possible to add a SummaryProperty-Value (with one of the
predefined GUIDs, of course) to a file that had none before.
As far as I can see, the current DSOFile.dll will throw an E_ACCESSDENIED
when you try to do this, that just seemed strange to me.
I realize that as of right now, the DSOFile.dll does everything it should
(since compound documents always have at least one property to link to), but
I still don't quite understand why you would put an artificial limitation
into your code to prevent something that otherwise seems to work fine.
That's pretty much the point of my previous post, I was interested to know
wether there was anyone who knew why Microsoft prevents you from adding the
first Property to a non-compound file (after one has been added through the
windows property window you can add as many more as you like using DSOFile),
while the DLLs seems to handle them fine everywhere else.
I know I'm using the DLL for something it is not intended to do, so I don't
expect any Microsoft support, I just wanted to know if anyone else had ever
tried something like this.
I just can't get it through my head why someone would willfully disable an
additional feature that would work fine if you just let it