Menu

#627 UXTheme error when compiling with wxWidgets 3.1.1

Undefined
invalid
nobody
None
Patch
2020-12-24
2018-02-22
No

wxWidgets removed some UXtheme functions in version 3.1.1. OllyDbg proposed a patch in the forum

http://forums.codeblocks.org/index.php/topic,22421.msg152637.html#msg152637

but this patch only removes the call to the function. For proper theming support I propose this patch.

1 Attachments

Discussion

  • Miguel Gimenez

    Miguel Gimenez - 2018-02-22

    Removed spurious "defined" from the patch

     
  • ollydbg

    ollydbg - 2018-02-22
    Index: src/CodeBlocks_wx31.cbp
    ===================================================================
    diff --git a/trunk/src/CodeBlocks_wx31.cbp b/trunk/src/CodeBlocks_wx31.cbp
    --- a/trunk/src/CodeBlocks_wx31.cbp (revisi髇: 11299)
    +++ b/trunk/src/CodeBlocks_wx31.cbp (copia de trabajo)
    @@ -201,6 +201,7 @@
                        <Add library="rpcrt4" />
                        <Add library="advapi32" />
                        <Add library="wsock32" />
    +                   <Add library="uxtheme" />
                        <Add directory="devel31" />
                        <Add directory="exchndl/win32/lib" />
                    </Linker>
    

    Do you mean that the uxtheme library always exist in the windows gcc compiler?

     

    Last edit: ollydbg 2018-02-22
  • Miguel Gimenez

    Miguel Gimenez - 2018-02-22

    wxWidgets was linking with it until V3.1.1, so it should exist in all Windows GCC who were able to compile wxWidgets.

    This library didn't exist before XP, but those OSes are not supported anyway.

     
  • Teodor Petrov

    Teodor Petrov - 2018-02-22

    Can someone show what is the visual difference with and without using the patch?

     
  • Miguel Gimenez

    Miguel Gimenez - 2018-02-23

    The first part of the code (SetSelection...) changes three protected variables that are not used anywhere (except for comparison purposes in operator ==), so I think it's safe to remove it.

    The second part changes m_borderColour to dark violet opposed to black. Not a big difference.

    This last patch removes uxtheme completely.

     
  • Miguel Gimenez

    Miguel Gimenez - 2018-02-23

    Remove also all unused vars/methods.

     
  • ollydbg

    ollydbg - 2018-02-28

    Hi, Miguel Gimenez, thanks for the patch. I see in your latest patch (remove_all_uxtheme.patch), the uxtheme related code is totally removed from C::B. Which is expected from my point of view, since wx3.1.1 has remove the uxtheme too.

    But my question is similar like Teodor Petrov said, I'm not sure there are some visual difference changes, since I'm not familar with the uxtheme related thing. I just read a webpage here: [url=https://msdn.microsoft.com/en-us/library/windows/desktop/hh270423(v=vs.85).aspx]Visual Styles Overview (Windows)[/url], but still don't know why we already have such uxtheme related code in C::B.

    In the patch, I see:

    @@ -114,17 +105,6 @@
         m_selection = -1;
         m_rowCount = 10;
         m_columnCount = 0;
    -
    -#if defined(__WXMSW__) && wxUSE_UXTHEME
    -    // If on Windows XP/Vista, use more appropriate colours.
    -    // Alatar: What for??? Why should we use fixed colours?
    -    if (wxUxThemeEngine::GetIfActive())
    -    {
    -        SetSelectionOutlineColour(wxColour(49, 106, 197));
    -        SetSelectionColour(wxColour(193,210, 238));
    -        SetSelectionTextColour(wxSystemSettings::GetColour(wxSYS_COLOUR_WINDOWTEXT));
    -    }
    -#endif
     }
    
     void wxSwitcherItems::Copy(const wxSwitcherItems& items)
    

    You see, the original commiter has already have the comments that why we need those code here.

    Thanks.

     
  • Miguel Gimenez

    Miguel Gimenez - 2018-02-28

    Probably the original commiter wanted to force selection-related colours so changing visual styles didn't mess them, due to ugly or unreadable combinations . I think Alatar is not the original commiter and he was wondering about this as we are doing now.

     
  • Teodor Petrov

    Teodor Petrov - 2018-03-15

    @ollydbg: Are you going to commit this?

     
    • ollydbg

      ollydbg - 2018-03-15

      I can't test this patch to see what is the visual difference with or without the patch for wx2.8.12 based C::B. For wx 3.x based C::B, I think this patch certainly fix the build error, and should be put in the trunk.

      What's your idea? We just commit it?

      BTW: Do we still need to maintain the wx2.8 related code for C::B, I think we should go directly to wx3.

       
      • Teodor Petrov

        Teodor Petrov - 2018-03-15

        Yes, we still maintain wx2.8.

         
  • Miguel Gimenez

    Miguel Gimenez - 2018-05-07

    killerbot fixed this issue in r11396, so this ticket can be closed.

     
  • ollydbg

    ollydbg - 2018-05-07

    Hi, Miguel Gimenez, killerbot just fix the build error when he built against wx 3.1.1, maybe, we still need your patch if we need to totally remove the uxtheme support.

     
  • Teodor Petrov

    Teodor Petrov - 2018-09-10

    Do we still need this patch/changes?

     

    Last edit: Teodor Petrov 2018-09-10
  • Teodor Petrov

    Teodor Petrov - 2020-12-24

    Do we still need this patch?

     
  • Miguel Gimenez

    Miguel Gimenez - 2020-12-24

    No

     
  • Teodor Petrov

    Teodor Petrov - 2020-12-24
    • status: open --> invalid
     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.