wxWidgets Discussion Forum

Hello,
I installed wxWidgets 3.0.4 with code:blocks 17.12 TDM-GCC-64 on Win7.0.
I generated a default gui wxWidgets application using the code:blocks wxWidgets wizzard.
Compiling generates 50+ depreicated warnings ?
Do I have to take these warning serious or just kick them out disabling the depreciated warnings warning altogether?

Best Regards,
Johi.

PS: warnings = see attachements.

If you wish your code to work with wxWidgets 3.2 and above you need to take them seriously.
Note: wxWidgets 3.2 does not exist at this time.

Tim S.

Those are harmless warnings.

Anyhow, if you want to get rid of them, then choose a more recent compiler. You need GCC > 5.3. TDM is, by now, 5.1

Hello, @Manolo,
Thank you for your answer.
So the only way to get rid of these pages of warning is to go to another compiler, there is no switch within WxWidgets or GCC do disable these warnings?
I am used to Microsoft compilers and there #pragma is used to disable warnings but it seems TDM-GCC is unable to do something like this.
Can you avise a flavor/version of GCC to use? I have been using VC2008/MFC for many years and I must say that GCC combined with Code:Blocks & wxWidgets requires much more expertise than the VC/MFC(wx) road. But as VC does not support wxSmith, i have no other option than to try to figure out the details.

Best Regards,
Johi.

There are two main "adaptions" of GCC for Windows: MinGW and Mingw-64, the latter was a fork from the former. They have different web sites. Both use GCC 8.
Up today, Mingw is only capable of build 32 bits binaries (they are working on a 64 bits version), while mingw-64 is 32/64 capable (look for -m32 and -m64 compiler flags).
There are some small differences in the way they "adapt" and the use of some Windows controls. Choose the one you like.

A side note: C::B is able to have several compilers at once. This allows to have different configurations ("targets" in C::B parlance) so you can use a compiler associated for a target. It's a bit tricky to set it right for newbabies, but you may experiment.

Hi,
Why not use a familiar IDE (MSVC), and use C::B just to design the GUI (i.e. wxSmith part).
Or even better - write a GUI code by hand and forget about C::B.

Thank you.

Hello @Manolo, Hello @Oneeyeman.
Thank you for your answer. In fact I already have code:blocks operational with VC & GCC compilers, I am using both on my machines. The major problem I ran into with the Microsoft compiler is that the debugger one needs to use (cdb) does not come via VC2008 pro. (i have an official license) but via platform SDK. And installing platform SDK requires .net framework x and .net framework x install fails because there is already a more recent framework installed on my machine.
Regarding the newbie aspect: What caused me multiple days of time loss with code:blocks is what I perceive as the moderate quality of the code:blocks wxWidgets project wizard: it seems O.K. but it has 50% chance or even 75% chance to fail and it caused me many days of time loss.
In fact the wizard shows the option to leave out Unicode. But then you see that you will not get your application compiled because setup.h defines Unicode=1 even if one selects no Unicode case. Then one reads that Unicode was practically abandoned some time ago. But the it would be wise to remove it from the wizard anyway. Possibly the same story with "Monolythic"; whatever I try, whatever documentation I follow, even if I succeed in compiling the Monolythic lib (with regular MinGW they compile, with TDM they do not on my machine), The Code:Blocks wizard does not recognize the generated libs. (so this factor, combined with Unicode, has 75% chance of failure for the wizard in my case). You have to know that monolythic compiles are presented as preferred in order to have no library issues.
As for the future strategy: It will indeed be a double one because until now code:blocks with wxSmith is really impressive but, as far as I can see, the VC2008 debugger for the moment seems superior under windows.
I remain with a question regarding the future potential of wxWidgets related to the warning list.
In fact I am a newbie, but with more than 20 years of experience in the industry sometimes one sees things other people see later.
What is the issue: a minor application (hello world GUI) generates a very high list of "deprecated" warnings. In other experiences I had, this was the sign that the development team was about to go for a new strategy with a lot unintentional compatibility breaks with the past. On several instances what was sold as a step forward, it ended up to be a step forward right in the ditch. Many good products got lost this way. One has the risk of examples, documentation, and simple software stability that goes away.
So my question is: what might be the intention of the core team in this regard? Are we going the .Net-MFC / Java (AWT - Swing) way or will compatibility & of course return on time invested be OK? We must not forget that the concept & the track record of wxWidgets is really amazing.
Best Regards,
Johi.

Both wxWidgets and C::B try to keep old environment (compiler and wx versions, and MSW / GTK olds too). This means some sort of surprises, as the warnings you get, or some controls having different behaviour in different MSW versions. Normally you can develop e.g. for Win7 and everything goes "well" in Win10; the opposite is not always true.

Then one reads that Unicode was practically abandoned some time ago

What? Unicode-mode is default in wxWidgets since long time ago. You must force a ASCII-mode at wx building if you want that. I'm not sure if you refer to CB's wizard, which would follow the same criteria.

You have to know that monolythic compiles are presented as preferred in order to have no library issues.

Yes, TDM has problems in building the monolithic lib. But, why don't prefer the several-libs version? This is common in Linux; and on MSW it may be better to use static libs (which get incorporated into your .exe) instead od dynamic ones.

the VC2008 debugger for the moment seems superior under windows.

This a long record that GDB cannot defeat by now. On the other hand, I can live with GDB skills.

this was the sign that the development team was about to go for a new strategy with a lot unintentional compatibility breaks with the past

.
Definitively not the case for wx nor CB. They do their best for new versions still work with old OSs/machines (about 2005), except for OSX where typical user wants the brand new of everything.

I don't use CB wizards nor wxSmith. This is just a tiny part of the total amount of time in a project. I prefer to have some project, use it as a template, and change current wx libs.
If you want to try my way, I can post some instructions. But the best is to read CB docs and ask in its own forum.

Hi,

JOHI wrote: ↑Fri May 31, 2019 6:05 am Hello @Manolo, Hello @Oneeyeman.
Thank you for your answer. In fact I already have code:blocks operational with VC & GCC compilers, I am using both on my machines. The major problem I ran into with the Microsoft compiler is that the debugger one needs to use (cdb) does not come via VC2008 pro. (i have an official license) but via platform SDK. And installing platform SDK requires .net framework x and .net framework x install fails because there is already a more recent framework installed on my machine.

I am not sure what you are talking about. MSVC does have an official debugger integrated inside the IDE. It may be tricky to pull it into the C::B, but if you start MSVC and try to debug the binary it will just work. Does it not for you?

JOHI wrote: ↑Fri May 31, 2019 6:05 am Regarding the newbie aspect: What caused me multiple days of time loss with code:blocks is what I perceive as the moderate quality of the code:blocks wxWidgets project wizard: it seems O.K. but it has 50% chance or even 75% chance to fail and it caused me many days of time loss.
In fact the wizard shows the option to leave out Unicode. But then you see that you will not get your application compiled because setup.h defines Unicode=1 even if one selects no Unicode case. Then one reads that Unicode was practically abandoned some time ago. But the it would be wise to remove it from the wizard anyway.

First what you absolutely need to understand is that whatever options you compiled wxWidgets, you absolutely have to use the exactly the same options compiling your own code. This is essential - otherwise you will have a lot of build/link/runtime issues, as you already discovered.
Second, UNICODE option (not Unicode one), is on by default since wx 3.0. Prior to that the library was supporting 2 types of builds - UNICODE and ANSI. Right now with wx3.0+ you need to explicitly turn off UNICODE in order to get the ANSI build. But then - why would you do that? Especially since we live in XXI century where we have an emoji, multi-lingual applications and inter-language applications. Unfortunately C::B does not know what options you used when compiling wxWidgets ( ), and so the options to turn on/off UNICODE is still there as the ANSI build is deprecated (not abandoned).
Granted the default setting in the wizard should probebly be UNICODE=on, especially for the new version, but it is and was off for a long time. Yui can try to complain to C::B people about that.

JOHI wrote: ↑Fri May 31, 2019 6:05 am Possibly the same story with "Monolythic"; whatever I try, whatever documentation I follow, even if I succeed in compiling the Monolythic lib (with regular MinGW they compile, with TDM they do not on my machine), The Code:Blocks wizard does not recognize the generated libs. (so this factor, combined with Unicode, has 75% chance of failure for the wizard in my case). You have to know that monolythic compiles are presented as preferred in order to have no library issues.

Monolithic build(s) are not preferred. In fact this build is very rarely tested by the core-devs and it strongly discouraged as it might give you some issues in the long run.
The most preferred and so-called "default" way of building is to use MONOLITHIC=0.
You don't gain anything by using monolithic build at all - just more headache.

JOHI wrote: ↑Fri May 31, 2019 6:05 am As for the future strategy: It will indeed be a double one because until now code:blocks with wxSmith is really impressive but, as far as I can see, the VC2008 debugger for the moment seems superior under windows.
I remain with a question regarding the future potential of wxWidgets related to the warning list.

Now about the warnings: they are just that - warnings. You can look at them and submit a (tested) patch to trac/PR on github fixing them. After all this is an open-source project. Or you can send an e-mail to wx-dev ML about this list attaching it for reference and mentioning you complete environment - GCC/MinGW version, Windows version, wx version and ALL settings you tried to compiple the library with. Remember - this is a user forum, created by users and used by users. Core developers almost never visit.

JOHI wrote: ↑Fri May 31, 2019 6:05 am In fact I am a newbie, but with more than 20 years of experience in the industry sometimes one sees things other people see later.
What is the issue: a minor application (hello world GUI) generates a very high list of "deprecated" warnings. In other experiences I had, this was the sign that the development team was about to go for a new strategy with a lot unintentional compatibility breaks with the past. On several instances what was sold as a step forward, it ended up to be a step forward right in the ditch. Many good products got lost this way. One has the risk of examples, documentation, and simple software stability that goes away.
So my question is: what might be the intention of the core team in this regard? Are we going the .Net-MFC / Java (AWT - Swing) way or will compatibility & of course return on time invested be OK? We must not forget that the concept & the track record of wxWidgets is really amazing.
Best Regards,
Johi.

No, the compatibility will definitely be preserved.
Now, read my reply to you, try to build wxWidgets properly, an "official" way, recreate the C::B project and rebuild the application.
I'm curious - how many warnings you will receive at that time.

Thank you.

ONEEYEMAN wrote: ↑Fri May 31, 2019 2:32 pm by ONEEYEMAN » Fri May 31, 2019 4:32 pm
Hi,

JOHI wrote: ↑
Fri May 31, 2019 8:05 am
Hello @Manolo, Hello @Oneeyeman.
Thank you for your answer. In fact I already have code:blocks operational with VC & GCC compilers, I am using both on my machines. The major problem I ran into with the Microsoft compiler is that the debugger one needs to use (cdb) does not come via VC2008 pro. (i have an official license) but via platform SDK. And installing platform SDK requires .net framework x and .net framework x install fails because there is already a more recent framework installed on my machine.

I am not sure what you are talking about. MSVC does have an official debugger integrated inside the IDE. It may be tricky to pull it into the C::B, but if you start MSVC and try to debug the binary it will just work. Does it not for you?

I am talking about the VC2008 debugger, it works perfectly.

ONEEYEMAN wrote: ↑Fri May 31, 2019 2:32 pm Granted the default setting in the wizard should probebly be UNICODE=on, especially for the new version, but it is and was off for a long time. Yui can try to complain to C::B people about that.

True, i might consider to do this. It is a pitfall that could block new users not aware of what is going on.

ONEEYEMAN wrote: ↑Fri May 31, 2019 2:32 pm Monolithic build(s) are not preferred. In fact this build is very rarely tested by the core-devs and it strongly discouraged as it might give you some issues in the long run.
The most preferred and so-called "default" way of building is to use MONOLITHIC=0.
You don't gain anything by using monolithic build at all - just more headache.

Same remark as above: the option in the wizzard can put new users on the wrong leg, so it would be better if it went away or was available version of wx releated or removed completely.

ONEEYEMAN wrote: ↑Fri May 31, 2019 2:32 pm No, the compatibility will definitely be preserved.
Now, read my reply to you, try to build wxWidgets properly, an "official" way, recreate the C::B project and rebuild the application.
I'm curious - how many warnings you will receive at that time.

I do not understand you definiton of "properly". c:\wxWidgets-3.0.4\build\msw>mingw32-make -f makefile.gcc SHARED=1 UNICODE=1 BUILD=debug that's more or less what is to it. This runs ok; the "gcc_mswuddll" directory is generated.
I select the related setting in the code:blocks wxWidgets wizzard with a new hello world gui application and the number of warnings is exactly 177 under gcc 5.1.0 (tdm-1). The application i am working on has some more lines of code and generates 885 warnings for the moment. Practically all of them related to depreciated functions. This kind of behaviour is not productive at all. If I compile my application in the VC2008 IDE, activating "_CRT_SECURE_NO_WARNINGS_" i get none (this to remove warnings related to size checking in string functions). So I am really curious how to make sure Code:Blocks with gcc can do someting similar. Of course you can say, stick with Microsoft, but my current GCC compiler should be able to do something similar (GCC reputation is solid).

@Manolo,
Also thank you for your comments, I think what is mentioned above is also a reply to your point of view.

Best Regards,
Johi.

A small hack that I used with TDM GCC 5.1:

Edit include/wx/window.h, about line 1700, add the #if block: and build wxWidgets again.

You may need some more hacks like that one.

Hello Manolo,
Sorry for the late reply.
As VC2008 debugger is for me a lot more convenient compared to CodeBlocks/Gcc i sticked to VC2008 and used CodeBlocks for the resources part.
But indeed, for sure your solution would work.
I might even need a similar solution for the fact that wxDatagramsocket seems to have a bug (at first sight) that is not there in Winsock.
Best regards
Johi.