Bug 36481 - Spinboxes missing up/down arrows
Summary: Spinboxes missing up/down arrows
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
3.4.0 Beta2
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: mab3.4
  Show dependency treegraph
Reported: 2011-04-22 03:42 UTC by Rainer Bielefeld Retired
Modified: 2011-05-03 04:15 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Screenshots, pls see original report (91.92 KB, application/x-download)
2011-04-22 03:43 UTC, Rainer Bielefeld Retired

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2011-04-22 03:42:52 UTC
It seems that all increase / decrease buttons are missing, pls. see attached screenshots.
Comment 1 Rainer Bielefeld Retired 2011-04-22 03:43:44 UTC
Created attachment 45941 [details]
Screenshots, pls see original report
Comment 2 vitriol 2011-04-22 04:31:35 UTC
I confirm, same behavior for me... it's a regression and obvious blocker.
Comment 3 Luboš Luňák 2011-04-22 04:48:53 UTC
I cannot confirm on Linux, possibly Windows-specific. And spinboxes missing secondary functionality is hardly a blocker.
Comment 4 vitriol 2011-04-22 04:53:26 UTC
(In reply to comment #3)

> And spinboxes missing secondary functionality is hardly a blocker.

LOL. A type of control completely missing in the UI is not a blocker? Unbelievable...
Comment 5 Rainer Bielefeld Retired 2011-04-22 06:02:29 UTC
Due to  vitriol's confirmation: NEW

Yes, LibO remains usable also without spinboxes, but it looks crippled. And every user at least will see that, and nearba every user will be affected.
Comment 6 vitriol 2011-04-24 12:46:13 UTC
Spin buttons exist although are invisible. Try to click at the right of box, they work.
It's definitely a stopper for me...
Comment 7 vitriol 2011-04-26 11:01:15 UTC
This is a Tor Lillqvist stuff? It really needs to be assigned ad fixed very soon.
Users can have a very bad perception of Windows version.
Comment 8 Don't use this account, use tml@iki.fi 2011-04-26 11:13:21 UTC
I don't know why, but in an own fresh build of the 3.4 branch I don't see this problem. So hopefully it will be fixed in beta3.
Comment 9 vitriol 2011-04-26 11:20:12 UTC
OK Tor. I wait the beta 3 for test :-)
Comment 10 Zack 2011-04-27 15:57:12 UTC
I can confirm this as well.  I too believe it's close to a blocker.  If not a blocker certainly a critical bug.  Awaiting Beta 3.
Comment 11 vitriol 2011-04-29 03:03:17 UTC
Sadly the bug persists in Beta 3 too. Very bad...
Comment 12 Rainer Bielefeld Retired 2011-04-29 10:38:01 UTC
Comment 13 Zack 2011-04-29 10:54:24 UTC
(In reply to comment #12)
> <http://wiki.documentfoundation.org/BugReport_Details#Version>
Sorry again!
Comment 14 Alex Thurgood 2011-05-01 02:28:56 UTC
@all :

The same issue has just been reported with Beta3 on Windows by a user on the French user list, so if a fix was made, it didn't get pushed in time for the beta3 release.

Comment 15 Don't use this account, use tml@iki.fi 2011-05-02 02:42:41 UTC
The immediate cause for spin buttons not being drawn seems to be that in OutputDevice::DrawNativeControl() in vcl/source/gdi/outdevnative.cxx, the rControlRegion field is {nLeft=0 nTop=0 nRight=-32767 nBottom=-32767} , whatever that means, but it counts as "empty" anyway so the method returns early at line 240.

(That method is in this case called to draw the "native" spinbutton from ImplDrawNativeSpinfield() in vcl/source/control/spinfld.cxx.)
Comment 16 Don't use this account, use tml@iki.fi 2011-05-02 02:53:54 UTC
ImplDrawNativeSpinfield() calls pWin->DrawNativeControl() (which here then is OutputDevice::DrawNativeControl()) explicitly passing a fresh temporary (and empty) Rectangle as the rControlRegion parameter:

if( pWin->IsNativeControlSupported(CTRL_SPINBOX, rSpinbuttonValue.mnUpperPart) && 
    pWin->IsNativeControlSupported(CTRL_SPINBOX, rSpinbuttonValue.mnLowerPart) )
    // only paint the embedded spin buttons, all buttons are painted at once
    bNativeOK = pWin->DrawNativeControl( CTRL_SPINBOX, PART_ALL_BUTTONS,
                                         Rectangle(), CTRL_STATE_ENABLED,
                                         rSpinbuttonValue, rtl::OUString() );

So it is not surprising that then the test in OutputDevice::DrawNativeControl() notices that it is empty and returns:

if ( mbOutputClipped || rControlRegion.IsEmpty() )
    return sal_True;

The check for IsEmpty was added by mmeeks on Tue Mar 15 18:05:42 2011 with the comment "don't handle very oddly sized (but empty) control regions, they cause grief". Michael, do you recall what problem this change fixed?
Comment 17 Rainer Bielefeld Retired 2011-05-02 03:14:03 UTC
I doubt that it's a really new aspect, but for the sake of completeness: Spin Buttons are also not shown (but existing and working, if you find the right place where to click) in menu 'Tools > Customize > Toobars > Modify > Change Icon'
Comment 18 Don't use this account, use tml@iki.fi 2011-05-02 03:34:37 UTC
OK, fixed now in the libreoffice-3-4 branch in a straightforward (but clueless) manner: Bypass the check for emptiness on Windows.

Rainer, that is indeed just another symptom of the same problem.
Comment 19 Michael Meeks 2011-05-03 04:12:35 UTC
Sure - so the change this fixed was an immediate crash under Linux, when rendering controls with zero sized regions;
AFAIR - this happened -a-lot- eg. on startup, or when we did some fairly trivial operation, adding that fixed this. Interestingly, it seems to have been fixed in some other way recently, since removing that no longer provokes the problem.

So - I guess I'll just revert the change in both branches; clearly I should write more down about the bug fixes, with numbers and traces, but it was done in some sort of rush while resolving tons of awful merging issues.