Created attachment 59211 [details]
example showing the problem

This regression was introduced with CWS mooxlsc which introduces a changed
handling of external references in calc.
Those parts in calc that provide the data for the charts need to be adapted also
to the new system.
@kohei, Eike told me that you have done most of that work, so you are the best
to fix this problem also. Please have a look! Thanks, Ingrid.

Whoa!  fixing one thing and breaking another. ;-)

I wonder what's at work here.  I'll take a look.

Ah, the ODF stores range address as 

'file:///file/path'#Sheet1.A1:'file:///file/path'#Sheet1.A4 (A)

instead of

'file:///file/path'#Sheet1.A1:Sheet1.A4 (B)

So, it's most likely because the parser is expecting the (B) form while the (A)
form is provided by the ODF importer.

I wonder if this is the correct ODF syntax (to always provide the start and end
cell addresses for range separated by ':' i.e. form A) instead of using form B.

I'm making similar changes in koheiformula02.  Perhaps I can take care of this
issue in that cws.

Heavy stuff.. problem is that data sequences (and other references used by
Chart) are created using a ScRangeList but ScRange/ScAddress have no information
about external references. This worked fine so far because in
'extsource'#Sheet1.B3:D5 the entire 'extsource'#Sheet1 could be resolved
resulting in an internal hidden sheet number.

I guess (and this is just a quick idea so far) the easiest (quite hackish)
attempt would be to mask the nTab member of ScAddress such that values above xxx
(use a defined constant of MAXTABCOUNT+1024 or similar) point to the external
document cache's index number. This would of course need adapting
ScAddress::Parse() (be careful with its usage in the formula compiler to not
break external references!), ScAddress::Format() and their ScRange::* and
ScRangeList::* equivalents, plus ScRangeStringConverter::* and maybe other
places as well. Special care would have to be taken with all UpdateReference()
calls that these sheet numbers will not get updated under any circumstances when
adding/deleting/moving sheets. The methods feeding the actual data to Chart then
need to access the external document cache for such sheet numbers. Further
investigation may be needed for loading/saving documents, where Chart stores the
references as range strings. Also setting up ChartListeners will need some
special treatment, they need to get notified for refreshed links. And maybe
other things I didn't think of right now..

I'm almost done.  I ended up modifying just the code in chart2uno.(c|h)xx, to
use reference tokens instead of range lists to keep track of data source ranges.
 This way the external reference info is preserved.  This appears to work pretty
well on my tests.

Unfortunately this required lots of changes in chart2uno.(c|h)xx, but the good
news is that the change is contained in those two files only.

I'm still going through the chart2uno code as a final check.  But it's safe to
say that the worst is over.

Oh, I almost forgot.  I still need to work on getting the external link update
to work properly.

ScChart2EmptyDataSequence doesn't appear to be used anymore.  We can probably
remove this class entirely.

>it's safe to say that the worst is over.

Well, I lied. :-(

Handling link updates properly with chart objects also needs non-trivial amount
of code change.  I'm still looking into this, and at this point I don't know how
long it's going to take to get it done.

Ok, I *hope* I got everything covered.  The issue was larger than I expected, so
it's hard to see if I've covered all corners.  But since I can't think of any
other outstanding issues, I'll mark this FIXED.

re-assigning to oc for qa.

When closing a document, pExternalRefMgr is deleted before
pChartListenerCollection, but ExternalRefListener dtor calls
ScExternalRefManager::removeLinkListener.

In Chart2Positioner::createPositionMap you cast from ScSingleRefToken* to
ScAddress*, causing heap corruption if a single column with headers was detected.

Also, you're causing lots of assertions in a non-product version by calling
GetIndex/GetString for normal reference tokens.

Ok.  All three issues you have raised should be fixed now.  Please re-check.

Created attachment 60048 [details]
XLS-Bugdoc

reopened because external references in ExcelChart still doesn't work (new
bugdoc attached)

reassigned for fixing

Yes, I can see how the xls import filter fails to import external refs, since
XclImpChSourceLink expects an internal range list type which will no longer work
with the new external ref implementation.

I'll work on fixing this soon.

Now it is fixed in the xls import and export filters.

I had a problem with the xls document that Calc re-saved from the attached bug
doc.  Excel doesn't draw the chart with external references when loaded.

But I checked that with a milestone prior to the integration of mooxlsc and it
still had the same problem.  So I assume that's entirely a different matter, not
a regression caused by my change.

back to qa.

verified in internal build cws_koheiformula02.
For the remaining problem with the xls- export there will be a follow-up issue

This issue is closed automatically. It should be fixed in a version with is
available for longer than half a year (OOo 3.1). If you think this issue isn't
fixed in the current version (OOo 3.2) please reopen it. But then please pay
attention about the field 'target milestone'.
The closure was approved by the Release Status Meeting at 22nd of February 2010
and it is based on the issue handling guideline for fixed/verified issues :
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues