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 388531 - paste selection from excel 2002 > invalid pasting: 'is beyond sheet boundaries'
paste selection from excel 2002 > invalid pasting: 'is beyond sheet boundaries'
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: import/export MS Excel (tm)
1.7.x
Other All
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2006-12-22 08:15 UTC by A
Modified: 2009-10-16 17:39 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
contains files to replicate bug and a screenshot of the error (106.65 KB, application/zip)
2006-12-22 08:16 UTC, A 		Details

Description A 2006-12-22 08:15:10 UTC 
Please describe the problem:
paste stuff from excel into gnumeric, get error

Steps to reproduce:
i will attach the files to replicate this...
1)open trimmed - 8-10-2006 data.xls and boilerplate.gnueric 
2)in the excel file, highlight C7:S28
3)cut
4)click on cell E7 of the boilerplate.gnumeric
5)paste
6)read error message--> Invalid Pasting into E7: 'is beyond sheet boundaries' 

Actual results:
error pops up, nothing is pasted

Expected results:
successfull pasting

Does this happen every time?
with these particular files, yes. I'll post more here if I come across more info pertaing to this problem

Other information:
Comment 1 A 2006-12-22 08:16:39 UTC 
Created attachment 78775 [details]
contains files to replicate bug and a screenshot of the error
Comment 2 Jon Kåre Hellan 2007-09-08 15:31:04 UTC 
With Gnumeric 1.7.12 and Excel 2000, the range is pasted, but the boundaries are wrong.

The selected range ends up in c13:s34. Rows 7:34 end up selected, with all
contents ouside c13:s34 blanked out.
Comment 3 Andreas J. Guelzow 2009-10-15 18:20:38 UTC 
This really seems to be closely related to bug #381732, and may inf act just be a different instance of the same bug. We clearly are not correctly interpreting the range information.
Comment 4 Morten Welinder 2009-10-16 17:39:51 UTC 
It is the same.  Fixed.