date:20030917

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
  ===
  RCS file: 
/home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/record/StringRecord.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- StringRecord.java 19 Aug 2003 14:07:40 -  1.6
  +++ StringRecord.java 18 Sep 2003 05:21:33 -  1.7
  @@ -165,6 +165,12 @@
   return (field_2_unicode_flag == 1);
   }
   
  +public boolean isInValueSection()
  +{
  +return true;
  +}
  +
  +
   /**
* called by the class that is responsible for writing this sucker.
* Subclasses should implement this so that their data is passed back in a
  @@ -237,7 +243,7 @@
   buffer.append("[/STRING]\n");
   return buffer.toString();
   }
  -
  +
   public Object clone() {
   StringRecord rec = new StringRecord();
   rec.field_1_string_length = this.field_1_string_length;
  
  
  

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

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

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

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/LabelRecord.java
  
  Index: LabelRecord.java
  ===
  RCS file: 
/home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/record/LabelRecord.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- LabelRecord.java  17 Sep 2003 05:34:29 -  1.8
  +++ LabelRecord.java  18 Sep 2003 03:44:56 -  1.9
  @@ -153,7 +153,7 @@
   if (field_4_string_len > 0) {
 if (isUnCompressedUnicode())
 {
  -  field_6_value = StringUtil.getFromUnicodeBE(data, 9 + offset,
  +  field_6_value = StringUtil.getFromUnicodeLE(data, 9 + offset,
   field_4_string_len);
 }
 else
  
  
  

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

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 = 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]

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,
> 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 ??

Agreed.

__ Tetsuya <[EMAIL PROTECTED]> __


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

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

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

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.cgi?id=9576

[PATCH] DBCELL, INDEX EXTSST (was Acess 97 import)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-09-18 02:25 ---
I have patched the head and as of now it should work fine.

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

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
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
  
  Can now import into MS Access. Cool! Both of the above fixes were required to make 
this work.
  
  Revision  ChangesPath
  1.42  +81 -184   jakarta-poi/src/java/org/apache/poi/hssf/model/Sheet.java
  
  Index: Sheet.java
  ===
  RCS file: /home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/model/Sheet.java,v
  retrieving revision 1.41
  retrieving revision 1.42
  diff -u -r1.41 -r1.42
  --- Sheet.java6 Sep 2003 19:15:53 -   1.41
  +++ Sheet.java18 Sep 2003 02:10:50 -  1.42
  @@ -288,6 +288,15 @@
{
retval.windowTwo = (WindowTwoRecord) rec;
}
  +else if ( rec.getSid() == DBCellRecord.sid )
  +{
  +rec = null;
  +}
  +else if ( rec.getSid() == IndexRecord.sid )
  +{
  +rec = null;
  +}
  +

   if (rec != null)
   {
  @@ -704,49 +713,6 @@
* Serializes all records in the sheet into one big byte array.  Use this to 
write
* the sheet out.
*
  - * @return byte[] array containing the binary representation of the records in 
this sheet
  - *
  - */
  -
  -public byte [] serialize()
  -{
  -log.log(log.DEBUG, "Sheet.serialize");
  -
  -// addDBCellRecords();
  -byte[] retval= null;
  -
  -// ArrayList bytes = new ArrayList(4096);
  -intarraysize = getSize();
  -intpos   = 0;
  -
  -// for (int k = 0; k < records.size(); k++)
  -// {
  -// bytes.add((( Record ) records.get(k)).serialize());
  -//
  -// }
  -// for (int k = 0; k < bytes.size(); k++)
  -// {
  -// arraysize += (( byte [] ) bytes.get(k)).length;
  -// log.debug((new StringBuffer("arraysize=")).append(arraysize)
  -// .toString());
  -// }
  -retval = new byte[ arraysize ];
  -for (int k = 0; k < records.size(); k++)
  -{
  -
  -// byte[] rec = (( byte [] ) bytes.get(k));
  -// System.arraycopy(rec, 0, retval, pos, rec.length);
  -pos += (( Record ) records.get(k)).serialize(pos,
  -retval);   // rec.length;
  -}
  -log.log(log.DEBUG, "Sheet.serialize returning " + retval);
  -return retval;
  -}
  -
  -/**
  - * Serializes all records in the sheet into one big byte array.  Use this to 
write
  - * the sheet out.
  - *
* @param offset to begin write at
* @param data   array containing the binary representation of the records in 
this sheet
*
  @@ -756,40 +722,69 @@
   {
   log.log(log.DEBUG, "Sheet.serialize using offsets");
   
  -// addDBCellRecords();
  -// ArrayList bytes = new ArrayList(4096);
  -// int arraysize = getSize();   // 0;
  -int pos   = 0;
  -
  -// for (int k = 0; k < records.size(); k++)
  -// {
  -// bytes.add((( Record ) records.get(k)).serialize());
  -//
  -// }
  -// for (int k = 0; k < bytes.size(); k++)
  -// {
  -// arraysize += (( byte [] ) bytes.get(k)).length;
  -// log.debug((new StringBuffer("arraysize=")).append(arraysize)
  -// .toString());
  -// }
  +int pos = offset;
  +boolean haveSerializedIndex = false;
   for (int k = 0; k < records.size(); k++)
   {
  -// byte[] rec = (( byte [] ) bytes.get(k));
  -// System.arraycopy(rec, 0, data, offset + pos, rec.length);
   Record record = (( Record ) records.get(k));
  +int startPos = pos;
  +//Once the rows have been found in the list of records, start
  +//writing out the blocked row information. This includes the DBCell 
references
  +if (record instanceof RowRecordsAggregate) {
  +  pos += ((RowRecordsAggregate)record).serialize(pos, data, cells);   
// rec.length;
  +} else if (record instanceof ValueRecordsAggregate) {
  +  //Do nothing here. The records were serialized during the 
RowRecordAggregate block serialization
  +} else {
  +

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
> this a known issue?
> 
> 
> 
> Also I just checked in a small change to LabelRecord. I assume I should be
> checking these changes into HEAD?
> 

Stabilizing bug fixes should go into the branch.  Destabilizing feature
additions should go in 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]
> 

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

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 not working & Checkins
>
>
> >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 HEAD?
>
> Bugfixes should go into both REL_2_BRANCH and HEAD. Major functinality
> enhancements go only into HEAD.
>
>
> On Wed, 2003-09-17 at 11:50, Height, Jason 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
> > 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]
> >
> >
>
>
> -
> 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]

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 HEAD?

Bugfixes should go into both REL_2_BRANCH and HEAD. Major functinality
enhancements go only into HEAD. 


On Wed, 2003-09-17 at 11:50, Height, Jason 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
> 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]
> 
> 


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

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/record/LabelRecord.java
  
  Index: LabelRecord.java
  ===
  RCS file: 
/home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/record/LabelRecord.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- LabelRecord.java  19 Aug 2003 14:07:40 -  1.7
  +++ LabelRecord.java  17 Sep 2003 05:34:29 -  1.8
  @@ -150,15 +150,17 @@
   field_3_xf_index = LittleEndian.getShort(data, 4 + offset);
   field_4_string_len   = LittleEndian.getShort(data, 6 + offset);
   field_5_unicode_flag = data[ 8 + offset ];
  -if (isUnCompressedUnicode())
  -{
  -field_6_value = StringUtil.getFromUnicodeBE(data, 8 + offset,
  -  field_4_string_len);
  -}
  -else
  -{
  -field_6_value = StringUtil.getFromCompressedUnicode(data, 9 + offset, 
getStringLength());
  -}
  +if (field_4_string_len > 0) {
  +  if (isUnCompressedUnicode())
  +  {
  +  field_6_value = StringUtil.getFromUnicodeBE(data, 9 + offset,
  +field_4_string_len);
  +  }
  +  else
  +  {
  +  field_6_value = StringUtil.getFromCompressedUnicode(data, 9 + offset, 
getStringLength());
  +  }
  +} else field_6_value = null;
   }
   
   /* READ ONLY ACCESS... THIS IS FOR COMPATIBILITY ONLY...USE LABELSST!
  @@ -236,6 +238,27 @@
   {
   return this.sid;
   }
  +
  +public String toString()
  +{
  +StringBuffer buffer = new StringBuffer();
  +buffer.append("[LABEL]\n");
  +buffer.append(".row= ")
  +.append(Integer.toHexString(getRow())).append("\n");
  +buffer.append(".column = ")
  +.append(Integer.toHexString(getColumn())).append("\n");
  +buffer.append(".xfindex= ")
  +.append(Integer.toHexString(getXFIndex())).append("\n");
  +buffer.append(".string_len   = ")
  +.append(Integer.toHexString(field_4_string_len)).append("\n");
  +buffer.append(".unicode_flag   = ")
  +.append(Integer.toHexString(field_5_unicode_flag)).append("\n");
  +buffer.append(".value   = ")
  +.append(getValue()).append("\n");
  +buffer.append("[/LABEL]\n");
  +return buffer.toString();
  +}
  +
   
   public boolean isBefore(CellValueRecordInterface i)
   {
  
  
  

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

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

Re: LabelRecord Uncompressed

RE: LabelRecord Uncompressed

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

Re: LabelRecord Uncompressed

Re: LabelRecord Uncompressed

LabelRecord Uncompressed

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

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

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

Re: Test build target not working & Checkins

RE: Test build target not working & Checkins

Re: Test build target not working & Checkins

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

14 matches

Site Navigation

Mail list logo

Footer information