Bug 8727 - Incorrect return types in DocumentSummaryInformation
Summary: Incorrect return types in DocumentSummaryInformation
Status: CLOSED FIXED
Alias: None
Product: POI
Classification: Unclassified
Component: HPSF (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-05-02 04:22 UTC by Drew Varner
Modified: 2004-11-16 19:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Varner 2002-05-02 04:22:55 UTC
The following two methods should return boolean primitives:

DocumentSummaryInformation.getScaleCrop()
DocumentSummaryInformation.getLinksDirty() 

Currently they return byte[], and are not implemented.

I'll take a stab at including the boolean variant (VT_BOOL) in 
hpsf/Property.java.

In the mean time, we ought to update the return types of these methods to 
boolean so users have a heads up. Neither of these methods are implemented, but 
the earlier we change this, the better I think.

I'd patch it but I can't access CVS through my dial-up proxy tonight.

- Drew
Comment 1 Rainer Klute 2002-05-02 08:11:48 UTC
I changed DocumentSummaryInformation.getLinksDirty() as requested, but I didn't
change DocumentSummaryInformation.getScaleCrop(). However, there is a method
DocumentSummaryInformation.getScale(). Is this the one you meant? Should we
change it's name to getScaleCrop()?
Comment 2 Drew Varner 2002-05-02 14:57:56 UTC
I think getScale() is fine. Microsoft names the attributSe scaleCrop but 
defines the PID for is as scale. 

msdn.microsoft.com/library/en-us/com/stgasstg_8vsj.asp 

I think getScale() is correct, as the PIDs are the best way to name them. I 
have found the naming of these things inconsistent from their originator.

- Drew
Comment 3 Andy Oliver 2002-05-02 15:45:22 UTC
as a general goal we often look to clarify names rather than keep the originals.
 MS deliberately makes theirs cryptic.  While its certain the inconsistancy will
cause some confusion, we're more here to provide OLE2CDF to Java programmers
than to provide Java to OLE2CDF programmers..  hopefully that makes sense as a
distinction.