Splitting debugger in two - specific debugger and common GUI

[MortenMacFly]

Feature wish:
I have 2 debugger configurations: One for 32 bit and one for 64 bit. Switching between those would be easier if the toolbar would offer a drop-down box to select the currently active config on-the-fly if.

For now, I always need to enter the debugger settings, even though I have two targets (32 bit and 64 bit) in one project.

[oBFusCATed]

Why don't you set the correct debugger config in the toolchain executables for your 32bit and 64bit compilers and then use Debug->Active debuggers->Target's default?

Do you know that you can have multiple configs for one debugger plugin and you can switch them in Debug->Active debuggers?

[MortenMacFly]

Do you know that you can have multiple configs for one debugger plugin and you can switch them in Debug->Active debuggers?

No.

Why don't you set the correct debugger config in the toolchain executables for your 32bit and 64bit compilers and then use Debug->Active debuggers->Target's default?

Where do I set the preferred debugger for a target?

[oBFusCATed]

In the Settings -> Compiler -> Toolchain executable -> Debugger

[MortenMacFly]

In the Settings -> Compiler -> Toolchain executable -> Debugger

Yes, I know that. But this is global and not per-target. I guess I mis-understood.

But the option from the menu is just fine...

[oBFusCATed]

If you have two different compiler for two different targets it will use the appropriate debugger configuration.

Probably we can add some options for this per target, but I'm not sure what is needed, so you can help me in this regard

[MortenMacFly]

Probably we can add some options for this per target, but I'm not sure what is needed, so you can help me in this regard

I don't think so...

But the option from the menu is just fine...

[Jenna]

The branch crashes for me in batchbuild mode (on Linux and Windows).
When trying to create m_disassemblyDialog from inside  DebuggerManager::SetInterfaceFactory wxScintilla stops with "Could not create a new wxControl instance.".

Too late to dig into it later at the moment.

[oBFusCATed]

Yes, we discussed it before and there was no approved solution.

[Jenna]

Yes, we discussed it before and there was no approved solution.

Do we really need to initialize debugging-stuff in batchbuild mode ?

[oBFusCATed]

The thing is that the code assumes that the debugging windows are correctly created and never checks for null pointers.
I can add the checks but I prefer not to do so.

[MortenMacFly]

I've merged the debugger branch with trunk and adjusted a few more wx 2.9.x compatibility things. Feel free to compile the C::B core of the branch using the project file "CodeBlocks_wx29.cbp" and "update29.bat" (also in SVN).

The same applies to trunk for those who want to try wx 2.9.x progress.

BTW: If you are compiling wx 2.9.x, make sure to switch off "WXWIN_COMPATIBILITY_2_6" and "WXWIN_COMPATIBILITY_2_8" when compiling wxWidgets 2.9.x from sources.

[oBFusCATed]

Morten:
"#define wxPG_COMPATIBILITY_1_2_0 0" breaks the build of wxsmith.
When committing please ensure that the contrib plugins build, too, because I'm using the branch as my main install!
Also this change should have been made in trunk, not in the branch!

[MortenMacFly]

"#define wxPG_COMPATIBILITY_1_2_0 0" breaks the build of wxsmith.

Not for me... I'll try though...

Also this change should have been made in trunk, not in the branch!

Why? wxPropGrid is already modified by you in the branch and differs therefore from trunk IMHO... I maybe wrong though...

[oBFusCATed]

Not for me... I'll try though...

There is a missing wxIsIdOk or something like that when the compatibility is off.

Why? wxPropGrid is already modified by you in the branch and differs therefore from trunk IMHO... I maybe wrong though...

Because this helps porting the code using wxpropgrid to wx2.9 a lot, and so commits changing wxsmith will fail to compile early if this change is in trunk.