cvs commit: jakarta-poi/src/java/org/apache/poi/hssf/record LabelRecord.java

2003-09-17 Thread jheight
jheight 2003/09/16 22:34:29 Modified:src/java/org/apache/poi/hssf/record LabelRecord.java Log: Fixed zero length Label string reading Fixed incorrect offset for uncompressed unicode Revision ChangesPath 1.8 +32 -9 jakarta-poi/src/java/org/apache/poi/hssf/recor

Re: Test build target not working & Checkins

2003-09-17 Thread Avik Sengupta
>I have just tried to run the test target in the build and it is >failing. Is this a known issue? HEAD is very much a work in progress, there are failing testcases. REL_2_BRANCH if stable. >Also I just checked in a small change to LabelRecord. >I assume I should be checking these changes into H

RE: Test build target not working & Checkins

2003-09-17 Thread Eric Pugh
Would that be why getrow() is not working? (see my earlier email Possible Bug HSSFSheet.getRow(row))...? Eric Pugh > -Original Message- > From: Avik Sengupta [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 17, 2003 9:04 AM > To: POI Developers List > Subject: Re: Test build target

Re: Test build target not working & Checkins

2003-09-17 Thread Andrew C. Oliver
On 9/17/03 2:20 AM, "Height, Jason" <[EMAIL PROTECTED]> wrote: > 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 >

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

2003-09-17 Thread jheight
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

DO NOT REPLY [Bug 9576] - [PATCH] DBCELL, INDEX EXTSST (was Acess 97 import)

2003-09-17 Thread bugzilla
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

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

2003-09-17 Thread 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 o

LabelRecord Uncompressed

2003-09-17 Thread 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

Re: LabelRecord Uncompressed

2003-09-17 Thread Tetsuya Kitahata
On Thu, 18 Sep 2003 12:37:00 +0930 (Subject: LabelRecord Uncompressed) "Height, Jason" <[EMAIL PROTECTED]> wrote: > 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, >

Re: LabelRecord Uncompressed

2003-09-17 Thread Andrew C. Oliver
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 = St

cvs commit: jakarta-poi/src/java/org/apache/poi/hssf/record LabelRecord.java

2003-09-17 Thread jheight
jheight 2003/09/17 20:44:56 Modified:src/java/org/apache/poi/hssf/record LabelRecord.java Log: Based on my trials and Tetsuya's email i have changed this to use getFromUnicodeLE Revision ChangesPath 1.9 +1 -1 jakarta-poi/src/java/org/apache/poi/hssf/record/Labe

RE: LabelRecord Uncompressed

2003-09-17 Thread 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

Re: LabelRecord Uncompressed

2003-09-17 Thread Andrew C. Oliver
IIRC, The only problem is that Excel doesn't mark it consistently. Thus the UnicodeString actually only covers *one* way that Excel does this. On 9/17/03 11:56 PM, "Height, Jason" <[EMAIL PROTECTED]> wrote: > Hmm I wonder if we should be using a UnicodeString here? > > I suspect that all Record

cvs commit: jakarta-poi/src/java/org/apache/poi/hssf/record StringRecord.java

2003-09-17 Thread jheight
jheight 2003/09/17 22:21:33 Modified:src/java/org/apache/poi/hssf/record StringRecord.java Log: StringRecords are inValueSection. Revision ChangesPath 1.7 +7 -1 jakarta-poi/src/java/org/apache/poi/hssf/record/StringRecord.java Index: StringRecord.java =