Apache OpenOffice (AOO) Bugzilla – Issue 58312
font tab: Font-size widget has wrong behavior
Last modified: 2010-02-02 13:38:18 UTC
Open the paragraph style editor dialog. Select the font tabbed panel. Select a value for the size. Scroll down the list until the selected value is out of port view. Select a size value. The list scrolls up until the old selected size value and a different value, close to the old one, is selected.
I don't see any problems: could you give a more detailed explanation please?
I cannot see any problem here. It works fine on my Windows XP (with "Windows classic" theme). Do you have a specific theme other than the default activated on your system?
Created attachment 32402 [details] Selectionsequence1_3
My SO is the WIndows 2000 with default theme. I try to explain in a more clear way. Let suppose thatthe layout for the font size list, in the font tabbed pane for the paragraph editor dialog, it's: Size -------- 12Pt --------(start view port) /12pt/ (selection) 13pt | (scroll cursor position) 14pt --------(end view port) 15pt 16pt 17pt 18pt 19pt 20pt Lets scroll the list with the scrollbar, not the buttons up and down but the cursor, till the selected entry will be out of view: Size -------- 12Pt --------(start view port) 17pt 18pt 19pt | (scroll cursor position) --------(end view port) 20pt now try to select 19pt The list will be scrolled up and the selection will be on a value close to the 12pt: -------- 14Pt --------(start view port) 12pt 13pt | (scroll cursor position) /14pt/ (selection) --------(end view port) 15pt 16pt 17pt 18pt 19pt 20pt I've attached som pictures tanks
Created attachment 32403 [details] Sorry thi one is the correct one.(Sequence)
Now I see the problem; it is essential that you use the fontsize selector two times to see the bug. MRU->OS: open the font tab (does not matter wether it is the Format.Character or the Edit.Paragraph style dialog). Use the scrollbar to move the selected font size out of the visible area. Now select a new FontSize. Again, use the Scrollbar to move the selection out of the visible area. Try to select a new FontSize -> now the control will display a different area of the sizes list.
Target adjusted
This Issue requires more information ('needmoreinfo'), but has not been updated within the last year. Please re-test with one of the latest versions of OOo - 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 : 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 ~
This bug is still present in DEV300_m25. My OS is Linux (Fedora 9) on x86_64.
->pl: The problem seems to be in MetricBox::Notify() On EVENT_LOSEFOCUS the box wants to be reformatted. That causes the stack below and ends in a change of selection. stack: vclmi.dll!ImplListBoxWindow::SetTopEntry(unsigned short nTop=1) Line 1868 C++ vclmi.dll!ComboBox::ImplUpdateFloatSelection() Line 938 C++ vclmi.dll!ComboBox::SetText(const String & rStr={...}, const Selection & rNewSelection={...}) Line 895 C++ vclmi.dll!FormatterBase::ImplSetText(const String & rText={...}, Selection * pNewSelection=0x00000000) Line 392 C++ vclmi.dll!MetricFormatter::Reformat() Line 1677 C++ svtmi.dll!FontSizeBox::Reformat() Line 1174 C++ > vclmi.dll!MetricBox::Notify(NotifyEvent & rNEvt={...}) Line 1934 C++ vclmi.dll!Window::Notify() + 0x327 bytes C++ vclmi.dll!Window::Notify() + 0x327 bytes C++ vclmi.dll!ImplListBox::Notify(NotifyEvent & rNEvt={...}) Line 2436 + 0x1a bytes C++ vclmi.dll!Window::Notify() + 0x327 bytes C++
I have found a simple solution of this bug and one more I found working on this one. It's not particularly smart--it simply tests in ComboBox::PreNotify() if the window sending notification is the listBox and doesn't let the mpSubEdit grab focus in that case--yet another workaround relying on specific behaviour of other components involved. The solution changes behaviour of ComboBox, however--click on any part aside of the listBox (even the scrollbars) is followed by the editField getting focus. --- The other bug I've spoken about is reproducible following these steps: 1. open font dialog 2. click to size box on some number somewhere in the middle of the listBox 3. click on one of the arrows of vertical scrollbar Now focus is on item before (or after, depending on which arrow has been used) the selected one.
Created attachment 55757 [details] Fix of selection in font size box.
*** Issue 52823 has been marked as a duplicate of this issue. ***
No further info required
For the sake of completeness: This is not a special WRITER problem, same effect ca be seen in CALC and DRAW.
The problem is caused by calling mpSubEdit->GrabFocus() in ComboBox::PreNotify() when processing EVENT_MOUSEBUTTONDOWN on mpImplLB. This causes EVENT_LOSEFOCUS to be emitted on mpImplLB, which in turn ends in reformatting the whole control box (through MetricBox::Notify()). Because, at this stage, the click hasn't been processed yet, the item selected in the listbox is still the original one, thus the listbox is scrolled to get it to view. Thus, when the click is finally processed, the view of the listbox has already been set to differenent range. dtardon->pl: It seems to me the best thing is to move the problematic code from ComboBox::PreNotify() to ComboBox::Notify(). Do you agree, or could there be any hidden consequences that I haven't spotted?
Created attachment 63538 [details] move the focus grabbing to ComboBox::Notify()
adding myself to cc
You won't hear me say that there is no side effect for this change; when changing focus behavior bets are usually off. However I confirmed your patch fixes the issue, and I see no harm either, so I'll commit it in CWS vcl104. Thanks for this patch !
please verify in CWS vcl104
Verified fix in CWS vcl104.
Checked in DEV300m60.
*** Issue 46922 has been marked as a duplicate of this issue. ***