Description: In trying to recreate a calendar to my liking I first create a series of weeks each beginning with a different day. To do this, each column is entered as a separate object and moved as appropriate to make up a full week. However, whilst creating the columns was no real trouble when it came to moving the columns it caused quite a bit of trouble. Each time I select the text in a column, the left toolbar disappears and returns when I select the textbox again (to get the handles) to move it to the appropriate position. This frequently results in the wrong textbox being selected(!) and happens every time I select a textbox. I DID succeed in the end through sheer bloody-mindedness and determination - though it is very frustrating. I should add that this is my first foray into using Libre Office Draw but it just seems wrong! I'll try to upload some pics I've taken to illustrate the problem. Steps to Reproduce: 1.Create a column of text (in my case numbers) and click in a clear area of the screen 2.Select the textbox - the left toolbar disappears moving everything to the left 3.Select the textbox to get the handles and the toolbar returns moving everything to the right again Actual Results: The wrong textbox is frequently selected since the columns of numbers are fairly adjacent to each other Expected Results: The correct column of numbers should be selected and the left toolbar should remain in position whatever you are doing Reproducible: Always User Profile Reset: Yes Additional Info: Version 24.4.3.2 (x86_64) Build: 48a6bac97e268aeb4c3483fc... Environment: CPU threads 12; OS: Windows 10 X86_64 (10.0 19045) User Interface: UI render: Skia/Raster;VCL: Locale: en-GB(en-GB); UI:en-GB Misc: Calc CL threaded I have tried to give as much info as I can. However, if more is needed then please get back to me and I'll do my best to oblige.
Created attachment 197950 [details] Shows example of problem I am having with left toolbar disappearing I can't think of any further comments I can make at this point
Confirm with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cac9c7db6257b27724d90d4a355e52e456ef7e08 CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded and 6.1 works in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) Behavior depends on zoom - when I zoom in, the problem doesn't occurs. Probably when part of mouse cursor "cross with arrows" overlap border of second textbox, then LO select second textbox.
Created attachment 198285 [details] test file
This seems to have begun at the below commit in bibisect repository/OS bibisect-41max. Adding Cc: to Lennard Wasserthal ; Could you possibly take a look at this one? Thanks e2f4c86ceefd4c44f7e739e3039ef2dae5c849e4 is the first bad commit commit e2f4c86ceefd4c44f7e739e3039ef2dae5c849e4 Author: Matthew Francis <mjay.francis@gmail.com> Date: Fri Sep 18 10:29:40 2015 +0800 source-hash-e80a8b6f14fac6bb6cc7ea55b118f95472d5b654 commit e80a8b6f14fac6bb6cc7ea55b118f95472d5b654 Author: Lennard Wasserthal <Wasserthal@nefkom.net> AuthorDate: Sat Feb 9 14:31:21 2013 +0100 Commit: Tor Lillqvist <tml@iki.fi> CommitDate: Mon Feb 11 10:10:29 2013 +0000 fdo#55430 switches off text mode when clicking an other object. This patch complements 85ea03ae536831649b104694d08dced4d4c8663f (and 6fbba11da54b52554941f00b07e42cc5d7a1643c, which didn't work correctly before) This also fixes issues when clicking on another object to stop text editing. Switches off text mode, and instantaneously selects the other object. (Rotation doesn't belong into the ./sd/ text routine AT ALL, which also caused bug 37482, which is resolved differently from now on) (Creating text fields doesn't belong into the ./sc/ shape text routine either, and if this executed, it causes funny glitches) Known issues: text mode stays on when you use drag'n drop (the one WITH waiting, to move to other applications etc).