Opened 3 years ago

Closed 2 years ago

Last modified 15 months ago

#13512 closed defect (fixed)

wxToolBar doesn't appear correctly in an application using comctl32.dll < 6.0

Reported by: gopalvenu Owned by:
Priority: low Milestone: 2.9.4
Component: wxMSW Version: stable-latest
Keywords: toolbar manifest comctl32 Cc:
Blocked By: Blocking:
Patch: yes

Description

[wxWidgets 2.9.2] [MINGW-4.4.1] [Windows 7]

I trying to create a toolbar using wxWidgets 2.9.2. The code works fine with version 2.8.12, but has the following problem in 2.9.2.

In version 2.9.2 te toolbar shows a white background rather than the gray background - and this white area does not stretch when I resize (widen) the main window. In fact, the white paint appears to be coming from from some unrelated previous paint operation.

images attached

Attachments (9)

At_Start.jpg download (11.4 KB) - added by gopalvenu 3 years ago.
After_main_window_widening.jpg download (15.3 KB) - added by gopalvenu 3 years ago.
After_main_window_narrowing_then_widening.jpg download (11.7 KB) - added by gopalvenu 3 years ago.
sample code.zip download (20.2 KB) - added by gopalvenu 3 years ago.
Sample Code (executable was too big to upload)
2011_10_12_1 At start.JPG download (26.1 KB) - added by gopalvenu 3 years ago.
2011_10_12_2 After widening.JPG download (28.2 KB) - added by gopalvenu 3 years ago.
2011_10_12_3 After mimizing and restoring.JPG download (27.3 KB) - added by gopalvenu 3 years ago.
13512reproduce.diff download (1.7 KB) - added by disc 2 years ago.
13512fix.patch download (1.7 KB) - added by disc 2 years ago.

Download all attachments as: .zip

Change History (30)

Changed 3 years ago by gopalvenu

Changed 3 years ago by gopalvenu

Changed 3 years ago by gopalvenu

comment:1 Changed 3 years ago by vadz

  • Status changed from new to infoneeded_new

I suspect you do something strange with background erasing. Please try to reproduce the problem in the toolbar sample and submit a minimal patch showing it.

TIA!

Changed 3 years ago by gopalvenu

Sample Code (executable was too big to upload)

comment:2 Changed 3 years ago by gopalvenu

  • Status changed from infoneeded_new to new

(Please also note that) I went to get the toolbar sample - I got to "http://docs.wxwidgets.org/2.8/wx_samples.html#sampletoolbar" and there was explanation of the toolbar sample, but did not see code or link to code.

comment:3 follow-up: Changed 3 years ago by vadz

  • Status changed from new to infoneeded_new

Sorry, I don't have the possibility to study sample code provided in such way. Please reread the instructions and try to reproduce the problem in the toolbar sample.

TIA!

comment:4 in reply to: ↑ 3 Changed 3 years ago by gopalvenu

  • Status changed from infoneeded_new to new

Replying to vadz:

Sorry, I don't have the possibility to study sample code provided in such way. Please reread the instructions and try to reproduce the problem in the toolbar sample.

TIA!

Can you give me a link to the sample code for toolabr? I couldn't find it.

comment:5 Changed 3 years ago by vadz

comment:6 Changed 3 years ago by gopalvenu

I have reproduced the problem in the toolbar sample code. I downloaded the "toolbar sample code" for 2.9.2 that you provided a link to. (Note that I did not have the toolbar button images to download).

I commented out ONE LINE - there was no other change

line 490 | toolBar->AddStretchableSpace();

and compiled it (MingW, Win 7)

It still shows the same problem *

I have attached three pictures :

  1. After start

Issues: font is messed up

  1. After stretching the main frame to the right

Issues: font is still messed up, plus

toolbar now has two regions with different backgrounds - (need to look closely)

  1. After minimizing program to taskbar, and restoring it

All issues gone (font is ok, background is ok)

These pictures should illustrate the issue very clearly.

I found one other issue during my testing:

In 2.8.12, toolbar::SetBackgroundColour() sets the color of the whole bar In 2.9.2, it seems to set the background color for each button, and not for the whole bar.

Let me know if you need any further info. I was trying to migrate from 2.8.12 to 2.9.2 and this is a total showstopper.

Changed 3 years ago by gopalvenu

Changed 3 years ago by gopalvenu

Changed 3 years ago by gopalvenu

comment:7 Changed 3 years ago by vadz

Must be some problem with MinGW headers because I definitely don't see this with MSVC. Which version of MinGW do you use?

comment:8 Changed 3 years ago by gopalvenu

MinGW-4.4.1

comment:9 Changed 3 years ago by catalin

FWIW I cannot see it happening in Win7 with very recent trunk and gcc 4.4.1. Could it be a manifest problem?
I also see each button with both image and text, unless I un-check the imagem option in the menu, in which case the images disappear but the buttons size is still as big as a button with image. IOW the whole think looks quite different on my machine in the same described conditions. Is something else changed in the wxW sources?

comment:10 Changed 3 years ago by vadz

Good point about the manifest, this could indeed explain it (and this would still be a bug then, of course, as it would mean that we check for Windows version instead of whether the app is themed or something like this, but a quite low priority one).

gopalvenu, do you use wxWidgets makefiles for building the sample?

comment:11 Changed 3 years ago by gopalvenu

I am using CodeLite v3.0.5041 with bundled MinGW-4.4.1 and wxWidgets 2.9.2.

CodeLite generates its own makefiles and invokes mingw32-make.exe on it.

Is there any data I can collect that will be of help?

comment:12 Changed 3 years ago by gopalvenu

Spent a few hours investigating this further.

The problem with the font, button mouseover, button press/release etc. seem to be there ONLY for the wxTB_FLAT style.

catalin, you tried to reproduce the issue but was not able to - I wonder if you could retry with the style below. Appreciate your help!:

toolBar_for_main_frame = this->CreateToolBar( wxTB_DOCKABLE|wxTB_FLAT|wxTB_TEXT|wxSIMPLE_BORDER, ID_toolBar_for_main_frame );

The toolbar background issue was still there even after I removed the wxTB_FLAT style.

comment:13 Changed 3 years ago by gopalvenu

in the wxTB_FLAT style where the issue shows up for me, it is "as if" the toolbar button position moves "to the left" or "left and up" by 1 or two pixels

comment:14 Changed 3 years ago by gopalvenu

Gosh, I just realized that I had not included the "wx/msw/wx.rc" in resource file. Apparenlty this is needed for toolbars to work properly. My bad.

comment:15 Changed 3 years ago by vadz

  • Keywords toolbar manifest added
  • Priority changed from normal to low
  • Status changed from new to confirmed
  • Summary changed from Toolbar issue in 2.9.2 (not there in 2.8.12) to wxToolBar doesn't appear correctly in an application not using the manifest

Arguably the toolbar should still look correctly even without manifest, as I wrote before, I think we check for the OS version instead of checking for whether the application is themed somewhere, and ideally this should be fixed. It's low priority however, meaning that I'm only going to look at this if somebody really needs to build a wx application without a manifest.

Any patches fixing this would, of course, be welcome in any case.

comment:16 Changed 3 years ago by gopalvenu

Wish I could help with the patch - but I am not at all familiar with the wxwidgets source.

Sounds to m elike you already know a fix - I will be very happy to test this for you on Win 7 and win XP (don't have access to other platforms now).

Perhaps at least the documentation can be updated in the meantime for wxToolBar class indicating that manifest is needed ?

Changed 2 years ago by disc

Changed 2 years ago by disc

comment:17 Changed 2 years ago by disc

  • Keywords comctl32 added
  • Patch set
  • Summary changed from wxToolBar doesn't appear correctly in an application not using the manifest to wxToolBar doesn't appear correctly in an application using comctl32.dll < 6.0
  • Version changed from 2.9.2 to 2.9-svn

The difference is the comctl32.dll version used, either 6.0+ or earlier. Attached is a diff to reproduce the problem in the toolbar sample. It forces using wx' manifest file instead of using the one that MSVC generates in MSVC8/2005 and later. It also modifies wx.manifest to not use comctl32.dll 6.0, it does that in a rather clumsy way though and probably only works for MSVC9/2008.
I also attached a patch which restores some of the older code and fixes the transparent background problem (at the cost of the reintroduction of some flickering) when using e.g. comctl32.dll 5.82. It doesn't change the behaviour with 6.0 or later so I think it's safe. If the fix is acceptable I can commit the patch.

comment:18 Changed 2 years ago by vadz

  • Milestone set to 2.9.4

Thanks Dimitri, this looks like the right thing to do, please apply it.

comment:19 Changed 2 years ago by DS

  • Resolution set to fixed
  • Status changed from confirmed to closed

(In [71341]) Fixed parts of toolbar background not being drawn with older comctl32.dll.

When using comctl32.dll versions older than 6.0 toolbar icons would not have their background drawn. Fix this in a rough way by always completely erasing the background like was done before. Regression since r62971.

Closes #13512.

comment:20 Changed 15 months ago by vadz

FWIW there are more problems when using comctl32.dll v5.80 under XP and later systems: button bitmaps with alpha don't get disabled correctly, i.e. their transparency is ignored and they appear as grey blobs when disabled instead of nicely greyed out icons with 6.0. There are other problems, too, e.g. disabled images in the toolbar sample are of wrong size and have wrong background.

Unfortunately I ran out of time for fixing this and, anyhow, using the correct manifest is a better idea anyhow but I'm leaving this note here just in case it can help somebody who runs into the same symptoms.

comment:21 Changed 15 months ago by VZ

(In [74509]) Restore embedding manifest when using MinGW.

The changes of r73483 broke inclusion of the manifest in the programs built
using MinGW because wxUSE_RC_MANIFEST was never defined. Somehow nobody
complained about it but this resulted in using comctl32.dll 5.80 instead of
6.0 and e.g. problems with toolbar appearance (see #13512).

Do use the manifest by default with MinGW and, in fact, all the other
compilers if any other ones still work, as only MSVC is known to embed the
manifest automatically and we take care of it separately.

Note: See TracTickets for help on using tickets.