Apache OpenOffice (AOO) Bugzilla – Issue 80543
Dialog-UI Problem
Last modified: 2007-09-01 08:55:41 UTC
During testing on 223 (Sun Build) the following could be registered: Trying to place a command button on a dialog, the button size and the button itself will not be visible. is is there - yes, but during design-prozess it is not visibel (see screenshot attached). Background Color is still ignored (this never was working). When executing the Dialog, the Button is visibel becouse of an defined border - this bug is only during design.
Created attachment 47440 [details] Picture of Button in IDE 680_223
In 2.2.1 the buttons have an own background colour which can't be changed. In the versions > 223 they have the same background colour as the dialog itself.
Hi Thomas, can you please check this in a more recent build? There was a CWS (integrated into m224 or 225) that fixes some display problems related to the Form Controls and BASIC IDE dialogs. Thanks! Joerg
I tested it today with Pavels OOG680_m1 from weekend
Ok, issue has been confirmed -> aw
I'm using Debian Etch
Duplicate to issue 79311 *** This issue has been marked as a duplicate of 79311 ***
AW: Since i am the owner ATM: If You ask me, it should go to someone from VCL team, maybe PL. DrawingLayer does nothing special in Vista. The duplicate is owned by AB who - IMHO - can also not do too much about it.
to PL.
MD: As discussed with AB, this issue is not duplicate to 79311. So I re-open it.
MD: added hdu and cl to cc list
set target 2.3
MD: Similar issue has been seen on Windows 2003 Server. So it's not only Vista.
MD: As discussed with KA set owner to CL.
Hi, On XP it looks the same in m223 as in 2.2.1.
Maybe I"m just showing my ignorance here, but looking at http://so-web.germany.sun.com/bonsai/cvsview2.cgi?command=DIFF&subdir=script%2Fbasctl%2Fsource %2Fdlged&file=dlged.cxx&rev1=1.48&rev2=1.51&whitespace_mode=show&diff_mode=context I"m wondering, if the code after the // do paint (unbuffered) and mark repaint end comment needs to be adjusted to rTargetOutDev too? AW?
cl->hdu: yes that was also my first idea but it does not fix the problem. There are at least 3 output devices involved in the new drawing scheme but since it is not documented how it should work, that will be a lot of debuging. So currently it is about getting debug code and some corneflakes
fixed in toolkit/source/awt/vclxwindow.cxx (r 1.77.10.1) Problem was that the controls where painted with native widgets and that is not working for the new overlay stuff. I'm not sure if this is the correct fix so this shoulde be reviewed by fs and aw after their vacation. My patch is in VCLXWindow::draw() do + BOOL bOldNW =pWindow->IsNativeWidgetEnabled(); + if( bOldNW ) + pWindow->EnableNativeWidget(FALSE); pWindow->PaintToDevice( pDev, aP, aSz ); + if( bOldNW ) + pWindow->EnableNativeWidget(TRUE); I think this does not harm anyone since the change is not permanent and it should be safe to do this here since PaintToDevice would not work with native widgets enabled
verified in cws, please test
reassign to msc
verify in cws impress128
verified in OOG680_m3 -> closed