Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Building Code::Blocks w/ wxWidgets 3.1.1 and MINGW-W64 over Windows 10

(1/2) > >>

PaliPalo:
Hello,

Not knowing where is the best place to post it, I did it here. (I know that partially concerns wxWidgets but I did not receive my wxWidgets account validation mail yet; so I post it here too)

The dev env I used:

1) MingW-W64 4.3.0 with gcc 6.3.0 and make 4.1
2) Code::Blocks version 16.01 from SVN repository (svn checkout https://svn.code.sf.net/p/codeblocks/code/trunk codeblocks-code)
3) wxWidgets 3.1.1 is the master branch of the git repo (git clone https://github.com/wxWidgets/wxWidgets.git)

wxWidgets was compiled with BUILD=debug and SHARED=1, NO monolithic. (then customized *31_64.cbp files for Code::Blocks + some other tuning to match my wxWidgets build)

First trouble occurs when I update the Code::Blocks repository from SVN. It seems that FortranProject has been updated. Indeed, parserf.cpp no more compiles correctlly; it complains that wxRE_ADVANCED, wxRE_ICASE and wxRE_NOSUB are not declared. To correct this I added #include <wx/regex.h>

Then, wxWidgets and Code::Blocks compiled correctly. But, when starting it, it fails after load. I can see the workspace but the application does not respond a while. After a moment, it crashes. After some attempts, I finally get it running by disabling the splashscreen with the adequate command line option.

Why does the app stopped working with the splashscreen ? I made some debug sessions to investigate. It results that MySpellingDialog.cpp use a wxTextCtrl with wxTE_RICH2 attributes. By removing this wxTE_RICH2, Code::Blocks does not hang anymore. OK, but that option is merely needed... I guess... So I reset it and look where the application received a SIGSEGV. To be brief, it seems that wxWidgets missed to test the fact that the wxTextCtrl is a rich edit with drag and drop enable when a non owned window is destroyed. Indeed I think the base class of wxTextCtrl is used (i.e. wxWindow) for the object dtor.

To palliate this problem, I modified src/msw/textctrl.cpp in wxWidgets by first defining the wxRICHTEXT_DEFAULT_DROPTARGET like this:


--- Code: ---#if wxUSE_DRAG_AND_DROP && wxUSE_RICHEDIT

// dummy value used for m_dropTarget, different from any valid pointer value
// (which are all even under Windows) and NULL
static wxDropTarget *
    wxRICHTEXT_DEFAULT_DROPTARGET = reinterpret_cast<wxDropTarget *>(1);

#endif // wxUSE_DRAG_AND_DROP && wxUSE_RICHEDIT

--- End code ---

and secondly update the wxWindowMSW::HandleDestroy to take this richedit fact like this


--- Code: ---bool wxWindowMSW::HandleDestroy()
{
    // delete our drop target if we've got one
#if wxUSE_DRAG_AND_DROP
    if ( m_dropTarget != NULL
#if wxUSE_RICHEDIT
&& m_dropTarget != wxRICHTEXT_DEFAULT_DROPTARGET
#endif
)
    {
        m_dropTarget->Revoke(m_hWnd);

        wxDELETE(m_dropTarget);
    }
#endif // wxUSE_DRAG_AND_DROP

    // WM_DESTROY handled
    return true;
}

--- End code ---

I do not know really know if this is the correct way but it works... at least for now. As I said: maybe this could help.

For the history, I mainly aim to be able to swap internal softwares from Windows to other OS if we plan to change it in the future. I try then to have a complete set of dev tools which I build and control myself (foolish, you said ? I totally agreed). Then I finally opted to use wxWidgets as GUI library (and wxFormBuilder). So, I wanted to used a cross-platform IDE that is based on wxWidgets too. I then chose Code:Blocks. All of them should run on a 64 bits architecture.

stahta01:
Looks like you do NOT need any help.

But, I do wish to warn you that wxWidgets 3.1 is a development build; the newest production build is version 3.0.3.

The next production series will be 3.2 based version that is normally based on the final 3.1 development build.

FYI: The CB Dev Team; seems to like patch files more than code snippets.

Tim S.

stahta01:
If you are using the CB wxWidgets wizard to start your wxFormBuilder CB projects. In the past, I tried to update that part of the CB Wizard. If you want, I will try to update that part of the Wizard once more. I really need someone to test the wxFormBuilder section of the CB wxWidgets wizard.

Tim S.

PaliPalo:
Thanks for reply

Indeed, yes, I do not need help here. But one day, I will search help and I would like then to find solution on the web. That's the main reason of my demarche. I have pleasure to help as I can.

The reason why I wrote a code snippet here is that I do not yet have a complete and efficient understanding of the svn and/or git process. In the past year, I handled a private tools for code versionning. And since I change my job 8 years ago, I do not more work in team, so the new tools are really new to me. Plus, I have a risk minded personnality. That means I prefer post the solution immediatly because... hey, what could happen to me tomorrow?

Concerning, your proposal about wizard, I think I may help later. For the moment, I have largely encompassed wxWidgets library but I have not yet a comfortable understanding. My next step is to build customized wxWidgets components that I will plug into wxFormBuilder (indeed, I started this yet). Those will be a wxWidgets implementation of some components that I developped internally inside VisualStudio. I hope I could make them better. So, once I will be sufficiently capable with wxFormBuilder, I could imagine to be of some help with the wizard. I guess that I have to know further about CodeBlocks plugins, etc. But this is not impossible.

Anyway, I think I will have a look at this soon. As I know myself to be hungry about that subject. But I haved to mess with my family life.

Krice:
Sometimes I'm wondering how do developers compile these projects if it's so difficult to even build them in the first place.

Navigation

[0] Message Index

[#] Next page

Go to full version