Please try using a CVS build.  I think this has been fixed.  The
net.sourceforge.x packages indicate this is 1.0.2 or an early development build
from the old sourceforge site.

Same old exception :(

Exception occurred during event dispatching:
java.lang.IllegalArgumentException: Cannot store a duplicate value 
("???????????????") in this Map
        at org.apache.poi.util.BinaryTree.insertValue(BinaryTree.java:1395)
        at org.apache.poi.util.BinaryTree.put(BinaryTree.java:1580)
        at org.apache.poi.hssf.record.SSTRecord.processString
(SSTRecord.java:1033)
        at org.apache.poi.hssf.record.SSTRecord.manufactureStrings
(SSTRecord.java:960)
        at org.apache.poi.hssf.record.SSTRecord.processContinueRecord
(SSTRecord.java:660)
        at org.apache.poi.hssf.record.RecordFactory.createRecords
(RecordFactory.java:176)
        at org.apache.poi.hssf.usermodel.HSSFWorkbook.<init>
(HSSFWorkbook.java:140)
        at TestFrame.openFile(TestFrame.java:64)

Are you able to post the XLS file that causes this problem?  Does it contain 
rich text cells?

perhaps for the moment we should kludge SST Record to notice duplicates and just
return the original in the event of a Rich Text cell.  I have to say this is one
feature I may consider the absence of irritating enough to sneak into 1.5.1.

*** Bug 9448 has been marked as a duplicate of this bug. ***

Curiously enough although this appears to be a somewhat different problem than
my bug (9448), I discovered that copying a worksheet with lots of long and
similar strings in it (and invoking Excel's lovely cut-off-at-255-character
logic - how quaint), I get one which will cause the duplicate value problem.

As for my bug, the sheet probably has all manner of fields in it, it's the
result of several years of accumulated data from a variety of sources, and while
it contains essentially just lots of text, it's been cut and pasted in from all
sorts of things so who knows what the formatting is.

I've begun to suspect that there's more at work than just a flawed continuation
design though, because some instrumented code running against a 700K or so
spreadsheet came up with this:

manufactureStrings(index=18,size=8224)
manufactureStrings: Loop entry, remaining=8206
HMM: char_count = 39
setupStringParameters()
setupStringParameters: Initial total = 81
Processing string...
manufactureStrings: Loop entry, remaining=8125
HMM: char_count = 101
setupStringParameters()
setupStringParameters: Initial total = 104
setupStringParameters: Formatted run, total now = 103530
setupStringParameters: Extended, total now = 1946285934
HMM: total len bytes 1946285934 remaining is 8125 exp 1946277809 count 101

Where the 'extended' data is actually several orders of magnitude larger than
the file that supposedly contains it.. so Somewhere either the record is getting
corrupted or mis-parsed, I dont know which 8-(.

While I can't make my test data publically available, I will send something to
Glen which can hopefully assist in hunting down the glitch(es).

Oh wow, maybe this one actually uses the ExtSSTRecord!  We never could find a
sheet that actually used/needed this.  Question: This is all western version of
Excel right?  (meaning a western european/US version of excel and/or western
european/US language)

Yup. US English everywhere (Though there are a goodly number of european accents
in there for good measure (in fact, whether you like it or not, excel seems to
take perverse pleasure in accenting Creme even when you dont want it to).

Good that should work.  Can you do a org.apache.poi.hssf.dev.BiffViewer on it
and see if the ExtSSTRecord looks like it actually has something that looks
meaningful in it?  It sounds like this stuff may be just the kind of jackpot we
need to track that record down!  (I'm still guessing, this may prove to just be
more Rich Text issues)

Oh oh... looks like I didn't know what I would be getting myself in for 
here!  :-)

Fixed in 1.5 branch and in trunk.  Should now correctly read rich text and
extended text with no problems.  The offical release will be 1.5.1.