Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Contributions to C::B => Topic started by: gd_on on March 23, 2020, 02:14:58 pm

Title: svn 11991
Post by: gd_on on March 23, 2020, 02:14:58 pm
I know that you don't like #if ... #else ... #endif
but to avoid conflicts in svn update, and as suggested Miguel Gimenez in http://forums.codeblocks.org/index.php/topic,23687.msg161404.html#msg161404 there is Update() to do the job (in main.cpp).
It's possible to use something like :
Code
#if wxCHECK_VERSION(3, 1, 4)
        Update();
#else
        wxPaintEvent e;
        ProcessEvent(e);
#endif // wxCHECK_VERSION
in main.cpp
and :
Code
#if wxCHECK_VERSION(3, 1, 4)
    wxPGWindowList const list(NULL);
#else
    wxPGWindowList const list;
#endif // wxCHECK_VERSION
        return list;
in watchesdlg.cpp.

Note that Update() works also with wxWidgets 3.1.3.
Title: Re: svn 11991
Post by: oBFusCATed on March 23, 2020, 06:22:27 pm
Do you have compiler failures or some other actual problem? This code builds fine with 2.8 and 3.0.
I don't see a reason why we would need to call an Update or paint event here. Any problems when dragging files?
Title: Re: svn 11991
Post by: gd_on on March 23, 2020, 07:03:39 pm
I had the same sequence of code in one of my own wxWidgets software. It was necessary because without this code, my window refresh was not correct. I have replaced these 2 lines by a simple Update() in my code and it works with both wxWidgets 3.1.3 and 3.1.4. It's the reason why I have done the same replacement in C::B.
But may be, C::B has not such problem.
The problem came when in C::B, I updated through svn which declared 2 svn conflicts that I had to solve manually.
Title: Re: svn 11991
Post by: oBFusCATed on March 23, 2020, 11:34:07 pm
OS, steps to reproduce?
Title: Re: svn 11991
Post by: gd_on on March 24, 2020, 10:15:50 am
OS : as told in my signature, it is Windows 10 (updated), family version.
Steps to reproduce :
modify as indicated above a previous version of main.cpp and watchesdlg. Probably take care of the date to be sure it will be considered as an "old" version by the next update process.
Update through svn.
Two conflicts in main and watchesdlg.

Title: Re: svn 11991
Post by: stahta01 on March 24, 2020, 11:14:01 am
Do you have compiler failures or some other actual problem? This code builds fine with 2.8 and 3.0.
I don't see a reason why we would need to call an Update or paint event here. Any problems when dragging files?

The code fails to build with wxWidgets git master; this counts as 3.1.4!
Builds OK with wxWidgets 3.1.3 release.

Tim S.
Title: Re: svn 11991
Post by: oBFusCATed on March 24, 2020, 06:55:29 pm
gd_on: I don't care for your conflicts, you've made modifications you'll have to decide what to do with them. For me the code builds fine in wx-master, wx2.8 and wx3.0 travis builds. The only thing I care about this change is if the removal of the forced repaint causes problems when dropping files in C::B. Can you make it fail like in your application? I've tested on linux and it works fine.

stahta01: Build log? You're always requesting build logs in the topics, but you don't provide one when you report something.

Link to travis https://travis-ci.org/github/obfuscated/codeblocks_sf/builds if you don't believe me.
Title: Re: svn 11991
Post by: gd_on on March 24, 2020, 07:18:30 pm
I have not found problems within C::B (until now) with your modifications.
My intention was just to remember you that Miguel Gimenez had identified the problem some time ago. In my C::B version, I tried to solve the problem by simply adding #if ... #else... #endif. Like that, I'm (almost) sure that the binary code is the same as previously for wx 3.1.3 and specifically adapted for wx 3.1.4 and +.
I don't know why this paint event has been added. Is it useful or not, I don't know. May be only the original author can say why he added this event.
If it works without any problem, of course the code can (and must) stay like that.

gd_on

PS : difficult for me to try to make a fail as in my application : context is totally different (I work within a wxsglcanvas window !)
Title: Re: svn 11991
Post by: stahta01 on March 24, 2020, 07:27:23 pm
Full build log would be rather large; will post the snipped build log once build is done.

Edit: It would have been nice if you told me you fixed it in r11991!!!!

Tim S.
 
Title: Re: svn 11991
Post by: oBFusCATed on March 24, 2020, 09:30:35 pm
@stahta01: The whole topic is all about rev11991 and that I've fixed this in a different way then the proposed solutions in the other topic.
Title: Re: svn 11991
Post by: MortenMacFly on March 29, 2020, 04:58:34 pm


Link to travis https://travis-ci.org/github/obfuscated/codeblocks_sf/builds if you don't believe me.

Cool stuff. Thats what I meant with CI/auto build for distros. Btw: the branch is renamed, you'll probably need to adopt.
Title: Re: svn 11991
Post by: oBFusCATed on March 29, 2020, 05:18:02 pm
Travis doesn't easily give you final builds... and it also builds only on some version of ubuntu (14.xx at the moment I think).