Bug 49181 - MINGW UI: Docked toolbars can not be moved
Summary: MINGW UI: Docked toolbars can not be moved
Status: RESOLVED DUPLICATE of bug 41985
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.5 Daily
Hardware: All Windows (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-26 09:57 UTC by ape
Modified: 2012-05-09 21:05 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
locking toolbars (9.00 KB, image/png)
2012-04-26 09:57 UTC, ape
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ape 2012-04-26 09:57:13 UTC
Created attachment 60621 [details]
locking toolbars

Toolbars are rigidly fixed and do not move.
Comment 1 ape 2012-04-26 10:00:12 UTC
(In reply to comment #0)
> Created attachment 60621 [details]
> locking toolbars
> 
> Toolbars are rigidly fixed and do not move.
------------
LOdev 3.5.4rc0+ 
Build ID: 8d9e2d9-a73d29c-6845e52-f269e46
OS: Windows-XPsp2_x64; Windows-7sp1_x32
Comment 2 manj_k 2012-04-26 14:14:00 UTC
Works for me (on WinXP 32b) with 
LOdev 3.5.4rc0+ 
Build ID: fc0c85e-a73d29c-6845e52-f269e46-186d9ed
tinderbox: buildname: Win-x86@15-Prague Win32
tinderbox: tree: libreoffice-3-5
tinderbox: pull time 2012-04-21 20:05:59
Comment 3 ape 2012-04-26 20:44:21 UTC
(In reply to comment #2)
> Works for me (on WinXP 32b) with 
> LOdev 3.5.4rc0+ 
> Build ID: fc0c85e-a73d29c-6845e52-f269e46-186d9ed
> tinderbox: buildname: Win-x86@15-Prague Win32
> tinderbox: tree: libreoffice-3-5
> tinderbox: pull time 2012-04-21 20:05:59

This build is the last worker.
Comment 4 Rainer Bielefeld Retired 2012-04-26 23:07:49 UTC
NOT Reproducible with "LibO-Dev_3.5.4rc0  [Build ID: ec752de-73cb0b8-f269e46] Win-x86@6-fast pull time 2012-03-19 11:08:23 – WIN7 Home Premium (64bit)

@reporter:
Thank you for your report – unfortunately important information is missing.
May be hints on <http://wiki.documentfoundation.org/BugReport> will help you to find out what information will be useful to reproduce your problem? If you believe that that  is really sophisticated please as for Help on a user mailing list
Please:
- Write a meaningful Summary describing exactly what the problem is
- Contribute a step by step instruction containing every key press and every 
  mouse click how to reproduce your problem (due to example in Bug 43431)
- add information 
  -- what EXACTLY is unexpected (cursor does not change to "move view"?)
  -- and WHY do you believe it's unexpected (cite Help or Documentation!)
  -- concerning your PC 
  -- concerning download source, pull time, ...
  –- Libo settings that might be related to your problems 
    (video hardware acceleration ...)
  -- how you launch LibO and how you opened the sample document
  -- everything else crossing your mind after you read linked texts

Even  if you can not provide all demanded information, every little new information might bring the breakthrough.

Please submit Bugs with initial status UNCONFIRMED

May be you can test <https://www.libreoffice.org/get-help/bug/> for submitting bug reports?
Comment 5 ape 2012-04-27 01:28:57 UTC
(In reply to comment #4)
> NOT Reproducible with "LibO-Dev_3.5.4rc0  [Build ID: ec752de-73cb0b8-f269e46]
> Win-x86@6-fast pull time 2012-03-19 11:08:23 – WIN7 Home Premium (64bit)
----------
The problem emerged in last two builds "Win-x86@7-MinGW":
 2012-04-25_14.56.06;
 2012-04-25_14.56.06.
I did not check for errors the "Win-x86@7-MinGW":
 2012-04-23_07.08.07;
 2012-04-24_11.37.45.
Hardware (the mouse or the touchpad) and Windows does not affect the occurrence of the error: "Win-x86@15-Prague_Win32" dated April 21, works fine at these PC's.
The last builds does not allow you to take and move the toolbars (Writer: "standart" or "format") by the mouse or the touchpad. The cursor (crossed arrows) does not appear.
Comment 6 ape 2012-04-27 01:52:53 UTC
(In reply to comment #5)
> The problem emerged in last two builds "Win-x86@7-MinGW":
>  2012-04-25_14.56.06;
>  2012-04-25_14.56.06.
---------
Sorry:
The problem emerged in last two builds "Win-x86@7-MinGW":
 2012-04-25_14.56.06;
 2012-04-26_09.53.25.
Comment 7 Rainer Bielefeld Retired 2012-04-27 02:00:21 UTC
Probably DUP of "Bug 41985 - MinGW: UI display broken"
@ape:
May be you suffer from a.m. Bug "Mouse pointer disappears instead of changing to "move arrows""?

When I move mouse pointer to the toolbar handle area at the left coming from the right, mouse pointer will disappear at the handle area and reappear moving further to the left as shown in you screenshot. But I can move the toolbar by drag and drop with the invisible mouse pointer. Can you please check?
Comment 8 Rainer Bielefeld Retired 2012-04-27 02:11:14 UTC
(In reply to comment #6)

@ape:
Can you please use build info strings similar to the one you see in my Comment with additional info whether it's from Master or daily branch (I will add that info in future, too)? That will ease to recognize relations very much.
Comment 9 ape 2012-04-27 02:49:03 UTC
(In reply to comment #8)
> (In reply to comment #6)
> 
> @ape:
> Can you please use build info strings similar to the one you see in my Comment
> with additional info whether it's from Master or daily branch (I will add that
> info in future, too)? That will ease to recognize relations very much.

------
1. Yes, this is the Bug_41985.
 The control panel is took and was moved by the cursor invisible. But it was very difficult to do on Asus_EeePC.
2. Last release with bug:
LOdev 3.5.4rc0+ [Build ID: 8d9e2d9-a73d29c-6845e52-f269e46]
Win-x86@7-MinGW pull time 2012-04-26_09.53.25 - WIN7 Home Premium sp1 (32bit) and WINXP Proffessional sp2 (64bit).
3. About "Master":
NOT Reproducible with "LibO-Dev_ 3.6.0alpha0+" [Build ID: b77858b] Win-x86@7-MinGW pull time 2012-04-26_23.01.24 - WIN7 Home Premium sp1 (32bit) and WINXP Proffessional sp2 (64bit).
Comment 10 Rainer Bielefeld Retired 2012-05-09 21:05:33 UTC
DUP due to comment 9. 

@ape:
Can you close that one WFM if you can reproduce that it still works fine  in second build?

*** This bug has been marked as a duplicate of bug 41985 ***