Created attachment 45941 [details]
Screenshots, pls see original report

I confirm, same behavior for me... it's a regression and obvious blocker.

I cannot confirm on Linux, possibly Windows-specific. And spinboxes missing secondary functionality is hardly a blocker.

(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...

Due to  vitriol's confirmation: NEW

@Lubos:
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.

Spin buttons exist although are invisible. Try to click at the right of box, they work.
It's definitely a stopper for me...

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.

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.

OK Tor. I wait the beta 3 for test :-)

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.

Sadly the bug persists in Beta 3 too. Very bad...

<http://wiki.documentfoundation.org/BugReport_Details#Version>

(In reply to comment #12)
> <http://wiki.documentfoundation.org/BugReport_Details#Version>
Sorry again!

@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.

Alex

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.)

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?

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'

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.

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.