Created attachment 83382 [details]
Here I show how the suggested feature would look like (two alternatives)
Imagine the following very basic situation:
In the cell B15 I have =SUM(B3:B12)
But, now I want to include a few cells more in (eg to extend upwards until B1) so to have the final selected range (B1:B12). So I double-click B15 and I see the selection box showing me the currently selected range.
The selection box shows the "handle" (to resize the selection) at the bottom right corner. So the only way to include the above cells in this case is:
1. locate the mouse inside the selection box so it turns into a "hand"
2. drag and drop to move the whole range two rows upwards
3. put the mouse on the bottom-right corner
4. click and drag to resize two rows downwards
This is a lot of steps for such a simple task. It can be greatly improved and perhaps even made more intuitive and user friendly.
What I suggest is:
1. (1st option - Ideal) that the selection box can be resized using any of its boundaries (not only from corners). For example when you put the mouse at any boundary, the mouse pointer could turn into a double arrow indicating that you can resize in that axis (something like the “Ideal” in the attached file). But maybe this is too fancy.. it would still be perfect without the pointer change.
2. (2nd best - if the above is too ambitious) the selection box can be resized using ANY of its 4 corners (it would look something like the “2nd_best” in the attached file). In this case the mouse pointer keeps its current behavior (ie turning into a hair cross when over the “handles” of the selection box.)
Considering that to move the selection box the mouse pointer needs to be completely inside the selection box, there is no interference or conflicts between "resizing" and "moving", therefore the borders of the box could be fully used to resize and the "hand" will only move it.
The above case involves the range selected by a formula. But EXACTLY the same as I explained can be applied to a regular selection of cells (ie a normal selection to format cells, without involving any formula.)
(This is my personal interpretation, so please forgive my misuse or ignorance of technical terms).
The behavior of the current resize method in Calc is inherited from Excel. In Excel it makes sense to have only a specific point in the selection box because the boundary is ALSO used to MOVE the selection box. Therefore the move and resize are in some sense “in conflict”.
But in Calc, the move is completely different: you don use the boundaries of the selection box. Therefore why not using the whole selection box for resize??? This would be a great feature and would make life easier for everyone in the day-to-day use of LibreOffice spreadsheets.
I included a PDF with hypothetical screen captures. Let me know what you think!! I would love to see this implemented in Calc!
Thanks for your great contributions, LO Calc ROCKS!!
I think this could be a nice improvement...
Created attachment 83590 [details]
Ideal situation: each of the 4 borders of the selection box can be used to resize it. When the mouse is over the boundary, it turns into a two-sided arrow indicating that if you click and drag you will move the boundary of the selection.
Created attachment 83591 [details]
2nd best alternative: the four corners of the selection box are "resizing handles"
Actually now I'm thinking that the 2nd best is maybe the best option, because by handling from one corner you can change the selection in both directions in the same action. Eg if you want to include more columns AND more rows, you can do it by handling the size from the corner...
But enough of talking alone here :)
TomaÅ¾ Vajngerl committed a patch related to this issue.
It has been pushed to "master":
fdo#67592 Resize selection box from all 4 corners
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
I implemented the 2nd option - you can check this out in the daily build.
I can't see it implemented, exactly which version do I have to test? This is the one I tested:
Build ID: aa9bef8271ed50a397c959ed53c91ee44b3dcb1
TinderBox: Win-x86@6-debug, Branch:libreoffice-4-1, Time: 2013-09-03_11:55:14
This will be in LO 4.2 as it is an enhancement so you need a daily build to test this .
*** Bug 69133 has been marked as a duplicate of this bug. ***
I have tried two times already with different daily builds and it crashes when I resize the selection.
What I do is
- type eg 5 numbers in a column
- place a formula in any cell with SUM(range)
- resize the selection box
- press ENTER
- Calc crashes.
I'm using Version: 220.127.116.11.alpha0+
Build ID: a8865e5df62b5f33aa769d459b9823eb5b110d4b
TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-09-03_14:36:22
I don't think this is related to this feature - it may be a recent bug. I will take a look what is causing the problems.
I think I found the problem and fixed it in master. It should work as expected in the next available daily build.
sorry to say it still doesn't work.. keeps crashing.
There was no new successful windows daily build for quite some time.. I am not sure my fix is included in any of the available ones. Let's wait for the next successful daily build.
The functionality is now in daily builds.
(In reply to comment #15)
> The functionality is now in daily builds.
I tested it on this buld (under Ubuntu):
Build ID: b1caf176a44b6979d2e0ea47f495a3dacf86e197
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2013-10-12_06:04:49
The corners are moving in spite of the fact the sum is not calculating. By the way it seems to be working.
GNU/Linux Mint 15 and LO 4.1 beta1.
Build ID: f4ca7b35f580827ad2c69ea6d29f7c9b48ebbac7
I don't see any changes.
I don't see it implemented...
LO Version: 18.104.22.168
Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a
J22Gim: For the second time - you need LO 4.2 if you want to test this. This will never be in LO 4.1 as it is a enhancement and not a bug.
Tomaz Vajngerl: sorry, and yes!! it works!! thanks!!
Build ID: 1de7d0aba4142424fe0082071a4ac64ec377cea0
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2013-11-27_00:02:42
*** Bug 75073 has been marked as a duplicate of this bug. ***