Issue 7072 - column widths shown wrong when altering with mouse & altering glitchy [also for rows,objects, heights&sizes]
Summary: column widths shown wrong when altering with mouse & altering glitchy [also f...
Status: CONFIRMED
Alias: None
Product: Calc
Classification: Application
Component: ui (show other issues)
Version: OOo 1.0.0
Hardware: All All
: P4 Trivial with 1 vote (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 9162 (view as issue list)
Depends on:
Blocks:
 
Reported: 2002-08-17 19:57 UTC by lars
Modified: 2017-05-20 11:13 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description lars 2002-08-17 19:57:02 UTC
if you hover the mouse pointer near a column border the mouse pointer changes 
to an  -||-  icon showing that some borders can be moved.

If you left-click then, you could actually start to move the border, but "the" 
column width pops-up before. That width however is not the width of the column 
but the width if the column was ending where the mouse pointer is which is more 
of course because of the larger hot area for the mouse pointer.

Now which is more important: if you now move the holded mouse pointer within 
the original hot area to a "new length", the border line is shown moving and 
the new length is displayed, but if stop holding the mouse button, the column 
width hasn't changed.

This issue actually applies to more than just the columns and is very annoying.

Fix it, please;  thanks, Lars
Comment 1 lars 2002-08-19 23:11:15 UTC
How it should be:


The hot area size remains;

when clicking the left mouse button in that area, the correct, 
current width of the column appears.

when mowing the mouse then, the column border is also moved so that 
there is an "offset" between mouse pointer and column border;


this means the column border is only moved that many number of pixels 
from its original position as the mouse pointer is moved from the 
position where it has been clicked!
Comment 2 andreschnabel 2002-11-11 19:10:16 UTC
*** Issue 9162 has been marked as a duplicate of this issue. ***
Comment 3 frank 2002-11-28 16:13:54 UTC
Hi Niklas,

one for you.

Frank
Comment 4 niklas.nebel 2002-11-28 17:56:09 UTC
It works as intended: The column is resized to the current mouse
position, not relative to the position where dragging was started. The
resizing is executed only if the mouse was moved more than 2 pixels
away from the starting position, but you can move the mouse out and
back into that area to resize by a smaller amount.
Comment 5 lars 2002-11-28 19:31:30 UTC
read the 2 original descriptions again:

there the problem (+"bug" !) is described and a "sense-making" 
solution is suggested
Comment 6 lars 2002-12-06 17:51:23 UTC
or rather than use the pixel position of the mouse and translate it 
into a size, use the mouse movement to change the size in 0.01 cm 
steps (+"acceleration" and so on perhaps) and then translate that 
into a new pixel position of the column border.


The problem is:

1. the column border is shown moving,  _although it hasn't_

2. a WRONG size is displayed


this is valid for many objects like bitmaps etc. !!!



if you want to keep your behaviour (why?) make it clear to the user 
what is happening, eg don't show the border move while not moved 2 
pixels and show the size first, when the the 2 pixels have been 
reached, so that the displayed size at least matches the new size.
Comment 7 niklas.nebel 2002-12-16 17:50:39 UTC
I think directly using the mouse position is the right thing in most
places (also for rulers, resizing drawing objects etc).
Falko, do you have any opinion on this?
Comment 8 falko.tesch 2003-10-08 13:05:28 UTC
I agree with Niklas. 
Nevertheless: We should "move" the selected line when clickinhg on it
and showing the column widths' value.
We should rather just leave the line alone (not thicken it).  
Re-targeted and re-prioritised.
Comment 9 ace_dent 2008-05-16 02:39:53 UTC
OpenOffice.org Issue Tracker - Feedback Request.

The Issue you raised has the status 'New' pending further action, but has not
been updated within the last 4 years. Please consider re-testing with one of the
latest versions of OOo, as the problem(s) may have already been addressed.
Either use the recent stable version: http://download.openoffice.org/index.html
or consider trying the new OOo 3 BETA (still in testing):
http://download.openoffice.org/3.0beta/
 
Please report back the outcome so this Issue may be Closed or Progressed as
necessary - otherwise it may be Resolved as Invalid in the future. You may also
wish to search for (and note) any duplicates of this Issue that may have
advanced further by checking the Issue Tracker:
http://www.openoffice.org/issues/query.cgi
 
Many thanks,
Andrew
 
Cleaning-up and Closing old Issues as part of:
~ The Grand Bug Squash, pre v3 ~
http://marketing.openoffice.org/3.0/announcementbeta.html
Comment 10 lars 2008-05-17 17:52:18 UTC
issue still valid as per OOo 3.0 Beta m2.

and I don't know whether you have really understood the important problem:


let's say a width is 2,30 cm.

width change is possible when mouse pointer is at 2,36 cm.

if I move to 2,33 cm, the display suggests this was succesful.

the size remains 2,30 cm though! can be considered a bug, thus reprioritizing!



Lars
Comment 11 Marcus 2017-05-20 11:13:16 UTC
Reset assigne to the default "issues@openoffice.apache.org".