Splitting debugger in two - specific debugger and common GUI

[Jenna]

This one should work, the only difference is, that it calls InitXRCStuff() also in batch-mode.
If that's really needed, it has to be done this way.

My worries are that the batch window might need the XRC stuff to be initialised (I am not sure about that) so it might have some side effects... (remember that you can enable plugins at will in batch mode) - I'll try though... If the XRC stuff is really not needed in batch mode (Yiannis?!) than it would actually be a good thing not to initialise it, as this safes time.

In former version InitXRCStuff() was not called in batch mode, now (we the new patch) it is, so we might get more overhead than needed.
Maybe it would be better to change the new code that leads to the crash in a matter, that it is not needed, but we should check how much time (and memory) it really uses and if it makes a measurable difference.

[oBFusCATed]

I doubt you'll see a difference, because the resource.zip file is loaded always in the CreateToolbars method.

[MortenMacFly]

Another thing I noticed while working on the 64 bit port of C::B:

You make heavy use of the stand-alone version of the wxPropGrid stuff. In fact, sooner or later it makes probably sense to use the wxPropGrid that ships with wx 2.9.x itself (as you'll need 2.9.x anyways for the compilation in 64 bit). I already did a lot of hacking to be compatible with both: the stand-alone and the wx integrated version. No I see a show-stopper which is the macro handling to register a wxPropGridEditor.

If you have time and nothing else to do ( ) you may want to try to compile against wx 2.9.x. While in trunk this works after a few work-arounds, the debugger branch fails, but only due to the Editor stuff... :-(

Just wanted to make your heads up what will be next the one or other day...

[oBFusCATed]

Vanilla stand alone wxPropGrid and the wxPropGrid in wx2.9 won't work, because I have made some changes.
Search for 'CB Begin' and 'CB end' comments in the source to see what have been changed.

Is it possible to use wx2.9+our version of wxPropGrid?

p.s. I was planning to submit some patches for wxPropGrid, but I postponed the task because of laziness...

[MortenMacFly]

Is it possible to use wx2.9+our version of wxPropGrid?

I think so, yes - but for distribution we need to do something like with wxScintilla and (more important) make sure the include folders are correct, thus what uses wxPropGrid searches first in the C::B SDK. The latter was the reason for me to use the WX version. A lot of C::B code would first include the wxPropGrid sources from WX.

[oBFusCATed]

I was planning to submit the patches to upstream, but I've not done so.
Also I'm not sure what is the status of wxpropgrid stand alone anymore, probably I should talk to wx people.

[oBFusCATed]

If you have time and nothing else to do ( ) you may want to try to compile against wx 2.9.x. While in trunk this works after a few work-arounds, the debugger branch fails, but only due to the Editor stuff... :-(

Patches? I've given it 15minutes to try to make it compile but the changes are too much for me.
Do you use the normal codeblocks.cbp file or you're using the -wx29.cbp file? I'm try to compile it on linux and there is no -wx29.cbp file.
Also I've tried to hack the includes, but it didn't work, because of the `wx-config`stuff - it always takes precedence.

[MortenMacFly]

Patches? I've given it 15minutes to try to make it compile but the changes are too much for me.
Do you use the normal codeblocks.cbp file or you're using the -wx29.cbp file? I'm try to compile it on linux and there is no -wx29.cbp file.

Too many of them and they are still WIP. I thought of creating another branch, so far I am using a heavily patched source tree with an own project file (the one with -wx29.cbp won't compile for 64 bit).
 

Also I've tried to hack the includes, but it didn't work, because of the `wx-config`stuff - it always takes precedence.

Well if should work if you play with the compiler/linker policies, even if you are using a script.

I don't know how we should handle it best... a 64 bit branch of the debugger branch / of trunk???

[oBFusCATed]

Too many of them and they are still WIP. I thought of creating another branch, so far I am using a heavily patched source tree with an own project file (the one with -wx29.cbp won't compile for 64 bit).

OK.
 

Well if should work if you play with the compiler/linker policies, even if you are using a script.

The problem is that the `wx-config --cflags` is in other compiler settings and they are always used before the include search paths.

I don't know how we should handle it best... a 64 bit branch of the debugger branch / of trunk???

Please don't do a branch of the branch, it will be a nightmare...
The best thing you can do is to fix trunk and then I'll try to fix the branch.
Maybe you can commit in trunk directly, so more people could test your changes.

[MortenMacFly]

Also I'm not sure what is the status of wxpropgrid stand alone anymore, probably I should talk to wx people.

According to this:

http://sourceforge.net/projects/wxpropgrid/forums/forum/452254/topic/3959996

It seems the best way is to make use of the wx integrated version of wxPropGrid on the long run. Also, according to the SVN logs there seems not much active development on the stand-alone version of wxPropGrid recently.

Maybe you can contact the author of that component asking what to do best. I did a lot ugly #if wxCHECK_VERSION(2, 9, 0), but finally the wxPGRegisterEditorClass macro breaks it completely. I don't see a good way to overcome this. If you want to try, I can provide you with the wx 2.9.x project file I have / use which does not use the 64 bit compiler (I have three: one for wx 2.9.x/32 bit; one for wx 2.9.x/64 bit... and the "legacy" for wx 2.8.x/32 bit).

[oBFusCATed]

Don't worry for the editor staff, I think I've fixed it.
Testing it on wx2.9 crashes cb, when adding a watch and I don't have debug version of wx2.9, so I cannot test it much.
But I'll check if wx2.8 still works correctly and I'll commit.
Or if you prefer I can give you a patch to test it.

[oBFusCATed]

Here is the patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/cb_dbg_wx29.patch

Please test it on windows and tell me if it compiles and hopefully runs correctly.

[oBFusCATed]

Morten:
Are you sure commit r7651 is OK?
I don't think this commit was needed in trunk, because the index is correctly set there.
Probably you wanted to backport the stepinto bug fixed in r7638? (http://svn.berlios.de/wsvn/codeblocks?op=comp&compare[]=%2F@7637&compare[]=%2F@7638)

[MortenMacFly]

Probably you wanted to backport the stepinto bug fixed in r7638? (http://svn.berlios.de/wsvn/codeblocks?op=comp&compare[]=%2F@7637&compare[]=%2F@7638)

Yes, that's what I had in mind... did I pick the wrong one??? (Reverting now...)

[oBFusCATed]

You can commit the other it is one liner