Created attachment 78145 [details] A simulation of the alleged bug using a small part of original spreadsheet. Part of a much larger spreadsheet is used to input competitors names in pairs alongside an appropriate pair number on a club score sheet. To save typeing, all club members names are stored in protected cells. When required, each member's name is copied from its protected cell and pasted into an un-protected cell in the same row as his pair number, his score, and his placing. His partners name is likewise pasted alongside. The list of members names and the un-protected entry cells are not part of the printable area of the score sheet. Within the printable area, a double column of cells contains formulae which simply concatenate; member's name + ampersand + partner's name. All works well when using just copy and paste are used. BUT if an un-suspecting user sees that several pairings have not changed since the previous use, but need to be moved up or down the columns, then he may attempt a cut and paste on the un-protected columns. This modifies the source addresses in the protected columns, and if the user is not the compiler of the spreadsheet, he will be unlikely to be able to sort out the mess. This seems similar to Bug ID 51757 (STATUS - CLOSED NOTABUG) but the possibility of protected cells being modified by a legitimate operation on an un-protected cell is surely unacceptable. I will attach a copy of a file which simulates the affected area of the original spreadsheet, filename BUGSHOW.
Hi AriF, I think to avoid your issue, you can address unprotected cells, with function like OFFSET(), INDEX() or even INDIRECT(). OFFSET() is a good option, you can reference from a protected cell to a protected and hidden column near the unprotected cells. To get the value in C4 you can use OFFSET(A4;0;2), if A is a hidden and/or protected column the user cannot cut on it, and cut C4 does not modify the formula. I think this is not bug, if you are not agree please REOPEN it. Maybe you want a new functionality, please open a new bug with the second option importance as "enhancement", change the title with a brief summary with your request, explaining in the comment what you want achieve.
----------------------------------------------------------------- Hi Mario, Thank you for your very helpful response on Bug 63649. The work around using OFFSET(), which works effectively enough, is no problem to insert into my application. Personally, I will still regard the original problem as a bug, but unless the rest of the world is of the same opinion, I see no point in a REOPEN. An enhancement that gave on-screen warning of the effect of a CUT-PASTE operation upon supposedly PROTECTED cells might be considered. Incidentally, I will be using the OFFSET function on data in the same columns. Referring to the on-screen Help pages, the Column variable is said to be "optional". However, using just OFFSET(Ref;Row) provokes a "missing variable" error. OFFSET(Ref;Row;0) or OFFSET(Ref;Row;) both work OK. Does this suggest an additional example line in the help text would be useful? Thanks again for your help. AriF