poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Height, Jason" <jhei...@subcorp.com.au>
Subject RE: VOTE: DBCell and Index Record patches on 2.0 branch
Date Tue, 23 Sep 2003 05:05:58 GMT
The Index Records were being written (and probably still are on 2.0 branch)
but point to invalid DBCells record (which were NOT being written). That was
the case when a template was used anyway.


-----Original Message-----
From: Chris Nokleberg [mailto:chris@sixlegs.com] 
Sent: Tuesday, 23 September 2003 2:33 PM
To: POI Developers List
Subject: Re: VOTE: DBCell and Index Record patches on 2.0 branch

On Mon, Sep 22, 2003 at 11:15:32AM -0700, Andrew C. Oliver wrote:
> I don't think our problem is this.  I think what needs to be done is
> to diff the biffview of a blank sheet versus one poi modifies and see what
> extra records we write.  We never used to write these records and it used
> work (DBCELL/INDEX).  Thus I think we're writing too many records rather
> than too few.

FWIW I agree. DBCELL & INDEX should are optional--Excel should get along
OK without them. If you write a malformed INDEX record (e.g. pointing to
missing DBCELLs) it will of course cause problems, which is what sounds
like was happening.


To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org

This e-mail (including attachments) is confidential information of Australian Submarine Corporation
Pty Limited (ASC).  It may also be legally privileged.  Unauthorised use and disclosure is
prohibited.  ASC is not taken to have waived confidentiality or privilege if this e-mail was
sent to you in error. If you have received it in error, please notify the sender promptly.
 While ASC takes steps to identify and eliminate viruses, it cannot confirm that this e-mail
is free from them.  You should scan this e-mail for viruses before it is used.  The statements
in this e-mail are those of the sender only, unless specifically stated to be those of ASC
by someone with authority to do so.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message