Download it now!
Bug 38023 - name range reference incorrect in 3.4 version
Summary: name range reference incorrect in 3.4 version
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.4.0 release
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Markus Mohrhard
URL:
Whiteboard: target:3.5
Keywords:
: 37818 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-06-07 01:19 UTC by Herve
Modified: 2012-05-12 19:17 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
file contening named range error (42.45 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-06-07 01:23 UTC, Herve
Details
the parameter file for test file (43.97 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-06-07 01:23 UTC, Herve
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Herve 2011-06-07 01:19:36 UTC
when inserted a sheet from file the named range are imported to.
But after save and closed, when open again the named range are wrong in version 3.4 but ok in version 3.3
the attached files have been created with 3.4 version and are correct at creation.
when opening the test file (3.4) name range are wrong (see explication sheet for what is wrong ) 
If you open it in v3.3 all named range are correct
Comment 1 Herve 2011-06-07 01:23:11 UTC
Created attachment 47647 [details]
file contening named range error
Comment 2 Herve 2011-06-07 01:23:59 UTC
Created attachment 47648 [details]
the parameter file for test file
Comment 3 Markus Mohrhard 2011-06-07 01:44:10 UTC
I take it. It seems we have some problems with the import of named ranges at the moment.
Comment 4 Markus Mohrhard 2011-06-07 09:39:58 UTC
*** Bug 37818 has been marked as a duplicate of this bug. ***
Comment 5 Kohei Yoshida 2011-06-07 22:17:04 UTC
BTW, I don't see the problem with the test file, using the latest master build.

I see in Parametre.E38

=SMIC *(TauxJournee/8)

and the result is 5.591, and in Conges.C16

=DATE(AnneeDepart,MoisDepart,JourDepart)

and the result is January 8, 2010 (the actual date format may be different under different locale).

When you say they are wrong, what do you actually see?
Comment 6 Herve 2011-06-08 08:35:07 UTC
bugzilla-daemon@freedesktop.org a écrit :
> https://bugs.freedesktop.org/show_bug.cgi?id=38023
>
> Kohei Yoshida<kyoshida@novell.com>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |kyoshida@novell.com
>
> --- Comment #5 from Kohei Yoshida<kyoshida@novell.com>  2011-06-07 22:17:04 PDT ---
> BTW, I don't see the problem with the test file, using the latest master build.
>
> I see in Parametre.E38
>
> =SMIC *(TauxJournee/8)
>    
When i open test file in 3.4rc2 the cell formula is =AnneeDepart *(#NOM ?/8)
> and the result is 5.591, and in Conges.C16
>
> =DATE(AnneeDepart,MoisDepart,JourDepart)
>    
Cell formula on open =DATE(#NOM ?;#NOM ?;#NOM ?)
> and the result is January 8, 2010 (the actual date format may be different
> under different locale).
>
> When you say they are wrong, what do you actually see?
>
>    
all named range reference to parameter file are wrong
Conges.F9-17 are normaly =DATE(AnneeReference;X;X)
they are =DATE(#NOM ?;X;X) X are the month and day

Conges.F24-26 must reference to named range AnneeReference they are 
=DATE(ANNEE(DIMANCHEDEPAQUES(ANNEE(#NOM 
?)+1));MOIS(DIMANCHEDEPAQUES(ANNEE(#NOM 
?)+1));JOUR(DIMANCHEDEPAQUES(ANNEE(#NOM ?)+1))+1)

Conges column N and O are all incorrect in formula a i see #NOM ?

Hope it will help

best regards

Herve
Comment 7 Rainer Bielefeld Retired 2011-06-10 02:57:57 UTC
RC2 is bit by bit identical with release version, so separate items in the version picker are useless. Changes have been discussed with Michael Meeks.
Comment 8 Markus Mohrhard 2011-06-23 19:29:34 UTC
Can you test with 3.4.1RC2 or RC3 as soon as they are released. We fixed some problems around the import of range names so this problem might be gone now.
Comment 9 Nikos 2011-06-25 03:39:38 UTC
(In reply to comment #8)
> Can you test with 3.4.1RC2 or RC3 as soon as they are released. We fixed some
> problems around the import of range names so this problem might be gone now.

The problem seems to persist on 3.4.1RC1.
Comment 10 Nikos 2011-07-18 02:34:39 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > Can you test with 3.4.1RC2 or RC3 as soon as they are released. We fixed some
> > problems around the import of range names so this problem might be gone now.
> 
> The problem seems to persist on 3.4.1RC1.

I tested this on 3.4.2RC1 and it does not work (returns Name on E38 and on C16). Moreover, the named ranges on my own spreadsheets created in earlier LibO and OO.org versions do not work in 3.4.2RC1 (and in no earlier 3.4 version I tried). This is a show stopper for me. So I really hope you can get it fixed. BTW tested this on Win7 (I use the 3.3 on OpenSuse)
Comment 11 Nikos 2011-07-18 02:46:28 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > Can you test with 3.4.1RC2 or RC3 as soon as they are released. We fixed some
> > > problems around the import of range names so this problem might be gone now.
> > 
> > The problem seems to persist on 3.4.1RC1.
> 
> I tested this on 3.4.2RC1 and it does not work (returns Name on E38 and on
> C16). Moreover, the named ranges on my own spreadsheets created in earlier LibO
> and OO.org versions do not work in 3.4.2RC1 (and in no earlier 3.4 version I
> tried). This is a show stopper for me. So I really hope you can get it fixed.
> BTW tested this on Win7 (I use the 3.3 on OpenSuse)

The problem with my own documents seems to be related to data ranges. Even though, data ranges created in prior versions (by Data--> define range)show up in the navigator as Database ranges, when they are used in formulas (e.g. Vlookup) they return #Name?.
Comment 12 Markus Mohrhard 2011-07-18 05:10:07 UTC
(In reply to comment #11)
> The problem with my own documents seems to be related to data ranges. Even
> though, data ranges created in prior versions (by Data--> define range)show up
> in the navigator as Database ranges, when they are used in formulas (e.g.
> Vlookup) they return #Name?.

This sounds like a different bug. Data->Define Range crates Database ranges whereas Insert->Names->Define creates range names. They have different import paths and are handled differntly in the core.

Can you create a bug for this with a test document?

Regarding, this bug: I still can't reproduce this with a 3-4 build and it seems Kohei can't reproduce it either
Comment 13 Nikos 2011-07-18 06:36:36 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > The problem with my own documents seems to be related to data ranges. Even
> > though, data ranges created in prior versions (by Data--> define range)show up
> > in the navigator as Database ranges, when they are used in formulas (e.g.
> > Vlookup) they return #Name?.
> 
> This sounds like a different bug. Data->Define Range crates Database ranges
> whereas Insert->Names->Define creates range names. They have different import
> paths and are handled differntly in the core.
> 
> Can you create a bug for this with a test document?
> 
> Regarding, this bug: I still can't reproduce this with a 3-4 build and it seems
> Kohei can't reproduce it either

Regarding the first part. I submitted Bug 39333.

Regarding this one: I have not tested under Linux yet (and I probably wont before the release of the stable version since I don't like messing this machine up and I need a working LibO installation for my work), but under Win7 (3.4.2 OOO340m1 (Build:201)) I get #Name? in the test file supplied by Herve.
Comment 14 Markus Mohrhard 2011-08-08 09:53:32 UTC
seems that I'm able to reproduce it now with a new master build
Comment 15 Markus Mohrhard 2011-08-08 16:45:41 UTC
So after some debugging I suspect in is another of our problems with named ranges when we copy sheets. We don't copy the formula string but our compiled formula token array which only contains an internal index to the range name.

So I think this bug is related to bug 39850 and bug 39820. I don't plan to do anything in this direction for the stable 3-4 branch because it needs some restructure of the copy/paste code and the handling of range names in formulas. My best idea at the moment is to copy the formula string and start a recompilation after pasting the formula cell.

Then there is an independent problem. The file already contains some errors: <style:map style:condition="is-true-formula(VLOOKUP([.M126];#nom ?;3;0)="")" style:apply-style-name="VacanceJour" style:base-cell-address="Salarie.M126"/>
Comment 16 Markus Mohrhard 2012-05-12 19:17:15 UTC
Fixed in 3.5