RE: Bug + fix

[Height, Jason]

Michael 

I am sorry but I don't see what you mention below using the latest CVS.

Here is what I have done:
1) downloaded HEAD from CVS and compiled.
2) Downloaded the example excel file attached to:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27929
3) Put a debug statement at line 99 in ObjRecord: 
   System.out.println("sid: "+Integer.toHexString(subRecordSid)+", size:
"+Integer.toHexString(subRecordSize));
4) Created a workbook from this example file.

You will note that this line is before any fixups that occur in
subrecord for the size that your patch introduced.

Here is the output that I get (note values are in hex):
sid: 15, size: 12
sid: c, size: 14
sid: e, size: c
sid: 13, size: 20
sid: 0, size: 0

I certainly do not see the large record length that you mention. Am I
missing something, or has this been fixed "upstream" as I suggested
earlier. As such maybe the patch you mention below should be removed
from the SubRecord file.

To confirm this I also placed breakpoints (line 48 & 52) in SubRecord
where the "fixups" for adjusted size occur, and the debugger did not run
that code for the above excel file.

Jason

-Original Message-
From: Michael Zalewski [mailto:[EMAIL PROTECTED] 
Sent: Friday, 24 September 2004 1:17 PM
To: POI Developers List
Subject: RE: Bug + fix

I can vouch for this fix. In fact, at least four different users
(including
myself) have submitted almost exactly the same patch. Yet the bug
remains in
the source code.

The problem is the ftLbsData subrecord (type 0x13), which is interpreted
by
POI to have a very long length. The ftLbsData record is present whenever
you
have a dropdown in the worksheet, such as through user forms, or with
data
validation turned on. The record length on the ftLbsData record is
always a
value like 0x1fee, which I cannot interpret. 0x1fee may be some kind of
magic number, or it might be some kind of garbage if ftLbsData always
has a
fixed size. Every sheet I have looked at seems to have a 16 byte
ftLbsData
sub-record. I would very much like to see a sample spreadsheet where the
ftLbsData subrecord reports some length other than 0x1fee.

Take a look at the patch I submitted on
http://nagoya.apache.org/bugzilla/show_bug.cgi?id'929 (oddly enough, its
marked as fixed now, but the code does not seem to be in CVS). I even
supplied a Junit testcase. In my patch, I did this:

+short adjustedSize = size;
+if( size < 0) {
+   adjustedSize = 0;
+} else if( offset + size > data.length) {
+   adjustedSize = (short) (data.length - offset);
+   if( adjustedSize > 4) {
+  adjustedSize -= 4;
+   }
+}

This code is a little more thorough than Manjuka's proposed patch - it
handles negative lengths which might be found in the UnkonwnRecord. It
also
attempts to not eat the last 4 bytes of the OBJ record. That should be
an
ftEnd subrecord, and the ftEnd record always seems to be present, even
when
there is a ftLbsData subrecord with an incorrect length. An ftEnd record
is
always 4 bytes of 0x00, so the patch I provide tries to leave the last 4
bytes out of the UnkownRecord.


-Original Message-
From: Height, Jason [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 23, 2004 9:38 PM
To: POI Developers List
Subject: RE: Bug + fix

Manjuka,

Actually your fix doesn't look quite "right". I have usually found that
these kind of problems are caused by some other records up stream
reporting their size incorrectly. And therefore the downstream records
getting all mixed up by that byte offset.

If possible would you be able to create a bugzilla report and attach an
example spreadsheet and the code to reproduce the bug.

Maybe you could have a further look if possible.

Jason

-Original Message-
From: Manjuka Soysa [mailto:[EMAIL PROTECTED]
Sent: Friday, 24 September 2004 10:50 AM
To: '[EMAIL PROTECTED]'
Subject: Bug + fix


Hi,
I had a problem parsing some spreadsheets that had filters at the top
(combo-box type dropdowns).
Calling HSSFWorkbook constructor was throwing an array out of bounds
exception.
I traced the problem to UnknownRecord constructor. I have attached the
fix.
Old code:
public UnknownRecord( short id, short size, byte[] data, int offset
)
{
sid = id;
thedata = new byte[size];

System.arraycopy(data, offset, thedata, 0, size);
}

Fix:
public UnknownRecord( short id, short size, byte[] data, int offset
)
{
sid = id;
thedata = new byte[size];

int copyLength = Math.min(size, data.length - offset);

System.arraycopy(data, offset, thedata, 0, copyLength);
}

cheers,
Manjuka

This email and any attachments may contain privileged and confidential
information and are intended for the named addressee only. If you have
received this e-mail in error, please notify the sender and delete this

RE: Bug + fix

[Height, Jason]

Manjuka,

Actually your fix doesn't look quite "right". I have usually found that
these kind of problems are caused by some other records up stream
reporting their size incorrectly. And therefore the downstream records
getting all mixed up by that byte offset.

If possible would you be able to create a bugzilla report and attach an
example spreadsheet and the code to reproduce the bug. 

Maybe you could have a further look if possible.

Jason

-Original Message-
From: Manjuka Soysa [mailto:[EMAIL PROTECTED] 
Sent: Friday, 24 September 2004 10:50 AM
To: '[EMAIL PROTECTED]'
Subject: Bug + fix


Hi,
I had a problem parsing some spreadsheets that had filters at the top
(combo-box type dropdowns).
Calling HSSFWorkbook constructor was throwing an array out of bounds
exception.
I traced the problem to UnknownRecord constructor. I have attached the
fix.
Old code:
public UnknownRecord( short id, short size, byte[] data, int offset
)
{
sid = id;
thedata = new byte[size];

System.arraycopy(data, offset, thedata, 0, size);
}

Fix:
public UnknownRecord( short id, short size, byte[] data, int offset
)
{
sid = id;
thedata = new byte[size];

int copyLength = Math.min(size, data.length - offset);

System.arraycopy(data, offset, thedata, 0, copyLength);
}

cheers,
Manjuka

This email and any attachments may contain privileged and confidential
information and are intended for the named addressee only. If you have
received this e-mail in error, please notify the sender and delete this
e-mail immediately. Any confidentiality, privilege or copyright is not
waived or lost because this e-mail has been sent to you in error. It is
your responsibility to check this e-mail and any attachments for
viruses.  No warranty is made that this material is free from computer
virus or any other defect or error.  Any loss/damage incurred by using
this material is not the sender's responsibility.  The sender's entire
liability will be limited to resupplying the material.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: part2 of: DESPERATE, HELP: Problem with new HSSFWorkbook() in web unix server

[Height, Jason]

Steve

My suggestion is to put a try catch block around all of your code below
that will catch ANY exception, and print out the stack trace. That
surely will lead to the exact line in the code that is causing the
grief.

At the moment it is impossible to give you any further indication of
what the problem may be.

Jason

-Original Message-
From: Steve [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 21 September 2004 8:47 AM
To: [EMAIL PROTECTED]
Subject: part2 of: DESPERATE, HELP: Problem with new HSSFWorkbook() in
web unix server

By the way, I'm deploying with:  poi-2.5-final-20040302.jar
Are any other jars needed?
Is it possible this problem is related a previoous problem on this
second
unix server,
where I could not read in a xls template file? I resorted to revising my
code so
that I didn't need to read a template.
--steve
see below for problem description


--- 
>To:
[EMAIL PROTECTED]
>   PMSubject:  DESPERATE, HELP:
Problem with new HSSFWorkbook() in web unix server
>
> We have a static java method (see below) in which we do
>new HSSFWorkbook();
>
> this causes "500 internal server error" in web server.
>
> The strange thing is this deployment works fine on my PC and
> on our development unix server.  When we "copy" the war and
> ear files from the development unix server  to deploy on our UAT
> unix machine, then the program crashes as described above
> at the new HSSFWorkbook().
>
> On the other machines, we nicely get our Excel program to
> popup in either a browser or in Excel.
>
> Any ideas about what could be causing this problem???
> We have tried everything, and asked whoever we could,
> but no success so far.
>
> THANKS,
> Steve
>
> private static HSSFWorkbook constructTemplateAsWorkbook() {
> if(ReportProducer.DEBUG1) {
>   System.out.println("7:40--constructTemplateAsWorkbook():
START");
> }
> HSSFWorkbookwbk= null;
> HSSFSheet   sheet  = null;
> HSSFPrintSetup  printSetup = null;
> if(ReportProducer.DEBUG1) {
>   System.out.println("7:40--constructTemplateAsWorkbook(): #1");
> }
> wbk = new HSSFWorkbook();
> if(ReportProducer.DEBUG1) {
>   System.out.println("7:40--constructTemplateAsWorkbook(): #2");
> }
> for(int nSheet=1; nSheet<; nSheet++) {
>   if(ReportProducer.DEBUG1) {
> System.out.println("7:40--constructTemplateAsWorkbook(): #3:
LOOP
> nSheet="+nSheet);
>   }
>   sheet = wbk.createSheet();
>sheet.setAutobreaks(true);
>sheet.setHorizontallyCenter(true);
>if(ReportProducer.DEBUG1) {
>  System.out.println("7:40--constructTemplateAsWorkbook(): #4:
LOOP
> nSheet="+nSheet);
>}
>//sheet.setMargin
>printSetup = sheet.getPrintSetup();
>printSetup.setLandscape(true);
>if(ReportProducer.DEBUG1) {
>  System.out.println("7:40--constructTemplateAsWorkbook(): #5:
LOOP
> nSheet="+nSheet);
>}
>printSetup.setFitWidth((short)1);
>if(ReportProducer.DEBUG1) {
>  System.out.println("7:40--constructTemplateAsWorkbook(): #6:
LOOP
> nSheet="+nSheet);
>}
>printSetup.setFitHeight((short)0);
> }
> if(ReportProducer.DEBUG1) {
>   System.out.println("7:40--constructTemplateAsWorkbook(): ABOUT
to
> return wbk");
> }
> return wbk;
>   }
>
>
> } // end of class
>
> xOfflineReportInvoker.getExcelWorkbook(): Start.
> OfflineReportInvoker.getExcelWorkbook(): DON'T useInputStream; make
> template.
> 7:40--constructTemplateAsWorkbook(): START
> 7:40--constructTemplateAsWorkbook(): #1
> <-- hangs up at this point
>
>
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Strange record type in Excel file

[Height, Jason]

Is that 93 in decimal or Hex. If it is hex then yup don't know what that
record type is.

 

If it is decimal ie 5D hex then the record is the OBJ record which
describes a graphic object. Which should be implemented.

 

In either case could you please create a bugzilla entry, attaching the
sample file that you provided.

 

Jason

 

-Original Message-
From: Mikael Sitruk [mailto:[EMAIL PROTECTED] 
Sent: Friday, 13 August 2004 6:34 AM
To: [EMAIL PROTECTED]
Subject: Strange record type in Excel file

 

Hi to all

 

I've encountered a problem in releases 2.5/2.51 that was not present in
1.10.

I have a workbook containing data, and I wish to copy to a target
workbook, in 1.10 everything was fine, nevertheless when upgrading to
2.5/2.51 I got an exception on the workbook creation.

 

I've attached the exception just for documentation

java.lang.reflect.InvocationTargetException

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)

at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA
ccessorImpl.java:39)

at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons
tructorAccessorImpl.java:27)

at
java.lang.reflect.Constructor.newInstance(Constructor.java:274)

at
org.apache.poi.hssf.record.RecordFactory.createRecord(RecordFactory.java
:225)

at
org.apache.poi.hssf.record.RecordFactory.createRecords(RecordFactory.jav
a:160)

at
org.apache.poi.hssf.usermodel.HSSFWorkbook.(HSSFWorkbook.java:163)

at
org.apache.poi.hssf.usermodel.HSSFWorkbook.(HSSFWorkbook.java:130)

at HSSF.(HSSF.java:109)

at HSSF.main(HSSF.java:348)



First I though that my code was not ok, so I used the one referenced in
the FAQ, and still got the problem. So I've printed the record that made
the problem, and got:

Record type: 93 size: 70 data: [EMAIL PROTECTED]

 

I've tried to find from which cell this can provide, but even after
having removing all the data in the worksheet (the problematic worksheet
is "sss") I still got the exception. 

I've checked in the M$ Excel File Format doc, but I don't see any
documentation on this record type!!!

Do you have any idea how I can overcome the problem? Since for now I'm
not able to upgrade to the latest POI version.

 

I've attached the problematic file

 

Thanks

 

Mikael.S

 


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.

RE: Plans etc (was Re: [VOTE] POI 2.5.1 release )

[Height, Jason]

After 2.5.1 and the copy of the HSSF branch to the head, It would be
nice to apply the patches that people have been supplying. There are a
number on the bug list that could be applied, or parts of which could be
applied.

Thoughts?

Jason

-Original Message-
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED] 
Sent: Friday, 6 August 2004 10:05 PM
To: POI Developers List
Subject: Re: Plans etc (was Re: [VOTE] POI 2.5.1 release )

At 02:35 PM 5/08/2004, you wrote:
>Ideally the HEAD-based release would contain Glen's latest changes.
>However, if 1. and 2. take too long it would be better to make a 2.5.1
>immediately and a 2.6 release later (but not too late).

2.5.1 is essentially good to go as it is so my plan is to put it up.

>Do we formally need to vote on this? Are there any other issues?

No.  I think we're good to go.




Glen Stampoultzis
[EMAIL PROTECTED]
http://members.iinet.net.au/~gstamp/glen/

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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Response to Rainer WAS: Re: [VOTE] POI 2.5.1 release

[Height, Jason]

No problems ;-)

Jason

-Original Message-
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 5 August 2004 1:11 PM
To: POI Developers List
Subject: RE: Response to Rainer WAS: Re: [VOTE] POI 2.5.1 release


Alright but you're going to have to buy me a beer when I'm next in
Adelaide.

At 01:31 PM 5/08/2004, you wrote:
>+1 to all of below, If you take the lead on this ;-)
>
>Jason
>
>-Original Message-
>From: Glen Stampoultzis [mailto:[EMAIL PROTECTED]
>Sent: Thursday, 5 August 2004 12:39 PM
>To: POI Developers List
>Subject: RE: Response to Rainer WAS: Re: [VOTE] POI 2.5.1 release
>
>At 11:30 AM 5/08/2004, you wrote:
>
> >Glen
> >
> >Ok done.
> >
> >I think that there is some agreement to move the 2.5 branch of HSSF
>over
> >to the HEAD, maybe then another release (2.6?) with the HPSF could be
> >done. Hopefully this could all be done fairly quickly.
>
>Yes.  I think we can say that we have consensus on that.  Failing any
>volunteers I guess I'll sign up for that.  Is there anything I should
be
>
>extra careful about overwriting?
>
>My plan is:
>
>1. Tag the existing performance code so that we can refer back to it in
>the
>future.
>2. Replace the packages org.apache.poi.hssf.*, org.apache.poi.ddf.*,
>org.apache.poi.poifs.* in HEAD with the code in REL2_BRANCH.
>3. Compare org.apache.poi.util.* manually for any changes that need to
>be
>merged.  (Replacing this package wholesale might screw up Rainers good
>work
>so a manual compare would be best).
>4. Run the tests to try and make sure I haven't broken anything.
>
>I think we should move the word stuff out of scratchpad also.  It has
>lived
>there long enough and with Piers patch it should be stable enough for
>some
>more serious bashing.
>
>Regards,
>
>Glen
>---
-
>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.
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]


Glen Stampoultzis
[EMAIL PROTECTED]
http://members.iinet.net.au/~gstamp/glen/

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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Response to Rainer WAS: Re: [VOTE] POI 2.5.1 release

[Height, Jason]

+1 to all of below, If you take the lead on this ;-)

Jason

-Original Message-
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 5 August 2004 12:39 PM
To: POI Developers List
Subject: RE: Response to Rainer WAS: Re: [VOTE] POI 2.5.1 release

At 11:30 AM 5/08/2004, you wrote:

>Glen
>
>Ok done.
>
>I think that there is some agreement to move the 2.5 branch of HSSF
over 
>to the HEAD, maybe then another release (2.6?) with the HPSF could be 
>done. Hopefully this could all be done fairly quickly.

Yes.  I think we can say that we have consensus on that.  Failing any 
volunteers I guess I'll sign up for that.  Is there anything I should be

extra careful about overwriting?

My plan is:

1. Tag the existing performance code so that we can refer back to it in
the 
future.
2. Replace the packages org.apache.poi.hssf.*, org.apache.poi.ddf.*, 
org.apache.poi.poifs.* in HEAD with the code in REL2_BRANCH.
3. Compare org.apache.poi.util.* manually for any changes that need to
be 
merged.  (Replacing this package wholesale might screw up Rainers good
work 
so a manual compare would be best).
4. Run the tests to try and make sure I haven't broken anything.

I think we should move the word stuff out of scratchpad also.  It has
lived 
there long enough and with Piers patch it should be stable enough for
some 
more serious bashing.

Regards,

Glen

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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Response to Rainer WAS: Re: [VOTE] POI 2.5.1 release

[Height, Jason]

Glen

Ok done.

I think that there is some agreement to move the 2.5 branch of HSSF over to the HEAD, 
maybe then another release (2.6?) with the HPSF could be done. Hopefully this could 
all be done fairly quickly.

Jason


-Original Message-
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 5 August 2004 10:52 AM
To: POI Developers List
Subject: RE: Response to Rainer WAS: Re: [VOTE] POI 2.5.1 release


I really can't see a reason to delay 2.5.1 so unless you want to veto I'd
really like to release it.

The whole merge of branch and head is another issue all together to my mind.

Please respond with your final vote on the vote thread.

Regards,

Glen

At 07:51 AM 5/08/2004, you wrote:
>I agree here, preserve what has been done, but then overwrite with the 2.5 
>series.
>
>Then release 2.5.1 as HSSF 2.5 + recent fixes plus rest of HEAD.
>
>Jason
>
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, 4 August 2004 11:35 PM
>To: [EMAIL PROTECTED]
>Subject: Response to Rainer WAS: Re: [VOTE] POI 2.5.1 release
>
>I understand your concerns.  It is also unfair to hold your work up.
>Initially I thought I'd be given a greater amount of time to do the HSSF
>refactoring, but its not looking promising and HSSF isn't stable in the
>head.  Therefore, I think we should overwrite the HSSF part of the HEAD wit
>h
>the 2.5 stuff (possibly branching first to preserve it).  While many folks
>have given promising (2/3 memory footprint reduction) feedback on the memor
>y
>savings, no contributors or even fellow committers have stepped forward to
>help and I can't really do that myself and keep it in synch.  Thoughts?
>
>--
>Andrew C. Oliver
>http://www.superlinksoftware.com/poi.jsp
>Custom enhancements and Commercial Implementation for Jakarta POI
>
>http://jakarta.apache.org/poi
>For Java and Excel, Got POI?
>
>
> > From: Rainer Klute <[EMAIL PROTECTED]>
> > Organization: Rainer Klute IT-Consulting GmbH
> > Reply-To: "POI Developers List" <[EMAIL PROTECTED]>
> > Date: Wed, 04 Aug 2004 08:40:17 +0200
> > To: POI Developers List <[EMAIL PROTECTED]>
> > Subject: Re: [VOTE] POI 2.5.1 release
> >
> > On Wed, 2004-08-04 at 07:31, Glen Stampoultzis wrote:
> >> I've collected a bunch of changes together and created a maintenance rel
>ease.
> >
> > Glen, first of all thank you for your changes and your effort to create
> > a maintenance release!
> >
> >
> >> This does not include any changes being made in the head.
> >
> > I don't mind another maintenance release, but I'd also like to see a
> > release with the "new" features that are in the head. For example, the
> > HPSF capability to write properties is not in any release but only in
> > the head for months if not for a year or so. HPSF's codepage handling is
> > also in the head only for months.
> >
> > I suspect that many users don't know that these features exist because
> > they just download a release and don't bother to checkout the CVS' head.
> >
> >
> > Regarding my vote:
> >
> >> [ ] +1 Go ahead and release
> >> [X] +0 Sure... whatever
> >> [ ] -0 I have some reservations (name them)
> >> [ ] -1 VETO.  We can not release this.
> >
> >
> > Best regards
> > Rainer Klute
> >
> >  Rainer Klute IT-Consulting GmbH
> > Dipl.-Inform.
> > Rainer Klute E-Mail:  [EMAIL PROTECTED]
> > Körner Grund 24  Telefon: +49 172 2324824
> > D-44143 Dortmund   Telefax: +49 231 5349423
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>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.
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]


Glen Stampoultzis
[EMAIL PROTECTED]
http://members.iinet.net.au/~gstamp/glen/
-

RE: [VOTE] POI 2.5.1 release

[Height, Jason]

+0

Jason

-Original Message-
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 04, 2004 12:31 AM
To: [EMAIL PROTECTED]
Subject: [VOTE] POI 2.5.1 release


I've collected a bunch of changes together and created a maintenance
release.

A preview copy may be found here:

http://cvs.apache.org/~glens/release/

This does not include any changes being made in the head.

[ ] +1 Go ahead and release
[ ] +0 Sure... whatever
[ ] -0 I have some reservations (name them)
[ ] -1 VETO.  We can not release this.



Glen Stampoultzis
[EMAIL PROTECTED]
http://members.iinet.net.au/~gstamp/glen/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Response to Rainer WAS: Re: [VOTE] POI 2.5.1 release

[Height, Jason]

I agree here, preserve what has been done, but then overwrite with the 2.5 series. 

Then release 2.5.1 as HSSF 2.5 + recent fixes plus rest of HEAD.

Jason

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 4 August 2004 11:35 PM
To: [EMAIL PROTECTED]
Subject: Response to Rainer WAS: Re: [VOTE] POI 2.5.1 release

I understand your concerns.  It is also unfair to hold your work up.
Initially I thought I'd be given a greater amount of time to do the HSSF
refactoring, but its not looking promising and HSSF isn't stable in the
head.  Therefore, I think we should overwrite the HSSF part of the HEAD wit
h
the 2.5 stuff (possibly branching first to preserve it).  While many folks
have given promising (2/3 memory footprint reduction) feedback on the memor
y
savings, no contributors or even fellow committers have stepped forward to
help and I can't really do that myself and keep it in synch.  Thoughts?

-- 
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI

http://jakarta.apache.org/poi
For Java and Excel, Got POI?


> From: Rainer Klute <[EMAIL PROTECTED]>
> Organization: Rainer Klute IT-Consulting GmbH
> Reply-To: "POI Developers List" <[EMAIL PROTECTED]>
> Date: Wed, 04 Aug 2004 08:40:17 +0200
> To: POI Developers List <[EMAIL PROTECTED]>
> Subject: Re: [VOTE] POI 2.5.1 release
> 
> On Wed, 2004-08-04 at 07:31, Glen Stampoultzis wrote:
>> I've collected a bunch of changes together and created a maintenance rel
ease.
> 
> Glen, first of all thank you for your changes and your effort to create
> a maintenance release!
> 
> 
>> This does not include any changes being made in the head.
> 
> I don't mind another maintenance release, but I'd also like to see a
> release with the "new" features that are in the head. For example, the
> HPSF capability to write properties is not in any release but only in
> the head for months if not for a year or so. HPSF's codepage handling is
> also in the head only for months.
> 
> I suspect that many users don't know that these features exist because
> they just download a release and don't bother to checkout the CVS' head.
> 
> 
> Regarding my vote:
> 
>> [ ] +1 Go ahead and release
>> [X] +0 Sure... whatever
>> [ ] -0 I have some reservations (name them)
>> [ ] -1 VETO.  We can not release this.
> 
> 
> Best regards
> Rainer Klute
> 
>  Rainer Klute IT-Consulting GmbH
> Dipl.-Inform.
> Rainer Klute E-Mail:  [EMAIL PROTECTED]
> Körner Grund 24  Telefon: +49 172 2324824
> D-44143 Dortmund   Telefax: +49 231 5349423
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: HPSF Mutables

[Height, Jason]

Curtis,

Your shouldn't have to manually attach properties, at least unless something
has radically changed.

Could you dummy up a simple test and write the sheet to a file instead of a
mime attachment. Maybe something is going wrong with mime. If it is still a
problem then please create a bug in bugzilla, attaching both the errornous
excel file and a code snippet to create the file.

FYI I have never seen this problem in my use of HSSF.

Jason

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.

RE: HPSF Mutables

[Height, Jason]

Curtis,

That doesn't seem to be something that I would expect excel to complain
about. Sounds like a bug to me.

Perhaps provide a little detail about how you are writing the HSSF
spreadsheet.

Jason

-Original Message-
From: Ling, Curtis [mailto:[EMAIL PROTECTED] 
Sent: Friday, 30 April 2004 2:25 AM
To: '[EMAIL PROTECTED]'
Subject: HPSF Mutables

Hello.
I'm using POI to export ms-excel compatible spreadsheets.  When I open the
spreadsheets using ms-excel, I get a "Lost document summary information"
error, which I'm attributing to the lack of a PropertySet in the document.
I'm following the example in the fourth section of the "HPSF HOW-TO", which
details how to write Properties using MutablePropertySet, MutableSection and
MutableProperty; but these classes are not present in the v2.5 final release
of POI.  I see that they are part of the CVS Source Tree, so I was wondering
if there was a binary (.jar) somewhere which included these classes, or if
it would be possible for someone to share theirs with me.

Sorry to be a pest.

Curtis Ling

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

RE: Moving HWPF out of scratchpad

[Height, Jason]

+0

Whilst I haven't a need to use HWPF, from what I have seen in the last few
weeks it has some momentum behind it, and at a seemingly fit state for it to
be promoted.

Certainly judging by the number of bug reports filed against HSSF recently
it couldn't be any worse ;-)

Jason

-Original Message-
From: Ryan Ackley [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 25 March 2004 5:31 AM
To: POI Developers List
Subject: Moving HWPF out of scratchpad

To all committers,

I would like to get feel out everyones thoughts on moving HWPF out of
scratchpad. More specifically, what requirements do you want me to meet
before you would be willing to vote for this to happen?

Avik and I are writing an article for JDJ and it will contain material on
HWPF. For this article to have the maximum benefit, I feel that HWPF should
be as easily accessible as possible. How about a 2.6 release containing
HWPF? thoughts?

-Ryan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

RE: Received a patch file

[Height, Jason]

Ryan,

Well I use cygwin which provides the unix patch, cvs etc utilites for
windows to do the work. But there may be easier ways (I don't know)

However here is a rough instruction:

Start a cygwin bash shell

cd 
patch -p0 < mypatchfile.diff

This assumes that the diff was performed beneath the Jakarta poi root
directory, it may be one level up or several levels down in the source tree,
you should be able to have a look at the diff file to work it out. The -p
parameter means ignore this many levels of directory structure in the patch
file. In our case when the directories match it is zero. 

If you are lucky the patch was applied without any rejects!!

Then use cvs to upload the new code which I assume you already know how to
do

Let me know if you come to grief.

Jason



-Original Message-
From: Ryan Ackley [mailto:[EMAIL PROTECTED] 
Sent: Friday, 5 March 2004 1:01 PM
To: POI Developers List
Subject: Received a patch file

Err...now what do I do? How do I apply a patch to cvs? FYI, I use Windows.

-Ryan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

RE: [SPAM Detected] Re: HWPF contributions...

[Height, Jason]

Piers,

Excellent! Cant wait to see some patches being applied!

Have you arranged a method with Ryan for contributing patches?

Ryan,

Is HWPF still in the scratchpad, or can it be promoted given its recent
ability to read documents and now perhaps with a few more real world
developers coming onboard.

I can see quite a lot of use for HWPF.

Jason


-Original Message-
From: Ryan Ackley [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 24 February 2004 3:35 AM
To: POI Developers List; Piers Taylor
Subject: [SPAM Detected] Re: HWPF contributions...


References:
<[EMAIL PROTECTED]>
Precedence: bulk


Very cool!! I am going to forward this to the dev list. 

- Original Message - 
From: "Piers Taylor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 23, 2004 11:54 AM
Subject: HWPF contributions...


> Hi Ryan,
> 
> I work for an English software company, Goss
> Interactive Ltd. (http://www.gossinteractive.com)
> 
> We have been working with the old POI HDF code
> for a little while now. In the course of using
> this code in a business environment we have applied
> a number of tweaks to the code in order to make it
> work with real-world Word docs. In particular we have
> made changes and enhancements to work with Word 2000/XP 
> etc.
> 
> These include: 
> 
> * adding the code to handle sprmPHugePapx and the 
>   associated Data Stream part of the document which 
>   it uses for data storage.
> 
> * adding code for undocumented PAP sprm 0x46.
>   (sprmPHugePapx 2)
> 
> * adding code for undocumented CHP sprm 0x70.
>   (Word 2000+ 32bit RGB character colours)
> 
> * fixes for ints sign extending shorts into large
>   negative ints.
> 
> * some checks for nulls that appear in Word 2000/XP docs
>   and cause null pointer exceptions.
> 
> All our own work with the aid of open source. 
> Absolutely no MS NDAs.
> 
> We would like to have our fixes enhancements included in
> your new HWPF code. (We checked to see if any of it was there.)
> Then we would like to change over to using HWPF. We would
> be interested in contributing future fixes/enhancements.
> 
> How would you like to proceed with this?
> 
> Best regards,
>   Piers
> 
> 
> Piers Taylor - Senior Developer
> Goss Interactive Ltd
> http://www.gossinteractive.com
> Telephone: +44 1752 517350
> 
> 
> --
> This e-mail contains proprietary information, some or all of 
> which may be legally privileged. It is for the intended recipient 
> only. If an addressing or transmission error has misdirected this 
> e-mail, please notify the author by replying to this e-mail. 
> If you are not the intended recipient you may not use, disclose, 
> distribute, copy, print or rely on this e-mail. 
> 
> Email transmission cannot be guaranteed to be secure or error free 
> as  information may be intercepted, corrupted, lost, destroyed, 
> arrive late or incomplete or contain viruses. This email and any 
> files attached to it have been checked with virus detection software 
> before transmission. You should nonetheless carry out your own virus 
> check before opening any attachment. Goss Interactive Ltd accepts no 
> liability for any loss or damage which may be caused by software 
> viruses.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

RE: Fwd: ASF Board Summary for February 18, 2004

[Height, Jason]

I can only assume that they have taken this approach so that the individual
is protected from potential lawsuits Ie the apache group would be targeted
since they would be the "author".

Having said that it is a sad world where we are seeing the need for such
things becoming more prevalent. You know I can remember when my folks never
used to lock the doors at home..

Jason

-Original Message-
From: Rainer Klute [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 24 February 2004 2:38 PM
To: POI Developers List
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Fwd: ASF Board Summary for February 18, 2004

On Tue, 24 Feb 2004 10:28:38 +1100 Glen Stampoultzis <[EMAIL PROTECTED]>
wrote:
> The other bit is that author tags are "officially" discouraged.
Personally 
> I find this somewhat annoying.  Given that it is discouraged and not 
> mandated I'm not sure where this leaves us.  What does everyone else feel 
> about @author tags?

I find this annoying, too, and would like to keep the author tags. Software
is written by humans. If authors were paid for their work, things would be
different, but for volunteer work they should at least get the honor to be
mentioned in the author tags.


Best regards
Rainer Klute

   Rainer Klute IT-Consulting GmbH
  Dipl.-Inform.
  Rainer Klute E-Mail:  [EMAIL PROTECTED]
  Körner Grund 24  Telefon: +49 172 2324824
D-44143 Dortmund   Telefax: +49 231 5349423

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

RE: [VOTE] New development build

[Height, Jason]

Sorry! Stupid filter here at work. You will have to ignore these lines from
me im afraid.

Jason

-Original Message-
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 17 February 2004 2:29 PM
To: POI Developers List
Subject: RE: [SPAM Detected] [VOTE] New development build


 >[SPAM Detected] [VOTE] New development build

I wasn't spamming... honest!


At 01:55 PM 17/02/2004, you wrote:
>2.5 production
>
>+1
>
>Jason


Glen Stampoultzis
[EMAIL PROTECTED]
http://members.iinet.net.au/~gstamp/glen/

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.

RE: [SPAM Detected] [VOTE] New development build

[Height, Jason]

2.5 production

+1

Jason

-Original Message-
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 17 February 2004 9:02 AM
To: [EMAIL PROTECTED]
Subject: [SPAM Detected] [VOTE] New development build


Precedence: bulk



I'd like to do a new development build followed soon after by a production 
build.

Following our current quirky version standards this would be 2.1 for the 
development version and 3.0 for the production version.  Alternatively we 
could go 2.5 for the production version.  I really don't care.

Please give your -1, -0, +0, +1's.

BTW,  we should probably look at upgrading to the new 2.0 license for this 
release.  This will be forced upon us if we release after the end of Feb 
anyway.  Anyone got a conversion script?




Glen Stampoultzis
[EMAIL PROTECTED]
http://members.iinet.net.au/~gstamp/glen/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

RE: cvs commit: jakarta-poi/src/documentation/content/xdocs/hssf quick-guide.xml

[Height, Jason]

Now that your work is in CVS, there was a bit of discussion on the mailing
list of people who wanted to work on this area.

Hopefully they should be able to take what has been done and extend it to
support reading/modification of existing drawings.

Jason

-Original Message-
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 11 February 2004 11:33 AM
To: POI Developers List
Subject: RE: cvs commit: jakarta-poi/src/documentation/content/xdocs/hssf
quick-guide.xml


At the moment creating a drawing on a sheet will not keep any existing 
drawings.  The potential is there to try and support reading drawing 
objects but the initial requirement was to support writing so I played it 
safe and didn't attempt to interpret existing shape objects.

At 09:54 AM 11/02/2004, you wrote:
>Is there a HSSFSheet.getPatriarch that will return the current Drawing
>Patriarch and wont erase drawings in the sheet? (There is no example of
this
>in the doco you just provided).
>
>Does this mean that there is one Patriarch for all drawings?


Glen Stampoultzis
[EMAIL PROTECTED]
http://members.iinet.net.au/~gstamp/glen/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

RE: cvs commit: jakarta-poi/src/documentation/content/xdocs/hssf quick-guide.xml

[Height, Jason]

  +at all.  To start drawing you need to call
createPatriarch
  +on the HSSFSheet class.  This has
the
  +effect erasing any other shape information stored
  +in that sheet.  By default POI will leave shape
  +records alone in the sheet unless you make a call
to
  +this method.


Is there a HSSFSheet.getPatriarch that will return the current Drawing
Patriarch and wont erase drawings in the sheet? (There is no example of this
in the doco you just provided).
 
Does this mean that there is one Patriarch for all drawings?

Jason

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.

RE: ValueRecords and SharedFormulas

[Height, Jason]

Attempt to send patch in smaller chunks

Jason


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.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ValueRecords and SharedFormulas

[Height, Jason]

Ok for whatever reason my attachments didn't make the mailing list. Avik did
you get them?

 

Jason


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.

RE: ValueRecords and SharedFormulas

[Height, Jason]

Title: RE: ValueRecords and SharedFormulas





Ok here is my original patch. And yes Avik what you say about shared formulas not being stored correctly on HEAD is correct.

I have just had a look at it and it seems that I also had done some work in the ExtSST area also that fixed a bug whereby the number of buckets could not exceed 128. I am not sure if this patch made it on its own or not.

I believe that this patch was produced against the head, but I haven't tried to apply the patch yet. I suggest having a look through it to see if it looks ok before applying it. I don't really have the ability to work on it at the moment.

I have attached the patch plus the 10 new files. Just one thing that needs to be addressed is in ValueRecordsAggregate, the parsing of the shared formula records when an ARRAY follows the formula (rather than a string) needs to be completed (I never had any excel files to test against). So I guess my patch isn't 100% complete yet.

Anyhow hope that it helps.


Jason 


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, 28 January 2004 12:47 PM
To: [EMAIL PROTECTED]
Subject: ValueRecords and SharedFormulas


The current(branch) method for retaining shared formulas will not work on HEAD.
Currently, we add a SharedFormulaRecord to a FormulaRecordAggregate when we see
one. However, for HEAD, no record objects other than ValueRecordAggregate are
stored, only the underlying data is stored in VRA, and Record's created on
demand. Andy, correct me if I am wrong. 


So bottomline, in such a scenario, it might be easier to support SharedFormula's
by breaking them up to real formula's at read time. will increase re-written
excel size ... but ... is easiest. 


If I remember right, Jason had a patch for it.. can try and add it in? Maybe if
you can mail it, we can all have a play around with it. 


I am also concerned about the lack of unit tests for ValueRecordAggregate, given
the amount of work that class does in the new scheme of things, but thats a
story for another day. 


Regards
-
Avik






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 

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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Comments are part of Escher!

[Height, Jason]

In view of the fact that the actual implementers of HSSF have their own
Escher support, I don't think it's appropriate to include my work at this
point. However, once Escher support is in, I am pretty sure I will be able
to submit smaller patches to enhance the support.

{snip)

Well I am glad that you would be willing to enhance and patch it once it is
in. Here is hoping that it can happen at some stage, in the mean time don't
go deleting your source tree!

Jason

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.

RE: Support for Images and charting

[Height, Jason]

Michael

Clearly you have a good idea of the way ahead, so why don't you and Kais
start submitting patches based on the work that you have done thus far.

I too seen the thread that mentioned to hold off, but I think that if some
code starts to drift in then it may start to bring the issue to the front of
everyones minds and we can start to move on this. I have been waiting for
hyperlinks and Comments (which I believe are a form of picture) FOR EVER!

Thanks

Jason Height


-Original Message-
From: Michael Zalewski [mailto:[EMAIL PROTECTED] 
Sent: Friday, 23 January 2004 1:24 AM
To: POI Developers List
Subject: RE: Support for Images and charting

There are actually 3 ways that Excel puts an image into a workbook.

The first is the old way, used by Excel v 4, but still supported by current
versions of Excel. In this case, images go into a 'DSO' record (I think).
Images done in this way are like any other cell content. This would be the
simplest way to implement image support, and is used by some PERL programs
There is also a patch to JExcelApi (but it's not part of the main
distribution yet) that does the same thing. Images attached in this way have
to be relatively small, and have to be a certain style of bitmap.

Here is a freshmeat description of Spreadsheet::WriteExcel
http://freshmeat.net/projects/writeexcel/?topic_idf%2C78%2C131%2C809
"The Spreadsheet::WriteExcel module can be used to create a cross-platform
Excel binary file. Multiple worksheets can be added to a workbook and
formatting can be applied to cells. Text, numbers, formulas, hyperlinks and
images can be written to the cells"

Here is a link to JExcelApi (on SourceForge)
http://sourceforge.net/projects/jexcelapi/

The patch to attach images is in their Yahoo Group
http://groups.yahoo.com/group/JExcelApi/
Join the group, click on 'Files', then look for jxl_2_3_11_image_patch.zip

The second way is through the Escher layer. In this case, images are part of
the Unknown Record ec (and eb and ed), which have the names MSODRAWINGGROUP,
MSODRAWING, and MSODRAWINGSELECTION You can read my earlier messages
describing this format at a high level  Basically, the images themselves are
stored inside the MSODRAWINGGROUP record. The position and properties such
as borders, background color, grouping with other objects is described in
the MSODRAWING record. And the last selected object is stored in the
MSODRAWINGSELECTION record. There will also be an OBJ record for each image,
which is how Excel comes up with the name 'Picture 1' when the image is
selected. You can read some of my earlier posts

http://www.mail-archive.com/[EMAIL PROTECTED]/msg03479.html
http://www.mail-archive.com/[EMAIL PROTECTED]/msg03305.html

I had developed a POI based parser for this, but stopped work when I read
that the committers were going to implement Escher support 'real soon now'
(That was back in October).

The third way is as an OLE attachment. In this case, the images themselves
go into a separate stream in the OLE Doc file. Images attached in this way
are actually OLE documents, and will have an associated program such as
PaintBrush, PhotoShop or some other graphics editor. The 'image' can even be
a Power Point slide, a page from a Word document, or another Excel
spreadsheet. This second stream is referenced by an OBJECT record

-Original Message-
From: Kais Dukes [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 22, 2004 7:53 AM
To: POI Developers List
Subject: RE: Support for Images and charting

Glen,

Thanks for the bar chart records, there very useful. Do you have a similar
dump for images?

Kind Regards

-- Kais

-Original Message-
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED]
Sent: 22 January 2004 12:50
To: POI Developers List
Subject: Re: Support for Images and charting


At 04:57 PM 22/01/2004, you wrote:
>I think all things left to do in HSSF are basically easy, but what do I
>know.

Hrrmm... charting will be a lot of work.  The main problem is that there's
very little information available on how charts work.  These are the
records for a very "simple" bar chart:


[UNKNOWN RECORD:ec]
[UNKNOWN RECORD:5d]
[BOF RECORD]
 [HEADER]
 [FOOTER]
 [HCENTER]
 [VCENTER]
 [PRINTSETUP]
 [UNKNOWN RECORD:33]
 [FBI]
 [FBI]
 [PROTECT]
 [UNITS]
 [CHART]
 [BEGIN]
 [SCL] // zoom magnification
 [PLOTGROWTH]  // font scaling
 [FRAME]   // border around text
 [BEGIN]   // default line and area format
 [LINEFORMAT]
 [AREAFORMAT]
 [END]
 [SERIES]  // start of series
 [BEGIN]
 [AI]  // LINK_TYPE_TITLE_OR_TEXT
 [AI]  // LINK_TYPE_VALUES
 [AI]  // LINK_TYPE_CATEGORIES
 [AI]  // ??
 [DATAFORMAT]  // Formatting applies to series?
 [BEGIN]   // ??
  

RE: Applet

[Height, Jason]

Andrew,

I believe that logging is not necessary for POI. Its only purpose is for
debugging, which can be achieved by either using the console or utilizing an
appropriate debugger.

As such I concur that it should be removed.

Jason



-Original Message-
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 18 November 2003 11:25 AM
To: POI Developers List
Cc: POI Users List
Subject: Re: Applet

Now that Nicola Ken is gone...can we just ditch logging?  Its no longer
useful.

On 11/17/03 3:30 PM, "Hart, Justin" <[EMAIL PROTECTED]> wrote:

> Another quick one...  NullLogger doesn't seem to be present in the jar
file
> for 1.5.1, it's listed in the javadoc as a class, where is it?
> 
> Justin
> 
> -Original Message-
> From: Hart, Justin
> Sent: Monday, November 17, 2003 6:08 PM
> To: POI Users List
> Subject: RE: Applet
> 
> 
> I've established 2 things :
> 1)  POI is trying to log, but shouldn't be (I have 1.5.1, shouldn't this
be
> off by default?)
> 2)  I don't want to log.
> 
> Advice?
> 
> Justin
> 
> 
> -Original Message-
> From: Hart, Justin
> Sent: Monday, November 17, 2003 4:37 PM
> To: [EMAIL PROTECTED]
> Subject: Applet
> 
> 
> Hiya,
> I'm trying to write an excel spreadsheet from a trusted applet, and I get
a
> nasty error message:
> java.security.AccessControlException: access denied
> (java.util.PropertyPermission poi.logging read)
> at java.security.AccessControlContext.checkPermission(Unknown Source)
> at java.security.AccessController.checkPermission(Unknown Source)
> at java.lang.SecurityManager.checkPermission(Unknown Source) at
> java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
> at java.lang.System.getProperty(Unknown Source)
> at org.apache.poi.util.POILogger.isDebugEnabled(POILogger.java:104)
> at org.apache.poi.util.POILogger.check(POILogger.java:164)
> at org.apache.poi.util.POILogger.log(POILogger.java:98)
> at org.apache.poi.hssf.model.Workbook.createWorkbook(Workbook.java:226)
> at
org.apache.poi.hssf.usermodel.HSSFWorkbook.(HSSFWorkbook.java:122)
> 
> Shouldn't this be a-ok?  It's a trusted applet!
> 
> Justin
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-- 
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI

http://jakarta.apache.org/poi
For Java and Excel, Got POI?

The views expressed in this email are those of the author and are almost
definitely not shared by the Apache Software Foundation, its board or its
general membership.  In fact they probably most definitively disagree with
everything espoused in the above email.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

RE: cvs commit: jakarta-poi/src/java/org/apache/poi/hssf/record M ergeCellsRecord.java

[Height, Jason]

Danny,

This still doesn't clone the elements within the collection. (elements
within field_2_regions). So both collections will be pointing to the same
object references. A change in one merged region that alters an element in
field_2_regions will affect the other (if this can happen).

I think that new objects should be placed into the new collection.

Jason


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 18 November 2003 7:41 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-poi/src/java/org/apache/poi/hssf/record
MergeCellsRecord.java

dmui2003/11/17 13:10:35

  Modified:src/testcases/org/apache/poi/hssf/usermodel Tag:
REL_2_BRANCH TestBugs.java
   src/java/org/apache/poi/hssf/record Tag: REL_2_BRANCH
MergeCellsRecord.java
  Added:   src/testcases/org/apache/poi/hssf/record Tag: REL_2_BRANCH
TestMergeCellsRecord.java
  Log:
  The cloned reference for merged cells did not create a new collection,
  so deletes cascaded to the original.
  Reported by: [EMAIL PROTECTED]
  PR:  22720
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.1   +79 -0
jakarta-poi/src/testcases/org/apache/poi/hssf/record/Attic/TestMergeCellsRec
ord.java
  
  
  
  
  No   revision
  No   revision
  1.1.2.15  +35 -4
jakarta-poi/src/testcases/org/apache/poi/hssf/usermodel/TestBugs.java
  
  Index: TestBugs.java
  ===
  RCS file:
/home/cvs/jakarta-poi/src/testcases/org/apache/poi/hssf/usermodel/TestBugs.j
ava,v
  retrieving revision 1.1.2.14
  retrieving revision 1.1.2.15
  diff -u -r1.1.2.14 -r1.1.2.15
  --- TestBugs.java 30 Oct 2003 17:20:26 -  1.1.2.14
  +++ TestBugs.java 17 Nov 2003 21:10:35 -  1.1.2.15
  @@ -54,16 +54,16 @@
   
   package org.apache.poi.hssf.usermodel;
   
  +import java.io.ByteArrayInputStream;
  +import java.io.ByteArrayOutputStream;
   import java.io.File;
   import java.io.FileInputStream;
   import java.io.FileOutputStream;
  -import java.io.ByteArrayInputStream;
  -import java.io.ByteArrayOutputStream;
  -import java.io.IOException;
  -import java.util.Date;
   
   import junit.framework.TestCase;
   
  +import org.apache.poi.hssf.util.Region;
  +
   
   
   /**
  @@ -406,6 +406,37 @@
   HSSFRow row = sheet.getRow(0);
   HSSFCell cell = row.getCell((short)0);
   System.out.println(cell.getStringCellValue());
  +}
  +
  +/**
  + * Merged regions were being removed from the parent in cloned sheets
  + * @throws Exception
  + */
  +public void test22720() throws Exception {
  +   HSSFWorkbook workBook = new HSSFWorkbook();
  +   workBook.createSheet("TEST");   
  +   HSSFSheet template = workBook.getSheetAt(0);
  +   
  +   template.addMergedRegion(new Region(0, (short)0, 1, (short)2));
  +   template.addMergedRegion(new Region(1, (short)0, 2, (short)2));
  +   
  +   HSSFSheet clone = workBook.cloneSheet(0);
  +   int originalMerged = template.getNumMergedRegions();
  +   assertEquals("2 merged regions", 2, originalMerged);
  +
  +//remove merged regions from clone
  +   for (int i=template.getNumMergedRegions()-1; i>=0; i--) {
  + clone.removeMergedRegion(i);
  +   }
  +
  +  assertEquals("Original Sheet's Merged Regions were removed",
originalMerged, template.getNumMergedRegions());
  +//check if template's merged regions are OK
  +   if (template.getNumMergedRegions()>0) {
  +  // fetch the first merged region...EXCEPTION OCCURS HERE
  +  template.getMergedRegionAt(0);
  +   }   
  +   //make sure we dont exception
  +   
   }
   }
   
  
  
  
  No   revision
  No   revision
  1.6.2.1   +2 -1
jakarta-poi/src/java/org/apache/poi/hssf/record/MergeCellsRecord.java
  
  Index: MergeCellsRecord.java
  ===
  RCS file:
/home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/record/MergeCellsRecord.j
ava,v
  retrieving revision 1.6
  retrieving revision 1.6.2.1
  diff -u -r1.6 -r1.6.2.1
  --- MergeCellsRecord.java 30 Apr 2003 04:38:47 -  1.6
  +++ MergeCellsRecord.java 17 Nov 2003 21:10:35 -  1.6.2.1
  @@ -326,7 +326,8 @@
   public Object clone() {
   MergeCellsRecord rec = new MergeCellsRecord();
   rec.field_1_num_areas = field_1_num_areas;
  -rec.field_2_regions = field_2_regions;
  +rec.field_2_regions = new ArrayList();
  +rec.field_2_regions.addAll(field_2_regions);
   return rec;
   }
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROT

RE: HWPF

[Height, Jason]

Excellent!

How long before we see HWPF promoted from scratchpad ;-)

Jason

-Original Message-
From: Ryan Ackley [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 13 November 2003 1:46 AM
To: POI Developers List
Cc: POI Users List; [EMAIL PROTECTED]
Subject: HWPF

Good news everyone, I am able to successfully edit a simple Word document
with HWPF. I will commit and post some sample code tonight. Right now it
only works on the simplest of files but over the next few
days/weeks/months/years, I will be adding features and making it more
robust.

Unfortunately, at this moment I am toiling at my day job because I had to
get to work because I was already late. I want to be home working on HWPF!

Ryan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

Add ability to insertRows with automatic row shift

[Height, Jason]

Hi all,

 

I was thinking that I would like to add the functionality:

 

HSSFRow row = HSSFSheet.insertRow(1);

 

This functionality would differ from createRow in that it would move all
current rows after and including the row at the insert position down by one
row, updating all cell references (in formulas) to row+1. This is the same
as excel Insert Row functionality.

 

The shiftRows functionality would be used, but would need to be improved so
that cell references in formulas are updated (this should probably be done
anyway). What do you all think.

 

Probably to be complete a deleteRow would be required as well that moved the
rows up by one.

 

This would be done on the HEAD.

 

What do you all think. No one else working on this?

 

Jason


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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: unable to open HSSF (generated) excel file

[Height, Jason]

Since RC1 is now out. Could you give that a go. There are a large number of
corruption issues that were sorted out in this release over and above pre3.

Jason

-Original Message-
From: Tom [mailto:[EMAIL PROTECTED] 
Sent: Friday, 31 October 2003 10:23 AM
To: Tom; [EMAIL PROTECTED]
Subject: Re: unable to open HSSF (generated) excel file

using  poi-bin-2.0-pre3-20030728
platforms- win2k and solaris.

our application queries a DB user-log table  and generates a workbook sheet
that contains 3 columns (plus some header columns). the 3 columns are
"username" "login-time" and "logout-time" all cell values are writted out as
strings. in some cases the workbook generated will not open in MS-Excel
2000. i wrote a test pgm that can recreate the problem consistently, using
the the data from the DB exported into a flat file. the test pgm simply
reads the file and writes to a workbook.

i have noticed that this seems to depend on size. if i run this for records
for the current month only, the report is generated correctly. if i run it
for the whole year, i am unable to open the file. 

i noticed a similar thread in the list and as per the resolution note, i
checked out the latest code from CVS today morning and tried re-running the
test pgm with the latest jars but i get the following exception
java.lang.ArrayIndexOutOfBoundsException
at org.apache.poi.util.LittleEndian.putNumber(LittleEndian.java:549)
at org.apache.poi.util.LittleEndian.putShort(LittleEndian.java:282)
at org.apache.poi.hssf.record.RowRecord.serialize(RowRecord.java:465)
at
org.apache.poi.hssf.record.aggregates.RowRecordsAggregate.serializeRowBlock(
RowRecordsAggregate.java:244)
at
org.apache.poi.hssf.record.aggregates.RowRecordsAggregate.serialize(RowRecor
dsAggregate.java:275)
at org.apache.poi.hssf.model.Sheet.serialize(Sheet.java:734)
at
org.apache.poi.hssf.usermodel.HSSFWorkbook.getBytes(HSSFWorkbook.java:787)
at org.apache.poi.hssf.usermodel.HSSFWorkbook.write(HSSFWorkbook.java:731)
at src.ReadWriteWorkbook.main(ReadWriteWorkbook.java:61)
Exception in thread "main"

i can send out the test pgm (which is fairly straight forward) and the input
test file (cannot attach it as the zipped file size is abt 150k). can
someone please help me with the problem?

note - if i try ms-excel 2002, i am able to open the file but i  get an
error dialog saying "errors detected in workbook, but ms excel was able to
open it by making repairs listed below" the repair log says that the repairs
were not possible.

please let me know if i should open this as a bug or i should pose this to
some other mailing list.


thanks,

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.

Shared Formula Patch

[Height, Jason]

Hi all,

 

A while back I mentioned that I had a patch to convert from shared formulas
to non shared formulas. I still would like to apply it, as shared formulas
are severely broken in the HEAD. I could (if required) create a patch for
the 2.0 branch as well.

 

Avik, You had some concerns that this would interrupt your work on
toFormulaString. Is this concern still valid?

 

Regardless if anyone has any shared formula example spreadsheets (I only
have one) for me to try my patch against could you please send them to me. 

 

Thanks

 

Jason Height

 

 


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.

RE: cvs commit: jakarta-poi/src/java/org/apache/poi/hssf/record S STDeserializer.java SSTRecord.java

[Height, Jason]

About 30 mins after I posted this is posted the corrected code.

The bug has now been resolved for all testcases and attachments to bugs.

Jason

-Original Message-
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 15 October 2003 4:04 AM
To: POI Developers List
Subject: Re: cvs commit: jakarta-poi/src/java/org/apache/poi/hssf/record S
STDeserializer.java SSTRecord.java

Then can you revert it or something?  The 2.0 branch really needs to stay
stable at this point.

On 10/14/03 3:29 AM, "Height, Jason" <[EMAIL PROTECTED]> wrote:

> 
> This patch is not quite there yet. It will be shortly.
> 
> I accidentally posted before running the test cases and the
> TestSSTRecord.testHugeStrings is failing
> 
> Jason
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 14 October 2003 4:48 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: jakarta-poi/src/java/org/apache/poi/hssf/record
> SSTDeserializer.java SSTRecord.java
> 
> jheight 2003/10/14 00:18:17
> 
> Modified:src/java/org/apache/poi/hssf/record Tag: REL_2_BRANCH
>   SSTDeserializer.java SSTRecord.java
> Log:
> Patch to fix bugs 15556 and 22742.
> 
> Double byte handeling of SSTDeserializer now works.
> 
> Revision  ChangesPath
> No   revision
> No   revision
> 1.5.2.1   +48 -33
> jakarta-poi/src/java/org/apache/poi/hssf/record/SSTDeserializer.java
> 
> Index: SSTDeserializer.java
> ==
> RCS file:
>
/home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/record/SSTDeserializer.ja
> va,v
> retrieving revision 1.5
> retrieving revision 1.5.2.1
> diff -u -r1.5 -r1.5.2.1
> --- SSTDeserializer.java30 Apr 2003 04:38:48 -1.5
> +++ SSTDeserializer.java14 Oct 2003 07:18:17 -1.5.2.1
> @@ -62,13 +62,14 @@
>   * Handles the task of deserializing a SST string.  The two main entry
> points are
>   *
>   * @author Glen Stampoultzis (glens at apache.org)
> + * @author Jason Height (jheight at apache.org)
>   */
>  class SSTDeserializer
>  {
>  
>  private BinaryTree strings;
> -/** this is the number of characters we expect in the first
> sub-record in a subsequent continuation record */
> -private int continuationExpectedChars;
> +/** this is the number of characters that have been read prior to the
> continuation */
> +private int continuationReadChars;
>  /** this is the string we were working on before hitting the end of
> the current record. This string is NOT finished. */
>  private String unfinishedString;
>  /** this is true if the string uses wide characters */
> @@ -82,6 +83,7 @@
>  /** Number of characters in current string */
>  private int charCount;
>  private int extensionLength;
> +private int continueSkipBytes = 0;
>  
>  
>  public SSTDeserializer( BinaryTree strings )
> @@ -93,13 +95,14 @@
>  private void initVars()
>  {
>  runCount = 0;
> -continuationExpectedChars = 0;
> +continuationReadChars = 0;
>  unfinishedString = "";
>  //bytesInCurrentSegment = 0;
>  //stringDataOffset = 0;
>  wideChar = false;
>  richText = false;
>  extendedText = false;
> +continueSkipBytes = 0;
>  }
>  
>  /**
> @@ -107,14 +110,15 @@
>   * strings may span across multiple continuations. Read the SST
> record
>   * carefully before beginning to hack.
>   */
> -public void manufactureStrings( final byte[] data, final int
> initialOffset, short dataSize )
> +public void manufactureStrings( final byte[] data, final int
> initialOffset)
>  {
>  initVars();
>  
>  int offset = initialOffset;
> -while ( ( offset - initialOffset ) < dataSize )
> +final int dataSize = data.length;
> +while ( offset < dataSize )
>  {
> -int remaining = dataSize - offset + initialOffset;
> +int remaining = dataSize - offset;
>  
>  if ( ( remaining > 0 ) && ( remaining <
> LittleEndianConsts.SHORT_SIZE ) )
>  {
> @@ -122,26 +126,31 @@
>  }
>  if ( remaining == LittleEndianConsts.SHORT_SIZE )
>  {
> -setContinuationExpectedChars( LittleEndian.getUShort(
> data, offset ) );
> +  //JMH Dont know about this
> +setContinuationCharsRead( 0 );//LittleEndian.getUShort(
> data, offset ) );
>  unfinishedString = "";
>  

RE: cvs commit: jakarta-poi/src/java/org/apache/poi/hssf/record S STDeserializer.java SSTRecord.java

[Height, Jason]

This patch is not quite there yet. It will be shortly.

I accidentally posted before running the test cases and the
TestSSTRecord.testHugeStrings is failing

Jason

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 14 October 2003 4:48 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-poi/src/java/org/apache/poi/hssf/record
SSTDeserializer.java SSTRecord.java

jheight 2003/10/14 00:18:17

  Modified:src/java/org/apache/poi/hssf/record Tag: REL_2_BRANCH
SSTDeserializer.java SSTRecord.java
  Log:
  Patch to fix bugs 15556 and 22742.
  
  Double byte handeling of SSTDeserializer now works.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.5.2.1   +48 -33
jakarta-poi/src/java/org/apache/poi/hssf/record/SSTDeserializer.java
  
  Index: SSTDeserializer.java
  ===
  RCS file:
/home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/record/SSTDeserializer.ja
va,v
  retrieving revision 1.5
  retrieving revision 1.5.2.1
  diff -u -r1.5 -r1.5.2.1
  --- SSTDeserializer.java  30 Apr 2003 04:38:48 -  1.5
  +++ SSTDeserializer.java  14 Oct 2003 07:18:17 -  1.5.2.1
  @@ -62,13 +62,14 @@
* Handles the task of deserializing a SST string.  The two main entry
points are
*
* @author Glen Stampoultzis (glens at apache.org)
  + * @author Jason Height (jheight at apache.org)
*/
   class SSTDeserializer
   {
   
   private BinaryTree strings;
  -/** this is the number of characters we expect in the first
sub-record in a subsequent continuation record */
  -private int continuationExpectedChars;
  +/** this is the number of characters that have been read prior to the
continuation */
  +private int continuationReadChars;
   /** this is the string we were working on before hitting the end of
the current record. This string is NOT finished. */
   private String unfinishedString;
   /** this is true if the string uses wide characters */
  @@ -82,6 +83,7 @@
   /** Number of characters in current string */
   private int charCount;
   private int extensionLength;
  +private int continueSkipBytes = 0;
   
   
   public SSTDeserializer( BinaryTree strings )
  @@ -93,13 +95,14 @@
   private void initVars()
   {
   runCount = 0;
  -continuationExpectedChars = 0;
  +continuationReadChars = 0;
   unfinishedString = "";
   //bytesInCurrentSegment = 0;
   //stringDataOffset = 0;
   wideChar = false;
   richText = false;
   extendedText = false;
  +continueSkipBytes = 0;
   }
   
   /**
  @@ -107,14 +110,15 @@
* strings may span across multiple continuations. Read the SST
record
* carefully before beginning to hack.
*/
  -public void manufactureStrings( final byte[] data, final int
initialOffset, short dataSize )
  +public void manufactureStrings( final byte[] data, final int
initialOffset)
   {
   initVars();
   
   int offset = initialOffset;
  -while ( ( offset - initialOffset ) < dataSize )
  +final int dataSize = data.length;
  +while ( offset < dataSize )
   {
  -int remaining = dataSize - offset + initialOffset;
  +int remaining = dataSize - offset;
   
   if ( ( remaining > 0 ) && ( remaining <
LittleEndianConsts.SHORT_SIZE ) )
   {
  @@ -122,26 +126,31 @@
   }
   if ( remaining == LittleEndianConsts.SHORT_SIZE )
   {
  -setContinuationExpectedChars( LittleEndian.getUShort(
data, offset ) );
  +  //JMH Dont know about this
  +setContinuationCharsRead( 0 );//LittleEndian.getUShort(
data, offset ) );
   unfinishedString = "";
   break;
   }
   charCount = LittleEndian.getUShort( data, offset );
  +int charsRead = charCount;
   readStringHeader( data, offset );
   boolean stringContinuesOverContinuation = remaining <
totalStringSize();
   if ( stringContinuesOverContinuation )
   {
  -int remainingBytes = ( initialOffset + dataSize ) -
offset - stringHeaderOverhead();
  -setContinuationExpectedChars( charCount -
calculateCharCount( remainingBytes ) );
  -charCount -= getContinuationExpectedChars();
  +int remainingBytes = dataSize - offset -
stringHeaderOverhead();
  +//Only read the size of the string or whatever is left
before the
  +//continuation
  +charsRead = Math.min(charsRead, calculateCharCount(
remainingBytes ));
  +setContinuationCharsRead( charsRead );
  +if (charsRead == charCount) 

RE: Improving POIFS performance

[Height, Jason]

Hopefully when performance is looked at, copies of the entire file don't
need to be in memory. As it stands now when POIFS reads in a file, all of
the blocks are stored as byte arrays. Interestingly even though HSSF
understands the Workbook document stream, the byte array allocated within
POIFS remains. Ie if you have a 1 MB excel file then there is a 1MB byte
array in POIFS that is not cleared. Plus all of the temporary byte arrays
that are copied and created each time a HSSF record is read.

In a similar sense HSSF will write everything to one big byte array before
this is written to the POI.


 
Ideally, and it sounds like this is the rough idea with what is going to
happen, there should be no need for temporary byte arrays to be either held
or passed around and everything could be done via reading and writing to
streams.

Additionally it would be cool to be able to "register" known documents with
POIFS so that the decoded document ie "Workbook" could be held onto rather
than the byte array. Sure, for unknown documents we would probably hold onto
the raw bytes. I was thinking of something like this:

POIFSDocument doc = new POIFSDocument();
doc.registerDocument("WorkBook", org.apache.poi.hssf.model.Workbook.class);
doc.setPreserveUnknownDocuments(true);
doc.readDocument(new FileInputStream(theFile));

internally POIFSDocument would see that it had hit a "Workbook", see if it
had a registered "decoder", create a new instance of it and then pass that
portion of the stream to the document decoder. If we ever get really
adventurous we can start to add decoders for other documents in the file
such as macros, etc etc.

Internally the constructor to HSSFWorkbook would need to change to be able
to do something like:

public HSSFWorkbook(File f) {
  POIFSDocument doc = new POIFSDocument();
  doc.registerDocument("WorkBook",
org.apache.poi.hssf.model.Workbook.class);
  doc.setPreserveUnknownDocuments(true);
  doc.readDocument(new FileInputStream(theFile));

  setModel( (WorkBook)doc.getDocument("Workbook"));
}



Maybe what I have outlined will not be suitable for all approaches, in which
case support for a similar byte array approach as current would need to be
provided.

Jason


-Original Message-
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 9 October 2003 1:03 PM
To: POI Developers List
Subject: Re: Improving POIFS performance

At 11:35 AM 9/10/2003, you wrote:
> > So Glen said he should have time to help integrate it and sheppard it
and
> > Chris as a committer.
>
>Sounds good, FYI there have been some bug fixes to the code since you
>had a look at it. Glen, if/when you need an updated set just let me know.
>
>BTW I am not an Apache committer but am pretty involved with a couple of
>open source projects, so hopefully as a sheep I will not be too unruly.

Look forward to looking into what you've written.  It'll probably be on the 
weekend as I've just started on a new job and I want to get a good start
first.

Regards,


Glen Stampoultzis
[EMAIL PROTECTED]
http://members.iinet.net.au/~gstamp/glen/

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.

RE: VOTE: DBCell and Index Record patches on 2.0 branch

[Height, Jason]

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.

Jason



-Original Message-
From: Chris Nokleberg [mailto:[EMAIL PROTECTED] 
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
someone
> 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
to
> 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.

Chris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

RE: VOTE: DBCell and Index Record patches on 2.0 branch

[Height, Jason]

OK As you have requested I have patched the 2.0 branch with all my fixes
except the DBCell and Index record stuff.

I do have a patch that would probably apply to the 2.0 branch however it
would cause performance problems because of the way that the cells are
stored in the ValueRecordsAggregate class.

I think that I need to have a think about it because I need this patch to
fix some problems that I am having, but having used the HEAD, I don't have
much trust in it. I think that the implementation of ValueRecordsAggregate
in HEAD has changed so much between 2.0 and now (and for my liking it is way
too complex. I favour a Keep It Simple approach, without sacrificing too
much performance).

Jason


-Original Message-
From: Avik Sengupta [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 23 September 2003 3:34 AM
To: [EMAIL PROTECTED]
Subject: Re: VOTE: DBCell and Index Record patches on 2.0 branch

My intention on getting this patch to REL_2_BRANCH was the hope that this
would fix some of the blocking bugs for the 2.0 release.. particularly the
ExtSST patch. 

I wanted to test this hypothesis, but I have found it impossible to apply
the patch to the branch from the CVS generated diff. Even after a lot of
massaging, it fails to apply. Also, looking at some of the changes to
ValueRecordAggregate, i imagine the differences in the two branches would
preclude automagic patching. 

So, Jason, can you manually apply the changes to the branch and generate the
diff? Please? :)

As i said, the EXTsst stuff is probably more important, so could you split
that one out? 

Thanks
-
Avik


>Hello,

>Avik has suggested that my patches to support DBCell and Index records
>should go on the 2.0 release branch. As this is fairly new code and a
major
>chunk of functionality, I thought that we should probably put it to some
>sort of vote.

>If you are in favour of me checking in my changes to the 2.0 branch then
+1
>it.

>Jaslon

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.

RE: Change in behaviour between HEAD and 2.0 branch

[Height, Jason]

Actually just thinking about it some more, it would be a little difficult to
do it in the HSSF methods because a cell might not exist between the start
and end cells.

So I think that I will change ValueRecordAggregate.constructRecord to return
null for unspecified row or cell.

Jason

-Original Message-
From: Height, Jason [mailto:[EMAIL PROTECTED] 
Sent: Monday, 22 September 2003 3:32 PM
To: 'POI Mailing List'
Subject: Change in behaviour between HEAD and 2.0 branch

Hi All,

 

On the 2.0 branch if I call HSSFRow.getCell and pass in a column that
currently doesn't exist then I get a null returned. 

 

On HEAD if I do this then I get a RuntimeException from
ValueRecordsAggregate.constructRecord because the type returned from the
cell type int list is -1. The current code is actually incorrect because it
should throw an ArrayindexOutOfBoundsException if only the if statement is
correct.

 

The question is whether to change the ValueRecordsAggregate.constructRecord
implementation or HSSFSheet.getRow & HSSFRow.getCell to return null when a
row or cell doesn't currently exist.

 

Any suggestions? I am leaning towards the HSSFXXX methods because they are
at the user level.

 

Jason

 

 

 



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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

Change in behaviour between HEAD and 2.0 branch

[Height, Jason]

Hi All,

 

On the 2.0 branch if I call HSSFRow.getCell and pass in a column that
currently doesn't exist then I get a null returned. 

 

On HEAD if I do this then I get a RuntimeException from
ValueRecordsAggregate.constructRecord because the type returned from the
cell type int list is -1. The current code is actually incorrect because it
should throw an ArrayindexOutOfBoundsException if only the if statement is
correct.

 

The question is whether to change the ValueRecordsAggregate.constructRecord
implementation or HSSFSheet.getRow & HSSFRow.getCell to return null when a
row or cell doesn't currently exist.

 

Any suggestions? I am leaning towards the HSSFXXX methods because they are
at the user level.

 

Jason

 

 

 


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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Patch: Conversion of Shared Formula

[Height, Jason]

Hi All,



OK I decided to be a bit proactive and implement the conversion from Shared
Formulas to "inline" formulas.



This fixed my spreadsheet corruption issues. Previously the Shared Formula
record was not being written out with formulas still referencing it. Now the
shared formula record is not written out but the shared formulas are written
out as inline formulas. The end result is obviously an increase in the
output file size due to not using shared records. (No biggie we do this
already for numbers and the like).

 

This is the path that the MS Excel Developers Kit Book suggests (pg
386-387).

 

I have attached the patch inline (see below). If you all agree with the idea
then I will apply it. As I have said this corrects my problems with
corruption.

 

Note: The patch inline doesn't include the new Ref and Area Ptg classes that
I needed to create. They just extend ReferencePtg and AreaPtg to do their
work.

 

Jason

 

 

? java/org/apache/poi/hssf/record/formula/AreaAPtg.java

? java/org/apache/poi/hssf/record/formula/AreaNAPtg.java

? java/org/apache/poi/hssf/record/formula/AreaNPtg.java

? java/org/apache/poi/hssf/record/formula/AreaNVPtg.java

? java/org/apache/poi/hssf/record/formula/AreaVPtg.java

? java/org/apache/poi/hssf/record/formula/RefAPtg.java

? java/org/apache/poi/hssf/record/formula/RefNAPtg.java

? java/org/apache/poi/hssf/record/formula/RefNPtg.java

? java/org/apache/poi/hssf/record/formula/RefNVPtg.java

? java/org/apache/poi/hssf/record/formula/RefVPtg.java

Index: java/org/apache/poi/hssf/model/Sheet.java

===

RCS file:
/home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/model/Sheet.java,v

retrieving revision 1.42

diff -u -w -b -r1.42 Sheet.java

Index: java/org/apache/poi/hssf/model/Workbook.java

===

RCS file:
/home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/model/Workbook.java,v

retrieving revision 1.32

diff -u -w -b -r1.32 Workbook.java

Index: java/org/apache/poi/hssf/record/FormulaRecord.java

===

RCS file:
/home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/record/FormulaRecord.java
,v

retrieving revision 1.23

diff -u -w -b -r1.23 FormulaRecord.java

--- java/org/apache/poi/hssf/record/FormulaRecord.java  27 Jul 2003
18:49:52 - 1.23

+++ java/org/apache/poi/hssf/record/FormulaRecord.java   22 Sep 2003
04:37:25 -

@@ -64,6 +64,7 @@

 import java.util.Stack;

 

 import org.apache.poi.hssf.record.formula.Ptg;

+import org.apache.poi.util.BitField;

 import org.apache.poi.util.LittleEndian;

 

 /**

@@ -90,6 +91,9 @@

 private short field_3_xf;

 private doublefield_4_value;

 private short field_5_options;

+private BitField  alwaysCalc = new BitField(0x0001);

+private BitField  calcOnLoad = new BitField(0x0002);

+private BitField  sharedFormula = new BitField(0x0008);

 private int   field_6_zero;

 private short field_7_expression_len;

 private Stack field_8_parsed_expr;

@@ -271,6 +275,10 @@

 return field_5_options;

 }

 

+public boolean isSharedFormula() {

+  return sharedFormula.isSet(field_5_options);

+}

+

 /**

  * get the length (in number of tokens) of the expression

  * @return  expression length

@@ -574,6 +582,12 @@

   .append("\n");

 buffer.append(".options = ").append(getOptions())

 .append("\n");

+buffer.append("  .alwaysCalc =
").append(alwaysCalc.isSet(getOptions()))

+.append("\n");

+buffer.append("  .calcOnLoad =
").append(calcOnLoad.isSet(getOptions()))

+.append("\n");

+buffer.append("  .sharedFormula =
").append(sharedFormula.isSet(getOptions()))

+.append("\n");

 buffer.append(".zero= ").append(field_6_zero)

 .append("\n");

 buffer.append(".expressionlength=
").append(getExpressionLength())

Index: java/org/apache/poi/hssf/record/RecalcIdRecord.java

===

RCS file:
/home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/record/RecalcIdRecord.jav
a,v

retrieving revision 1.2

diff -u -w -b -r1.2 RecalcIdRecord.java

--- java/org/apache/poi/hssf/record/RecalcIdRecord.java 30 Apr 2003
04:38:48 -1.2

+++ java/org/apache/poi/hssf/record/RecalcIdRecord.java  22 Sep 2003
04:37:25 -

@@ -154,7 +154,8 @@

 }

 

 public boolean isNeeded() {

-return isNeeded;

+  return true;

+//return isNeeded;

 }

 

 public String toString()

Index: java/org/apache/poi/hssf/record/SharedFormulaRecord.java

===

RE: Sharted Formula Support

[Height, Jason]

Hi Avik,

I was wondering whether you were able to have a look at this over the
weekend?

I was thinking whether it would be a good idea to follow the developers kit
book advice and convert any shared formulas to formulas as they are parsed.
This could be done in the ValueRecordsAggregate.construct method.

However if you were able to fix the problem over the weekend this may be
more work than necessary.

Jason

-Original Message-
From: Avik Sengupta [mailto:[EMAIL PROTECTED] 
Sent: Friday, 19 September 2003 11:49 PM
To: POI Developers List
Subject: Re: Sharted Formula Support

Sorry, havent been able to look at mail all day...

I'll have a look at this on sunday, dont have a minute till then... but
here are my (random) thoughts...

I had fixed a significant bug similar to this. The issue was the string
record had to be AFTER the shared formula record rather than before for
string+shared formulas. This went in before 2.0pre3 on the 2.0 branch,
as well as on HEAD. 

If you check the testcase called test15228 in TestBugs.java, and its
associated xl file (15228.xls). 

So clearly, while SOME shared formulas work on rewrite, some dont.

There are some people working on SharedFormulas, but primarily on its
toFormulaString implementation. 

As i said, the earliest i can take a look at this is on sunday.. which i
will. 

Regards
-
Avik

On Fri, 2003-09-19 at 12:28, Height, Jason wrote:
> Hello All,
> 
>  
> 
> I think that I have found where excel is corrupting in my examples. It
seems
> that the workbook that I am trying to copy has a Shared Formula record in
> it. Looking at the ValueRecordAggregate it seems that these records are
> inadventenly thrown away!!!
> 
>  
> 
> The way that the records are added in the construct method and then
decoded
> in the insertCell method is flawed. The SharedFormulaRecord is added to
the
> FormulaAggregate AFTER the FormulaAggregate is decoded in the insertCell
> method.
> 
>  
> 
> Has anyone else experienced this or is working on shared formula support?
> 
>  
> 
> Jason
> 
>


> 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.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

VOTE: DBCell and Index Record patches on 2.0 branch

[Height, Jason]

Hello,

 

Avik has suggested that my patches to support DBCell and Index records
should go on the 2.0 release branch. As this is fairly new code and a major
chunk of functionality, I thought that we should probably put it to some
sort of vote.

 

If you are in favour of me checking in my changes to the 2.0 branch then +1
it.

 

Jaslon

 

 


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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Sharted Formula Support

[Height, Jason]

Hello All,

 

I think that I have found where excel is corrupting in my examples. It seems
that the workbook that I am trying to copy has a Shared Formula record in
it. Looking at the ValueRecordAggregate it seems that these records are
inadventenly thrown away!!!

 

The way that the records are added in the construct method and then decoded
in the insertCell method is flawed. The SharedFormulaRecord is added to the
FormulaAggregate AFTER the FormulaAggregate is decoded in the insertCell
method.

 

Has anyone else experienced this or is working on shared formula support?

 

Jason


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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Major bug in REL2_BRANCH

[Height, Jason]

This sounds like a similar issue that I am tracking down on HEAD. I have a
spreadsheet that I read into HSSF and then write it straight back out and it
gets corrupted! I am trying to narrow it down, so far I have narrowed it
down to a single sheet. If I have a test case then I will post it.

Jason

-Original Message-
From: Avik Sengupta [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 18 September 2003 11:34 PM
To: POI Developers List
Subject: Re: Major bug in REL2_BRANCH

works for me.. are you trying on an empty workbook?? doesnt work in that
case.. there is a bugzilla bug for that. 

Otherwise, it must be workbook specific.. 

On Thu, 2003-09-18 at 19:07, Glen Stampoultzis wrote:
> I don't have a testcase prepared yet but you can try running 
> ReadWriteWorkbook.java.  The workbook will be written but without the 
> changes to the row.
> 
> Regards,
> 
> Glen
> 
> At 11:07 PM 18/09/2003, you wrote:
> >testcase pls? i am not aware of anything beyond whats on bugzilla. I am
> >using pre2 in production, tho arguably for simple cases.
> >
> >On Thu, 2003-09-18 at 18:11, Glen Stampoultzis wrote:
> > > Looks like there's a major bug with rewriting workbooks.  It doesn't
work
> > > at all.  Is this a known bug?
> > >
> > >
> > >
> > > Glen Stampoultzis
> > > [EMAIL PROTECTED]
> > > http://members.iinet.net.au/~gstamp/glen/
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> Glen Stampoultzis
> [EMAIL PROTECTED]
> http://members.iinet.net.au/~gstamp/glen/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

RE: LabelRecord Uncompressed

[Height, Jason]

Hmm I wonder if we should be using a UnicodeString here?

I suspect that all Records should actually use & hold onto the UnicodeString
class which knows how to decode compressed/uncompressed, rich text etc.

Looking at the Excel Developers Kit it seems to indicate this. At the moment
we potentially throw away information embedded within the excel Unicode
string when we store it as a java String object. This change would touch
every record that contains a string that already doesn't use UnicodeString.
For example. LabelRecord, HeaderRecord, FooterRecord, etc.

Look at the source for HeaderRecord, whose to say that the string is always
compressed?

Jason

-Original Message-
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 18 September 2003 1:11 PM
To: POI Developers List
Subject: Re: LabelRecord Uncompressed

I think there is a marker which says whether or not it is one or the other.

On 9/17/03 11:07 PM, "Height, Jason" <[EMAIL PROTECTED]> wrote:

> Hello
> 
> 
> 
> On the head I get some weird strings for uncompressed label records due to
> the following code:
> 
> 
> 
> field_6_value = StringUtil.getFromUnicodeBE(data, 9 + offset,
> 
>   field_4_string_len);
> 
> 
> 
> Now I think that this should be (well this causes it to work):
> 
>  field_6_value = StringUtil.getFromUnicodeLE(data, 9 + offset,
> 
>   field_4_string_len);
> 
> 
> 
> Or is that only because I am testing on a LE machine. I thought that the
> byte swapping was handled at a much lower level.
> 
> 
> 
> I know that a lot of this stuff changed during my absence, Should I change
> this to LE ??
> 
> 
> 
> Jason
> 
> 
> 
>

--
> --
> 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.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-- 
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI

http://jakarta.apache.org/poi
For Java and Excel, Got POI?

The views expressed in this email are those of the author and are almost
definitely not shared by the Apache Software Foundation, its board or its
general membership.  In fact they probably most definitively disagree with
everything espoused in the above email.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

LabelRecord Uncompressed

[Height, Jason]

Hello

 

On the head I get some weird strings for uncompressed label records due to
the following code:

 

  field_6_value = StringUtil.getFromUnicodeBE(data, 9 + offset,

field_4_string_len);

 

Now I think that this should be (well this causes it to work):

   field_6_value = StringUtil.getFromUnicodeLE(data, 9 + offset,

field_4_string_len);

 

Or is that only because I am testing on a LE machine. I thought that the
byte swapping was handled at a much lower level.

 

I know that a lot of this stuff changed during my absence, Should I change
this to LE ??

 

Jason

 


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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: jakarta-poi/src/java/org/apache/poi/hssf/record/a ggregates RowRecordsAggregate.java ValueRecordsAggregate.java

[Height, Jason]

Hi All,

As you can see this patch was quite large. It was mainly from my early patch
(before the performance improvements). 

I haven't attached this to the 2.0 branch because it is major functionality
enhancement. I know at least one company that will be using this code though
;-)

I will close out the bugzilla bug that this was in response to.

Jason

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 18 September 2003 11:41 AM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-poi/src/java/org/apache/poi/hssf/record/aggregates
RowRecordsAggregate.java ValueRecordsAggregate.java

jheight 2003/09/17 19:10:50

  Modified:src/java/org/apache/poi/hssf/model Sheet.java
   src/java/org/apache/poi/hssf/record DBCellRecord.java
ExtSSTInfoSubRecord.java ExtSSTRecord.java
IndexRecord.java SSTDeserializer.java
SSTRecord.java SSTSerializer.java
   src/java/org/apache/poi/hssf/record/aggregates
RowRecordsAggregate.java ValueRecordsAggregate.java
  Log:
  Fixed ExtSST serialization (length not calculated correctly)
  Implemented DBCellRecord and IndexRecord serialization
  
  

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.

Test build target not working & Checkins

[Height, Jason]

Hello

 

Phew. Well I am back from a long (well not long enough) holiday. I have a
corruption issue I am trying to track down in POI.

 

I have just tried to run the test target in the build and it is failing. Is
this a known issue?

 

Also I just checked in a small change to LabelRecord. I assume I should be
checking these changes into HEAD?

 

Jason


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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ValueRecordsAggregate performance branch

[Height, Jason]

Andy,

Ok I guess that I don't completely understand what is going on then! I
thought that the existing insertCell method would be all that is required,
without the need to decomposing the cell inorder to save the cell ie simply
save the object reference as was originally being done, but in a structure
that would enable fast row lookup and fast row cell iteration.

Since I don't exactly know what is going on I think that it may be best if
you do the merge of this class into the main branch. After which I will
supply another patch to 9576.

Jason


-Original Message-
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 20 February 2003 23:42
To: Height, Jason
Subject: Re: ValueRecordsAggregate performance branch [Scanned For Viruses]

Height, Jason wrote:

> Andy,
>
> Ok I think that I roughly understand what you are trying to do on the 
> performance branch wrt ValueRecordsAggregate in that you are trying to 
> store the contents of a cell as a primitive rather than as an object 
> (LabelSST etc). I can see that this will provide memory improvements, 
> according to OptimizeIt a LabelSST object occupies 30bytes whereas you 
> are only storing the index to the string which is a double ie 8 bytes, 
> so there is a 22 byte overhead per LabelSST object.
>
Note that I do this slightly wastefully, Only 4 bytes are really 
required, but in order to make things clean and not have yet another 
array, its stored in the same place as #s.

> However if I am going to iterate over each cell wont there will be 
> some performance problems in that the ValueRecordsAggregate will need 
> to instanciate and then GC a lot of objects? So although you have 
> saved memory for storing the workbook, additional memory and 
> processing is required to use the workbook!
>
Eventually.  I'm into refactoring and stuff.  So this change is pretty 
much a huge refactoring.  Doing it all at once seems wrought with 
disaster (at least to me).  My thought was 1st graft the new method into 
existing structures.  Then later make another pass of optimizations 
(maybe after 2.0, not sure). 

> I think that the VRAIterator is FANTASTIC. It fixes my performance 
> problems with my DBCell etc patch.
>  
>
Cool.

>
> Why couldn't we just implement the data structures for quick access 
> without decomposing them from the java objects? In my opinion (for 
> what it is worth) the conversion from and to the java object 
> representations is not a good idea, it makes the whole thing much more 
> complicated, needs to expose additional methods, will be harder to 
> maintain and the CPU time required to create and maintain the data in 
> both directions may be more significant (and not worth the memory saving).
>
In due time.  Note though that some decomposition is necessary to make 
the code manageable (even if it wastes memory).  I can't imagine bit 
twiddling on byte arrays of this stuff.  Furtheremore if the file were 
treated too flatly, we'd end up doing lots of extra array copies 
whenever an insert was done in the middle...  Still I think memory 
mapping should be a goal for a post-2.0 release (formulas and graphing 
first).

> PS Ever noticed that the Record object holds onto the byte data array 
> from which it is created. It doesn't need to. Basically it is wasting 
> as much memory as the size of the excel file that was opened. Is this 
> intentional?
>
Every record does?  If so, that is a big mistake IMNSHO.

Anyhow, no need to write this privately.  I'm thick skinned when the 
conversation is technical :-).  We sould eliminate the record holding 
onto the data if it indeed is doing that.  Thats a monumental waste of 
memory.

Oh yeah.. I meant to propose you a committergotta do that this morning.

-Andy

> Jason
>
>
>


> 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.




This e-mail (including attachments) is confidential information of Australian 
Submari

DBCell, IndexRecord & ExtSSTRecord patch performance

[Height, Jason]

I have investigated the poor performance as a result of the patch that I
wrote for Bug 9576.

 

Most (95%) of the performance can be recovered with adjustments to the
ValueRecordsAggregate. My patch relies heavily on being able to serialize a
block of cells. A cell block is defined by a start row and end row and
should be serialized in row-cell order. Currently (as I originally noted)
the performance is due to the fact that there is no way to quickly get the
cells for a given row number, the current patch creates an iterator over the
result of the call to values() of the TreeMap FOR EACH ROW THAT IS WRITTEN!.
This iterator is traversed in order from start to finish OVER ALL CELLS not
just for a given row.

 

Obviously you can imagine the amount of memory being allocated and GC's and
also the amount of work needed to write a block of cells.

 

To arrive at my performance conclusions I altered the way that cells are
stored (The TreeMap is Keyed by the row number ie new
Integer(cel.getRowNum()) and contains a ArrayList of cells) and also wrote
my own custom iterator that will return the rows in correct order (but I
still need to return the cells for a row in correct order and make sure that
duplicate inserts only insert one cell for a given row and cell number).

 

I have looked at Andy's implementation of ValueRecordsAggregate in the
performance-branch and this is doing a very similar thing in terms of the
ability to quickly get the cells allocated to a row. To be honest it seems
to be a bit complicated but maybe it needs to be.

 

Can we merge the performance-branch ValueRecordsAggregate class or should I
continue along my original approach listed above.

 

When is 1.9 being released?

 

Thanks

 

Jason Height

Systems Engineer

ASC

 


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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SanityChecker problem with DBCell, Index and ExtSST Patch [Scanned For Viruses]

[Height, Jason]

Yes I agree it is messy. I will try to get it to create the records prior to
writing them out. It wont be easy and will take some time to patch.

I wouldn't wait on this patch before doing a development release.

Jason

-Original Message-
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED]] 
Sent: Monday, 10 February 2003 20:58
To: POI Developers List
Subject: Re: SanityChecker problem with DBCell, Index and ExtSST Patch
[Scanned For Viruses]

At 02:41 PM 10/02/2003 +1030, you wrote:
>Hello,
>
>
>
>Currently the SanityChecker fails for my ExtSST patch because the
>ExtSSTRecords are only written out during the serialization process. They
>are not available in the list of records that are returned from the
>Workbook.getRecords method hence the sanity checker fails.
>
>
>
>What I could do is write the workbook file out and call the SanityChecker
>after reloading the records into a list using the
>RecordFactory.createRecords method.
>
>
>
>Is this acceptable to every one?
>
>
>
>Jason

I guess that would get you around the problem.  It seems a little messy 
though.  Is there any other way to trigger the creation of those records 
before writing out the stream?

Regards,

Glen




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

SanityChecker problem with DBCell, Index and ExtSST Patch

[Height, Jason]

Hello,

 

Currently the SanityChecker fails for my ExtSST patch because the
ExtSSTRecords are only written out during the serialization process. They
are not available in the list of records that are returned from the
Workbook.getRecords method hence the sanity checker fails.

 

What I could do is write the workbook file out and call the SanityChecker
after reloading the records into a list using the
RecordFactory.createRecords method.

 

Is this acceptable to every one?

 

Jason


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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ExtSSTRecord [Scanned For Viruses] [Scanned For Viruses] [Sca nned For Viruses] [Scanned For Viruses]

[Height, Jason]

The performance cost is not bad, I just wanted to mention that there is one.


What happens in my implementation is that I need to be able to write out a
set of rows and a set of cells for those rows. Since a TreeMap is used to
store the rows and values I call TreeMap.values().iterator() to traverse the
rows and values.

So the cost is the memory required to create a Collection, Iterator and then
the performance cost of iterating the rows & values. In my experiments the
cost isn't noticeable, although I was only using excel files that have a
small number of rows (~35), but around 400 cells.

Jason


-Original Message-
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, 4 February 2003 23:55
To: POI Developers List
Subject: Re: ExtSSTRecord [Scanned For Viruses] [Scanned For Viruses] [Sca
nned For Viruses] [Scanned For Viruses]

>
>
>One point I made in the bug report was that there is a performance cost
>associated with correctly implementing these records (need to temporary
>Collections and iterators over the TreeMap collections in the Aggregate
>classes). I thought that I would address the performance issues of the
patch
>after the *working* patch is applied.
> 
>
if its not *too* bad then +1.. . If you mean like years then well I 
might feel differently.

>Jason
>
>-Original Message-
>From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] 
>Sent: Tuesday, 4 February 2003 13:53
>To: POI Developers List
>Subject: Re: ExtSSTRecord [Scanned For Viruses] [Scanned For Viruses]
>[Scanned For Viruses]
>
>Awesome!
>
>
>
>---
-
>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.
>
>  
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

RE: ExtSSTRecord [Scanned For Viruses] [Scanned For Viruses] [Scanned For Viruses]

[Height, Jason]

Hi all,

The good news is that I have been able to find my bug in the INDEX and
DBCell records. I can now copy a functioning excel file and the copy will
successfully import into Access.

The bad news is that the ExtSSTRecord implementation is required to allow a
excel workbook created from scratch (or a workbook that has been modified)
to import correctly. I should be able to have an implementation and patch by
tomorrow though.

One point I made in the bug report was that there is a performance cost
associated with correctly implementing these records (need to temporary
Collections and iterators over the TreeMap collections in the Aggregate
classes). I thought that I would address the performance issues of the patch
after the *working* patch is applied.
 
Jason

-Original Message-
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, 4 February 2003 13:53
To: POI Developers List
Subject: Re: ExtSSTRecord [Scanned For Viruses] [Scanned For Viruses]
[Scanned For Viruses]

Awesome!




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.

RE: ExtSSTRecord [Scanned For Viruses] [Scanned For Viruses]

[Height, Jason]

Andy,

I have almost finished implementing INDEX & DBCell records. The patch that I
attached to the bug report is not 100% correct, however even with it not
being 100% correct there are some test cases that I have where the INDEX &
DBCell records are written correctly and the excel file still doesn't import
into access, so I assumed the problem was with the EXTSSTRecord since this
was the only record that looked "different" in the results from the
BiffViewer.

Give me 24 hours and I should have another patch that is 100% correct for
DBCell and index records.

Jason


 
-Original Message-
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, 4 February 2003 13:39
To: POI Developers List
Subject: Re: ExtSSTRecord [Scanned For Viruses] [Scanned For Viruses]

I think its the INDEX->DBCell + this most likely.  We really need to get 
to writing those.

Height, Jason wrote:
> Andy, 
> 
> Ok I think that I am well on the way to "fixing it".
> 
> There was a bug in the EXTSSTRecord.fillFields so no Info sub records were
> being created (so they weren't being displayed in the BiffViewer, and
> therefore I couldn't understand how the hell it was working).
> 
> The Excel Developers book indicates that it is required when an excel file
> has LabelSST and SST records.
> 
> This might be contributing to my import in to Access current problems, so
> that's why I am investigating it.
> 
> Jason
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, 4 February 2003 10:27
> To: POI Developers List
> Subject: Re: ExtSSTRecord [Scanned For Viruses]
> 
> This record is for "optimization".  It doesn't appear to be necessary and
> its completely undocumented (or the documentation is incomprehensible).
> OpenOffice doesn't seem to make this record either.
> 
> -Andy
> - Original Message -
> From: "Height, Jason" <[EMAIL PROTECTED]>
> To: "'POI Mailing List'" <[EMAIL PROTECTED]>
> Sent: Monday, February 03, 2003 5:05 PM
> Subject: ExtSSTRecord
> 
> 
> 
>>Hi everyone,
>>
>>
>>
>>What is the deal with the ExtSSTRecord? There are a few oddities with the
>>implementation that either I don't understand or are wrong
>>
>>
>>
>>Here is the getRecordSize method:
>>
>>
>>
>>public int getRecordSize()
>>
>>{
>>
>>return 6 + 0x3fa - 2;
>>
>>}
>>
>>
>>
>>What is that magic 0x3fa number? Shouldn't it be:
>>
>>
>>
>>public int getRecordSize()
>>
>>{
>>
>>return 6 + 8*getNumInfoRecords();
>>
>>}
>>
>>
>>
>>A similar issue with the serialise method with also contains that magic
>>number (0x3fa) ???
>>
>>
>>
>>I will change it to be what I think is right (as depicted above) unless
>>someone has an objection or my understanding is not correct.
>>
>>
>>
>>Please let me know..
>>
>>
>>
>>Jason
>>
>>--
> 
> --
> 
>>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.
> 
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>


> 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 

RE: ExtSSTRecord [Scanned For Viruses]

[Height, Jason]

Andy, 

Ok I think that I am well on the way to "fixing it".

There was a bug in the EXTSSTRecord.fillFields so no Info sub records were
being created (so they weren't being displayed in the BiffViewer, and
therefore I couldn't understand how the hell it was working).

The Excel Developers book indicates that it is required when an excel file
has LabelSST and SST records.

This might be contributing to my import in to Access current problems, so
that's why I am investigating it.

Jason

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, 4 February 2003 10:27
To: POI Developers List
Subject: Re: ExtSSTRecord [Scanned For Viruses]

This record is for "optimization".  It doesn't appear to be necessary and
its completely undocumented (or the documentation is incomprehensible).
OpenOffice doesn't seem to make this record either.

-Andy
- Original Message -
From: "Height, Jason" <[EMAIL PROTECTED]>
To: "'POI Mailing List'" <[EMAIL PROTECTED]>
Sent: Monday, February 03, 2003 5:05 PM
Subject: ExtSSTRecord


> Hi everyone,
>
>
>
> What is the deal with the ExtSSTRecord? There are a few oddities with the
> implementation that either I don't understand or are wrong
>
>
>
> Here is the getRecordSize method:
>
>
>
> public int getRecordSize()
>
> {
>
> return 6 + 0x3fa - 2;
>
> }
>
>
>
> What is that magic 0x3fa number? Shouldn't it be:
>
>
>
> public int getRecordSize()
>
> {
>
> return 6 + 8*getNumInfoRecords();
>
> }
>
>
>
> A similar issue with the serialise method with also contains that magic
> number (0x3fa) ???
>
>
>
> I will change it to be what I think is right (as depicted above) unless
> someone has an objection or my understanding is not correct.
>
>
>
> Please let me know..
>
>
>
> Jason
>
> --
--
> 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.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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.

ExtSSTRecord

[Height, Jason]

Hi everyone,

 

What is the deal with the ExtSSTRecord? There are a few oddities with the
implementation that either I don't understand or are wrong

 

Here is the getRecordSize method:

 

public int getRecordSize()

{

return 6 + 0x3fa - 2;

}

 

What is that magic 0x3fa number? Shouldn't it be:

 

public int getRecordSize()

{

return 6 + 8*getNumInfoRecords();

}

 

A similar issue with the serialise method with also contains that magic
number (0x3fa) ???

 

I will change it to be what I think is right (as depicted above) unless
someone has an objection or my understanding is not correct.

 

Please let me know..

 

Jason


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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DBCell & Index .. Ouch!

[Height, Jason]

Ok

 

Here are my troubles with implementing the DBCell and Index records
correctly in HSSF. I was wondering if I am missing something.

 

I was going to simply implement this functionality within the
RowRecordAggregate, however this cannot be done because:

 

1: The offsets to DBCell records from the Index record are relative to the
first Workbook BOF record. Of the two simple workbooks from excel that I
have run through the BOF record was at position 0, but I assume that this is
not always the case (pg 441 of Excel97 Dev Kit gives an example where the
BOF is not 0). In anycase the location of the BOF record is not accessible
from the RowRecordAggregate, but would be in the Workbook class. Is this
just a misprint, is it really possible for the workbook BOF to not be the
first record and therefore at offset 0?

 

2: The DBCell record references the first cell from a row and of course cell
references are also not available in the RowRecordsAggregate.

 

So it appears that the Sheet.serialize(int offset, byte[] data) is about to
get more complex, my only problem is how to locate the Workbook BOF from a
Sheet? I don't think that this can be done at the moment (there is not
Workbook reference from a sheet), so I think that the createSheet will need
to be supplied a reference to the Workbook so it can traverse the Workbook
records until it finds the BOF.

 

Any other comments appreciated.

 

Thanks

 

Jason

 

 


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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Crash in HSSF [Scanned For Viruses]

[Height, Jason]

Jim,

The best bet is to read the section "Submitting Patches" at
http://jakarta.apache.org/poi/getinvolved/index.html

Jason

-Original Message-
From: Jim Cobban [mailto:[EMAIL PROTECTED]] 
Sent: Friday, 13 December 2002 11:14
To: POI Developer Maillist
Subject: Crash in HSSF [Scanned For Viruses]

I tracked down the MethodNotFoundError.  It was one of my classes which I
had not recompiled.  So with the change to HeaderRecord and FooterRecord I
can now read all of my spreadsheets.

That just leaves the problem that I cannot update the jar to incorporate the
changes to HeaderRecord and FooterRecord.  However I can clearly just unpack
the whole jar, replace the two files, and create a brand new jar.

What should I do to contribute the fix?

Jim Cobban   [EMAIL PROTECTED]
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438


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 ASC by someone with authority to do so.

RE: DO NOT REPLY [Bug 12165] - Need a way to get a formatted string for a numeric field when reading a file.

[Height, Jason]

This sort of thing has been done already in the Swing based Viewer
application.

It wouldnt be hard to create a class that encapsulates this functionality.
Although there would be a bit more work to cater for custom formats. (Which
is why i havent done it yet!)

Jason

> -Original Message-
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, 2 September 2002 10:02
> To:   [EMAIL PROTECTED]
> Subject:  DO NOT REPLY [Bug 12165]  -  Need a way to get a formatted
> string for a numeric field when reading a file.
> 
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> .
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
> INSERTED IN THE BUG DATABASE.
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12165
> 
> Need a way to get a formatted string for a numeric field when reading a
> file.
> 
> [EMAIL PROTECTED] changed:
> 
>What|Removed |Added
> --
> --
>  Status|NEW |RESOLVED
>  Resolution||WONTFIX
> 
> 
> 
> --- Additional Comments From [EMAIL PROTECTED]  2002-09-02 00:32
> ---
> ask this question on the list.  I don't think this is a bug and this
> description
> is insufficient for a bug report.
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 

TextObject Record

[Height, Jason]

Hi all,

I recently received my own copy of the ms excel 97 developers kit book from
amazon so I thought that i would start to contribute to the supported
records.

I was going to implement the ability to add comments. The first part of this
is to implement the text object record 1b6.

This record has two continue record that follow the text object record. The
first continue record contains the text. I have two questions:

1) The first byte of the text continue record indicates whether the
following bytes indicate a string that is stored as compressed unicode (only
stores the low bytes) or uncompressed unicode (both low and high byte are
stored). As far as i can tell the org.apache.poi.util.StringUtil.getUnicode*
methods doesnt handle both of these cases. Is that correct? Is there a
utility class that will read this, or do i have to create my own methods.

2) Once i have successfully read in the two continue records, how are they
written out again? Will i need to write all records (the Text object, first
continue record and second continue record) in the text object serialize
method? Will i need to override the getRecordSize to cater for all three
records so that the byte array that is passedinto the serialize method is
the correct size?

Thanks

Jason Height




--
To unsubscribe, e-mail:   
For additional commands, e-mail: