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
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
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
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
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]
+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
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
+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
+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
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 jakarta-poi-root
patch -p0 mypatchfile.diff
This assumes that the diff was
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
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
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
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
snip
+at all. To start drawing you need to call
codecreatePatriarch/code
+on the codeHSSFSheet/code class. This has
the
+effect erasing any other shape information stored
+in that sheet. By
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
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
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
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
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
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
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
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
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
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
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:
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
: 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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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
. 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
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]]
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
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
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
-
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
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
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
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
51 matches
Mail list logo
