Issue 80543

Summary: Dialog-UI Problem
Product: ui Reporter: thomaskrumbein <tk>
Component: uiAssignee: marc.neumann
Status: CLOSED FIXED QA Contact: issues@ui <issues>
Severity: Trivial    
Priority: P2 CC: Armin.Le.Grand, clippka, cno, hdu, issues, joerg.skottke
Version: 680m223Keywords: oooqa, regression
Target Milestone: OOo 2.3   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 80294    
Attachments:
Description Flags
Picture of Button in IDE 680_223 none

Description thomaskrumbein 2007-08-09 19:20:22 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.
Comment 1 thomaskrumbein 2007-08-09 19:23:01 UTC
Created attachment 47440 [details]
Picture of Button in IDE 680_223
Comment 2 Mechtilde 2007-08-14 11:41:49 UTC
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. 
Comment 3 joerg.skottke 2007-08-14 12:19:15 UTC
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
Comment 4 Mechtilde 2007-08-14 12:38:33 UTC
I tested it today with Pavels OOG680_m1 from weekend
Comment 5 joerg.skottke 2007-08-14 12:46:32 UTC
Ok, issue has been confirmed -> aw
Comment 6 Mechtilde 2007-08-14 12:57:45 UTC
I'm using Debian Etch
Comment 7 joerg.skottke 2007-08-14 13:05:28 UTC
Duplicate to issue 79311

*** This issue has been marked as a duplicate of 79311 ***
Comment 8 Armin Le Grand 2007-08-14 13:53:43 UTC
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.
Comment 9 joerg.skottke 2007-08-14 14:01:53 UTC
to PL.
Comment 10 mdxonefour 2007-08-16 16:01:17 UTC
MD: As discussed with AB, this issue is not duplicate to 79311. So I re-open it.
Comment 11 mdxonefour 2007-08-16 16:08:42 UTC
MD: added hdu and cl to cc list
Comment 12 mdxonefour 2007-08-16 16:09:32 UTC
set target 2.3
Comment 13 mdxonefour 2007-08-16 16:10:31 UTC
MD: Similar issue has been seen on Windows 2003 Server. So it's not only Vista.
Comment 14 mdxonefour 2007-08-16 16:11:29 UTC
MD: As discussed with KA set owner to CL.
Comment 15 cno 2007-08-16 16:31:10 UTC
Hi,
On XP it looks the same in m223 as in 2.2.1.
Comment 16 hdu@apache.org 2007-08-17 08:44:35 UTC
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?
Comment 17 clippka 2007-08-17 09:29:06 UTC
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
Comment 18 clippka 2007-08-17 15:38:57 UTC
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
Comment 19 clippka 2007-08-17 16:46:18 UTC
verified in cws, please test
Comment 20 marc.neumann 2007-08-20 08:35:48 UTC
reassign to msc
Comment 21 marc.neumann 2007-08-20 08:36:23 UTC
reassign to msc
Comment 22 marc.neumann 2007-08-21 11:52:16 UTC
verify in cws impress128
Comment 23 Mechtilde 2007-09-01 08:55:40 UTC
verified in OOG680_m3 -> closed