After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 562363 - constructed range is not eval correctly after sheet referenced is deleted
constructed range is not eval correctly after sheet referenced is deleted
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: Analytics
git master
Other All
: Normal normal
: ---
Assigned To: Morten Welinder
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2008-11-26 18:35 UTC by Henry Law
Modified: 2008-11-27 01:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
also handle GNM_EXPR_OP_RANGE_CTOR's subtree which is of type cellref/constant (1.30 KB, patch)
2008-11-26 18:37 UTC, Henry Law
none Details | Review

Description Henry Law 2008-11-26 18:35:23 UTC
Please describe the problem:
When a constructed range where part of it is cellref like 'Sheet2!A1:Sheet2!A3' is used as argument of functions(i.e. sum) and the reference sheet('Sheet2' here) is deleted, the result of the functions keep unchanged. 

Steps to reproduce:
1. create a new workbook
2. enter expression '=sum(Sheet2!A1:Sheet2!A3)' in Sheet1's A1
3. enter 1, 2, 3 in Sheet2's A1 - A3, now Sheet1's A1 show '6'
4. remove 'Sheet2'


Actual results:
Sheet1's A1 still show 6

Expected results:
Sheet1's A1 should be either '=sum(#REF!:#REF!)' or simply '#REF!'

Does this happen every time?
yes

Other information:
Seems problem due to constructed range is GnmExpr of type GNM_EXPR_OP_RANGE_CTOR which did not handle any the dependent of it subtree inside link_expr_dep() and unlink_expr_dep() even the subtree is a simple cellref or constant(which turn out not handled at run time).
Comment 1 Henry Law 2008-11-26 18:37:46 UTC
Created attachment 123479 [details] [review]
also handle GNM_EXPR_OP_RANGE_CTOR's subtree which is of type cellref/constant
Comment 2 Morten Welinder 2008-11-26 18:48:00 UTC
I'll have a look later.  Note, that GNM_EXPR_GET_OPER does not return
a bitfield, so the "&" thing will not work.  I'll deal with it.
Comment 3 Morten Welinder 2008-11-27 01:02:18 UTC
We need to treat those operators as any other binary operator and get
them linked in as dependencies.  For simple cases, it doesn't matter for
evaluation -- the generated dynamic dependency is ok for that -- but
for anything that needs to change the formula containing the ctor, we
need it.  I.e., we need it for sheet remove, column insert, etc.

In the case where an operand is not a simple cell reference we even need
it for evaluation.  indirect(a42):indirect(a43) really does need to
depend on a32 and a43!


This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.