Building Code::Blocks on Win 64

[MortenMacFly]

And if you want to maintain compatibility with wx-2.8.x, you should keep cbIntPtr in the code.

No, in recent wx2.8 wxIntPtr is defined correctly (see wx/defs.h) - so its no longer a wx2.9.x thing. So you are more safe if you use wxIntPtr meanwhile... that was my point.

[stahta01]

And if you want to maintain compatibility with wx-2.8.x, you should keep cbIntPtr in the code.

No, in recent wx2.8 wxIntPtr is defined correctly (see wx/defs.h) - so its no longer a wx2.9.x thing. So you are more safe if you use wxIntPtr meanwhile... that was my point.

Where is it Documented as being in 2.8; I ask because I tried your argument with using wx_str() and it failed even though it has been in every 2.8 release I checked (checked about 4 releases).

Tim S.

[Biplab]

And if you want to maintain compatibility with wx-2.8.x, you should keep cbIntPtr in the code.

No, in recent wx2.8 wxIntPtr is defined correctly (see wx/defs.h) - so its no longer a wx2.9.x thing. So you are more safe if you use wxIntPtr meanwhile... that was my point.

My point is to keep things simple. wx-2.8 api is well established. wx-2.9 api is meant for wx-3.0. It may change over time until wx-3.0 is released. Till then I'd use wx-2.8 & wx-2.9 api separately wherever possible.

A couple of #ifdef s here and there wouldn't make any difference to the binary. It's trivial to remove them when we want to drop support of wx-2.8.

If we keep following bleeding edge wx-trunk, we may end up breaking Linux/Mac builds. If I'm not wrong, there are distros which come with older wx packages.

[MortenMacFly]

My point is to keep things simple. wx-2.8 api is well established. wx-2.9 api is meant for wx-3.0. It may change over time until wx-3.0 is released. Till then I'd use wx-2.8 & wx-2.9 api separately wherever possible.

Full agreed.

If we keep following bleeding edge wx-trunk, we may end up breaking Linux/Mac builds. If I'm not wrong, there are distros which come with older wx packages.

Most likely I simply don't get it, but why defining an own type (cbIntPtr) if there is a type in both: wx2.8 and wx2.9 that works?

Where is it Documented as being in 2.8; I ask because I tried your argument with using wx_str() and it failed even though it has been in every 2.8 release I checked (checked about 4 releases).

Its not, I believe its not even documented in wx29... ;-) I just checked, it was introduced by JS himself in r66923, currently they are at r70626. However, I don't get what you mean with wx_str()? We are talking about {cb/wx}IntPtr here.

[stahta01]

Its not, I believe its not even documented in wx29... ;-) I just checked, it was introduced by JS himself in r66923, currently they are at r70626. However, I don't get what you mean with wx_str()? We are talking about {cb/wx}IntPtr here.

I was just showing the example where I was told you could NOT use a 2.9 feature in 2.8 till it is documented in 2.8; This is even true when the feature existed in both 2.6 and 2.8. There is about 100 #ifdef that are not needed in Code::Blocks because of the c_str/wx_str functions where in 2.8 wx_str is defined the same as c_str but I could not use it because it was not documented.

Tim S.

[MortenMacFly]

There is about 100 #ifdef that are not needed in Code::Blocks because of the c_str/wx_str functions where in 2.8 wx_str is defined the same as c_str but I could not use it because it was not documented.

I agree on probably not using methods / classes that are back-ported from wx2.9.x and are either not documented or encapsulated in a special "#if wxABI_VERSION >= 208XX". But this specific function is there for ages and works. In addition it does exactly the same as the 5-liner "#ifdef" in Code::Blocks. Maybe I am missing something but honestly I don't see a reason not to use it. Did I told you so?

Code

    // identical to c_str(), for wxWin 1.6x compatibility
    const wxChar* wx_str()  const { return c_str(); }

[stahta01]

Did I told you so?

I do NOT think that you were the one who said no to it. But, one of the CB Dev team did.

I just added all the #if guards because I wanted to get the original 2.9 patch(s) applied.

I planned to submit a patch removing the #if 2.9 when wxWidgets 3.0 is released.

Tim S.

 

[MortenMacFly]

This should be fixed in actual trunk and will surely make it in Biplab's win64-build.
It also occurs on linux 64-bit with wx2.9 if debug-messages are on.

BTW: What drives me nuts are these warnings:

Code

../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist

Did anyone already figured out a good way how to catch them? They occur in every call to updateui, so very often and the debugger gets crazy after a while...

[Jenna]

This should be fixed in actual trunk and will surely make it in Biplab's win64-build.
It also occurs on linux 64-bit with wx2.9 if debug-messages are on.

BTW: What drives me nuts are these warnings:

Code

../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist

Did anyone already figured out a good way how to catch them? They occur in every call to updateui, so very often and the debugger gets crazy after a while...

I don't get them on linux.
I will try on win7, nbut I do not have a 64bit build of wx at the moment.
But I will see if I get them here also.

[MortenMacFly]

I will try on win7, nbut I do not have a 64bit build of wx at the moment.

Its not 64 bit related, but wx2.9.x and they come from OnSearchMenuUpdateUI btw...

[MortenMacFly]

Its not 64 bit related, but wx2.9.x and they come from OnSearchMenuUpdateUI btw...

...what might be related and what is not clear to me:
We load the menu like this:

Code

    wxXmlResource *myres = wxXmlResource::Get();
    myres->Load(resPath + _T("/resources.zip#zip:main_menu.xrc"));

...but the toolbar like this:

Code

    wxXmlResource *myres = wxXmlResource::Get();
    myres->Load(resPath + _T("/resources.zip#zip:*.xrc"));

Notice the *.xrc for the toolbar. Why? This cannot be any good...

[MortenMacFly]

Notice the *.xrc for the toolbar. Why? This cannot be any good...

...and another one: Dos anybody know why we don't use the Manager function to load the menubar and toolbar from the XRC files anymore?

[Jenna]

This should be fixed in actual trunk and will surely make it in Biplab's win64-build.
It also occurs on linux 64-bit with wx2.9 if debug-messages are on.

BTW: What drives me nuts are these warnings:

Code

../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist

Did anyone already figured out a good way how to catch them? They occur in every call to updateui, so very often and the debugger gets crazy after a while...

This should be fixed in r7929, at least for the OnUpdateUI-stuff, but there are of course more issues, that have been hidden in wx2.8 .