Author Topic: Bad icons of C::B in the 16.01 release  (Read 15590 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6035
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Bad icons of C::B in the 16.01 release
« on: January 24, 2016, 07:31:06 am »
I just download this binary
codeblocks-16.01-setup.exe, and unzip it, and run the CBlauncher.exe, I noticed that the icons are really bad!

See the screen shot:



I see this issue in wx3.x build C::B, but now, I see it in wx 2.8 based C::B.

See the bug report here:
https://sourceforge.net/p/codeblocks/tickets/234/
And wx-user mail list discussion:
https://groups.google.com/d/msg/wx-users/eA2pNgviez8/ifbIpukmAQAJ

Any one has ideas how to fix this issue? Thanks.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9699
Re: Bad icons of C::B in the 16.01 release
« Reply #1 on: January 24, 2016, 11:37:16 am »
I just download this binary
codeblocks-16.01-setup.exe, and unzip it, and run the CBlauncher.exe, I noticed that the icons are really bad!
See the screen shot:
For me, the icons are just fine on Windows 10 with the release version.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6035
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Bad icons of C::B in the 16.01 release
« Reply #2 on: February 06, 2016, 06:30:53 am »
I add two image shots, one is for C::B 16.01(rev10702) and the other is from nightly build rev10595. I checked all the commit logs between those two commits, but I don't know what cause this issue. I guess the issue is inside in wx (2.8.12) source.



and



The 16.01 just have much narrow column(118 pixels) then the nightly build version(146 pixels)
« Last Edit: February 12, 2016, 02:18:46 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6035
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Bad icons of C::B in the 16.01 release
« Reply #3 on: February 06, 2016, 06:52:26 am »
OK, then I just build C::B against wx git master head, and the width is 141.
See image below:
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6035
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Bad icons of C::B in the 16.01 release
« Reply #4 on: February 12, 2016, 07:20:29 am »
Guys, I found that if I put a manifest file named "codeblocks.exe.manifest" with the content:

Code
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
    version="1.0.0.0"
    processorArchitecture="*"
    name="CompanyName.ProductName.YourApplication"
    type="win32"
/>
<description>Your application description here.</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>

Along with the codeblocks.exe, then this issue is GONE. (I'm on WinXP)

I just take several days to find this simple solution.

While debugged, I see we have a file named "x86.manifest" in our src\src\resources, and this file is correctly compiled into the codeblocks.exe. (I just a resource editor to open the codeblocks.exe to verify it).

But what the problem is that, when I debugged the code, I see two instance of "comctrl32.dll" is in the process's space, one is version 5, and the other is version 6, in our x86.manifest, we did require version 6, but I see in our C::B's source code, it still get version 5. The related code is here:

Code
// function to check the common controls version
#ifdef __WXMSW__
#include <windows.h>
#include <shlwapi.h>
bool UsesCommonControls6()
{
    bool result = false;
    HINSTANCE hinstDll;
    hinstDll = LoadLibrary(_T("comctl32.dll"));
    if (hinstDll)
    {
        DLLGETVERSIONPROC pDllGetVersion;
        pDllGetVersion = (DLLGETVERSIONPROC)GetProcAddress(hinstDll, "DllGetVersion");

        if (pDllGetVersion)
        {
            DLLVERSIONINFO dvi;
            HRESULT hr;

            ZeroMemory(&dvi, sizeof(dvi));
            dvi.cbSize = sizeof(dvi);

            hr = (*pDllGetVersion)(&dvi);

            if (SUCCEEDED(hr))
               result = dvi.dwMajorVersion == 6;
        }

        FreeLibrary(hinstDll);
    }
    return result;
}
#else
bool UsesCommonControls6()
{
    // for non-windows platforms, return true
    // as this is only used for knowing if bitmaps support transparency or not
    return true;
}
#endif

This means, the icon issue is caused by using the version 5 of the common ctrl.

After I explicitly put a "codeblocks.exe.manifest" along with the codeblocks.exe, it issue is solved.

Any hints about this? maybe, our "x86.manifest" is wrong.

BTW:
The blurred icon was caused by the remove of the alpha channel from the png file(if C::B can't use the version 6 of the comctrl32.dll), see below:
Code
wxBitmap cbLoadBitmap(const wxString& filename, wxBitmapType bitmapType)
{
    // cache this, can't change while we 're running :)
    static bool oldCommonControls = !UsesCommonControls6();

    wxImage im;
    wxFileSystem* fs = new wxFileSystem;
    wxFSFile* f = fs->OpenFile(filename);
    if (f)
    {
        wxInputStream* is = f->GetStream();
        im.LoadFile(*is, bitmapType);
        delete f;
    }
    delete fs;
    if (oldCommonControls && im.HasAlpha())
        im.ConvertAlphaToMask();

    return wxBitmap(im);
}
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6035
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Bad icons of C::B in the 16.01 release
« Reply #5 on: February 12, 2016, 11:26:35 am »
@Morten, your commit rev10409 cause this issue.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6035
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Bad icons of C::B in the 16.01 release
« Reply #6 on: February 12, 2016, 12:02:47 pm »
I think we need to post a message box or dialog to tell user if the version 6 of the comctl32.dll can't be loaded correctly.
Also, do we need to fix the 16.01 binary files(at least it cause some annoy issue under windows XP)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9699
Re: Bad icons of C::B in the 16.01 release
« Reply #7 on: February 12, 2016, 04:20:01 pm »
@Morten, your commit rev10409 cause this issue.
I am ware of that. But I would like to stick with compatibility to recent and current operating systems and better drop support for outdated and no longer supported OS. For the latter we'd probably need to describe the drawbacks. BTW: The wx guys do it the same way, so with wx30 compatibility to WinXP is not granted anymore. So changes towards this OS make only partially sense.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9699
Re: Bad icons of C::B in the 16.01 release
« Reply #8 on: February 12, 2016, 04:30:29 pm »
@Morten, your commit rev10409 cause this issue.
BTW: This commit causes also another issue on wx3.0.2 on Windows: If you click a menu an assertion is raised. But that's a bug in wxWidgets which is fixed in trunk already. However, it makes C::B not ready for production on Windows with wxWidgets v3.0.2. Once again: We should not limit ourselves or do work-arounds because of bugs that are resolved in the near future.
« Last Edit: February 12, 2016, 04:32:01 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Bad icons of C::B in the 16.01 release
« Reply #9 on: February 12, 2016, 08:47:00 pm »
Morten: Have you asked the wx devs if this change could be backported to WX_BRANCH_3_0?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6035
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Bad icons of C::B in the 16.01 release
« Reply #10 on: February 13, 2016, 02:59:29 am »
About the manifest file support, we can have two (the default embedded, and the standalone), and look at some document: Manifest embedded and external - which has priority? Can one override other? - Stack Overflow.

Under Windows XP, the standalone manifest file will take precedence, and other system(Win7 or Win10) will still use the internal one.

About the "click a menu assert", I haven't see it before 2015-12-xx, since to find the icon issue, I have switched from wx 3.0.2 to wx trunk after that day.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9699
Re: Bad icons of C::B in the 16.01 release
« Reply #11 on: February 13, 2016, 10:59:49 pm »
Morten: Have you asked the wx devs if this change could be backported to WX_BRANCH_3_0?
IMHO it is already because its quite serious. I'll check - I've both is use.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9699
Re: Bad icons of C::B in the 16.01 release
« Reply #12 on: February 13, 2016, 11:02:36 pm »
Under Windows XP, the standalone manifest file will take precedence, and other system(Win7 or Win10) will still use the internal one.
If that is the case, it would be an easy fix, indeed. Can you verify its working and provide me with a manifest file so I can see how it affects windows 10, for example?

About the "click a menu assert", I haven't see it before 2015-12-xx, since to find the icon issue, I have switched from wx 3.0.2 to wx trunk after that day.
Notice that this applied only to Windows >v8.1 I believe. The reason is that wx reports a wrong operating system version on those. Thus, some functions will work in "legacy" mode. There was a nice discussion about it on the wx patch tracker. But I don't have a link at hand...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9699
Re: Bad icons of C::B in the 16.01 release
« Reply #13 on: February 13, 2016, 11:16:12 pm »
IMHO it is already because its quite serious. I'll check - I've both is use.
Yes, it is (see [wxWidgets]\src\msw\utils.cpp). so wxWidgets 3.0.3 (hopefully such thing will arrive soon) will have it fixed.

Edit: That is the fix, btw:
http://svn.wxwidgets.org/viewvc/wx/wxWidgets/branches/WX_3_0_BRANCH/src/msw/utils.cpp?r1=76715&r2=76714&pathrev=76715
« Last Edit: February 14, 2016, 12:09:30 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6035
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Bad icons of C::B in the 16.01 release
« Reply #14 on: February 14, 2016, 05:26:39 am »
Under Windows XP, the standalone manifest file will take precedence, and other system(Win7 or Win10) will still use the internal one.
If that is the case, it would be an easy fix, indeed. Can you verify its working and provide me with a manifest file so I can see how it affects windows 10, for example?
Yes, it works here, I just add a file named codeblocks.exe.manifest, and it works fine with our 16.01 pre-build binary release.
You can use the one in my post: Re: Bad icons of C::B in the 16.01 release, also, you can just use the manifest file (x86.manifest) before the commit rev 10409.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.