Cell borders handling very unfortunately VERY different between ^c and ^x!

Questions and answers about FreeOffice PlanMaker 2018 for Windows
Post Reply
Posts: 5
Joined: Fri Jun 26, 2020 2:31 pm

Cell borders handling very unfortunately VERY different between ^c and ^x!

Post by sft10 » Wed Jul 01, 2020 11:39 am

I have similar problems with Excel, but I had hoped PM did it better; it does not but perhaps you could implement better handling of cell borders, perhaps in the paid version only?

The short version: Shifting (^x, ^v) cell ranges brakes border formatting of the (now-emptied but not deleted original cells, whilst only copying (^c, ^v) does not, and this inconsistency then makes necessary lots of additional work, i.e. creating a convoluted workflow to end up to the desired result for shifting cell ranges/blocks /rows (certainly similar to columns). As it is now, you EITHER can shuffle around rows, etc., OR you have border formatting; both at the same time is in fact impossible. In detail:

When I insert new rows in a PM calc sheet, the "vicinity" borders are copied to the new cells, which is very good, e.g. I have 3 new rows, in a table where some cells have vertical borders, others not: everything's fine for the new cells, no manual fuss needed. The problem here: If even ^x worked as expected, I would NOT need to create the new rows for the target position in the first place.

Similar when I "delete" cells (by "Delete" key, i.e. in fact just "empty", not really delete the cells, NOT by "Spreadsheet - Delete whole rows", I refer here to the cell CONTENT deletion, NOT to CELL deletion then): The (now empty) cells' borders remain intact: very good.

The problems (as said, Excel isn't any better) arise when I CUT-and-INSERT cell ranges (rows here, is probably similar with columns): LOTS of manual cell border handling is needed afterwards, i.e. the "emptied" cells LOSE their border formatting, and those "emptied" rows become now unusable for "new" (or shifted) data: "shuffling around" rows is NOT possible since it loses all border formatting.

I discovered a way around this, but I'm not happy with it:

- first, I create the necessary new target rows (in order to avoid overwriting existing cells): not even this step should be necessary, see below

- then, instead of doing a ^x, I must do a ^c (copying instead of cutting)

- I then do the ^v on the target position: Formatting is preserved there; I didn't check but I suppose just the cell contents are inserted (i.e. copied), the cell borders (which have been created correctly on the new rows' creation) stay intact

- I then have to select the original cell range (which I just have copied to another position) or simpler, rows, again, then either really delete the rows or delete their contents (depending on me needing these rows further on or not, but most of the time, I do NOT need them then any further, see below).

This way ONLY in PM, the the border formatting of the original (now emptied) rows is preserved, and it's the same in the original block, the same in the newly created (empty yet) rows, and the same in the "shifted" (in fact necessarily) copied cells/rows; "necessarily" since any cutting (^x) BREAKS the border formatting in the original position.

In order to shift rows (etc.), I constantly need to create new rows (on the new position), and really-delete (not by "Delete" key which would only delete the contents) rows now not needed anymore; also the risks of inadvertently deleting rows NOT to be deleted, are quite high.

Now for a smooth handling of this: Preservation of the (emptied) original position's cells' border formatting even after ^x is needed, not only for ^c.

This way, you could shuffle around rows this way: You would preserve some empty rows on the BOTTOM of the "body" of your spreadsheet (by "body" I mean between the very first ("title", "subtitle"...) rows and then the "finish" rows, containing the calculation formulas for the "body" in-between), as a "reserve".

Then you "make room" for the needed target rows (for ^v) by shifting (^x, ^v) "everything below", then you select the rows you want to be shifted, you do ^x, ^v for them, and you're done, in both directions, this just takes seconds, and creation of new rows is only necessary here and then, when you foresee creating some really new rows:

You need rows 22 to 26 between rows 12 and 13, so you select rows 14 to 100, do ^x (NOT ^c!), select (now empty) cell A19, do ^v (now there's room with now empty rows 14 to 18), select rows 27 (ancient 22) to 31 (ancient 26), do ^x, select (empty) cell A14 again, do ^v, and you then either close the 5 now empty rows 27 to 31, or you leave them alone, provisionally, for further shuffling - in practice, it's not necessary to also shuffle the big body below, every time, but only if your "reserves higher up" don't count for the necessary number of empty rows, in case several empty rows between "mini blocks" combined.

This is smooth working, but totally destroys border formatting.

In order to preserve border formatting, you do, as explained above, with ^c instead of ^x, and since here, you don't create empty blocks on the original positions, but just copy your original data, you quickly create total chaos, afterwards NOT deleting ALL of the original data, or, worse, even data in lines above or below the original block.

(The only risk with shuffling by ^x instead being that on ^v, you will not have freed enough empty rows to contain the shuffled data, which is why I free some 2, 3 rows "too many", then adjust later on, here and there, and then again on "consolidation", i.e. when I prepare the whole for the table's "finish".)

There is NO logical reason for treating ^c and ^x so differently in this respect, there only COULD be a logical (and valid) reason to implement some option "apply original (border) formatting to shifted content instead of the current target formatting default" (but which should always be the default), (i.e. cells are always formatted in some way even with no current content, "waiting" for content), AND after taking away the content of cells (by ^x), their previous formatting should not be reset to "zero" (i.e. be just taken away):

Logically, and instead of preserving the original cell formatting (which in some cases might be quite "special"), the only other alternative would be that "emptied" cells (emptied by ^x; ironically, emptying them by "del" - but which you can NOT do before the ^c, hence the bunch of problems coming with that way of proceeding, see above - preserves the format, so there's another inconsistency here) would then reset to their "vicinity format", the "default format of the range", sort of, i.e. would just lose some very special format, e.g. coloring because of their formula taken away: just ^x-deletion of the content should NOT lose their "regular" formatting.

I suppose that lots of what I have described above, for border formatting, will also apply to other formatting attributes, but I didn't check those.

Again: Both "Del" and ^c (of course, for the latter) preserve original formatting, whilst ^x (where this would be also needed) does not, so ^x-^v is in fact not available, safe extreme manual correcting thereafter, where ^c-^v would be without problems re this aspect, but where it would cause all sorts of other problems, as described above (convoluted workflow, additional dangers of data loss/corruption).

Please consider. (Excel not doing it any better isn't a reason for "preserving" their faults and illogical idiosyncracies. And, just bug extermination making the exception here, I clearly think you're perfectly in your right to preserve any additional work to the paid version.)

SoftMaker Team
SoftMaker Team
Posts: 1415
Joined: Wed Mar 11, 2020 5:31 pm

Re: Cell borders handling very unfortunately VERY different between ^c and ^x!

Post by SuperTech » Sat Jul 04, 2020 12:11 pm

Thanks for your suggestion. I have forwarded the details to our product management...

Posts: 137
Joined: Wed May 22, 2019 11:56 pm

Re: Cell borders handling very unfortunately VERY different between ^c and ^x!

Post by Woody44 » Thu Jul 09, 2020 3:25 pm

I have always wondered why spreadsheet programs do that. The Calc spreadsheet in Libre Office does the same thing, as does Excel. And you are correct -- it's very annoying.

Post Reply

Return to “FreeOffice PlanMaker 2018 for Windows”