Description: Filling of merged cells should handle more accuracy Steps to Reproduce: 1. Merge A1:B2 cells 2. Enter any number in merged cells, like 23 3. Press a bold dot in bottom right corner of the merged cells and drag it down to row 5. Drop mouse button 4. Look at the result (and on screenshot in attach too) User souldn't have an opportunity to get only part of merged cells in end >_< Actual Results: We have only part of merged cells in end of filling process Expected Results: We have always full merged cells in end of filling process Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: fca525d570f4fada3db1a9bbee2e88a5a02839d9 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL
Created attachment 166266 [details] Screenshot with a problem
Attila, I found one problem after your great patches. Please look at it for QA - it isn't a regression, it's more an implementation error or even an enhancement
Reproduced in Version: 7.1.0.0.alpha0+ Build ID: a9976a958b2857e308c6598532151878615bfd9f CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Roman Kuznetsov: Thank you for the found bug. I think i will try to make the fill handle jump not only 1 cell at once, but as many as big the source area (that is selected before the fill). Excel handle it like this. I know some problems about autofilling merged cells, that i plan to fix, when i will have time... -Simple rectangle like selection can result in a non-rectangle like selection, like this: +-+-+-+ |A|B|C| +-+B+-+ |B| +-+ Filling with this selection result similar glitch as reported in this ticket. I think it can be fixed by extending the selection to a real rectangle (as Excel does) -Destination area [where to copy to] can be bad, that can cause similar glitches... Maybe an error message should pop up instead of the fill, if the filling would cut an already existing big merged cell into smaller ones... maybe the only alloved merge changes should be when 1x1 cells are merged into 1 bigger... Or warn / ask the user what to do, etc-etc.. -The preview popup [during autofill] should be updated to calculate with merged cell too -there are some different special format type that need some special filling algorithm.. like to continue 'monday', 'tuesday' ... -non-auto fills, like fill down (CTRL-D) works a bit differently, sure there are / will be some bugs related to that.. like the fill's source area must be discovered
Dear Attila Szűcs, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.
Repro Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community Build ID: ff2ba77f22b2e96f96f5537aec1705956b47583d CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: CL Version: 7.3.8.0.0+ (x64) / LibreOffice Community Build ID: e1ad83ddb2f39419fb5d7c69eba51e2b9f49c788 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: CL Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: c94961c6869c34b3874d21cfaa5ec1488609acfe CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: CL Version: 7.5.0.1.0+ (X86_64) / LibreOffice Community Build ID: ced8585bcb92aa58ca3e24197ff38fb82cc8a703 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: CL threaded Version: 7.6.0.0.beta1+ (X86_64) / LibreOffice Community Build ID: 1b5cee822e0bc15ddbdfc86926678ca35ab3e082 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: CL threaded