Author Topic: cbDebuggerPlugin?  (Read 5961 times)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
cbDebuggerPlugin?
« on: November 05, 2006, 04:25:47 am »
Hi again CBers.
I haven't given in on my quest to support interpreted languages. However, I've scaled things back a little and focusing on Python exclusively for now - more or less as a proof of concept, but it should offer pretty rich Python support by the time I'm done. I'm currently working on the debugger and thinking about subclassing from cbDebuggerPlugin. Without further ado, my questions:

1. Does a cbDebuggerPlugin object have the same lifecycle as a regular plugin? In particular, is it loaded at CB startup.
EDIT: yes -seems to be the case
2. Can there be more than one debugger plugin active in the environment? (I don't mean debugging simultaneously, just loaded into the environment)
EDIT: yes

Assuming 2,

3. How does CB know what debugger to pass messages to (i.e. how do I set the active debugger in CB?) (EDIT: it just passes message to all? Not sure about cbDebuggerPlugin::Debug)
4. Does each debugger share a common debugger menu, toolbar and controls or do they create their own instances of these?  (Presumably EDIT: SOME BUT NOT ALL are shared, although I have my own ideas about what a watch should look like - something like a "structured" rich edit control). If shared then the answer to 3 is critical.

I'm sure i'll discover the answers to these as I play with the code and examine the gdb plugin, but guidance will save me time and lead to a better product. If 2 is not true then I'll either have to do some truly horrible hacking or propose some sdk mods...

thanks
Damien
« Last Edit: November 05, 2006, 05:21:09 am by dmoore »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: cbDebuggerPlugin?
« Reply #1 on: November 05, 2006, 09:58:25 am »
1. cbDebuggerPlugin is an interface and it has no lifecycle. All (enabled) plugins are loaded on startup and unloaded on shutdown.
2. Sure.
3. C::B passes UI messages to all plugins.

To clear things up a little, C::B doesn't even know/care if a debugger plugin is loaded. If you want to create 10 debugger plugins, C::B will load them happily. If you want to make them share menus between them or each to his own, that's up to you.
AFAIR, the only place in the sdk where a debugger plugin is checked for existence, is in the editor code to notify the debugger about setting/unsetting breakpoints.
Be patient!
This bug will be fixed soon...

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: cbDebuggerPlugin?
« Reply #2 on: November 05, 2006, 10:30:11 am »
To clear things up a little, C::B doesn't even know/care if a debugger plugin is loaded. If you want to create 10 debugger plugins, C::B will load them happily. If you want to make them share menus between them or each to his own, that's up to you.

Thanks mandrav. This is the kind of insight that is very useful. I would hate to see the crazy mess that would result with 10 debugger plugins floating around. :) Is there a case for defining a project specific debugger so when a specific project is active so is the particular debugger? When a user switches projects with a new debugger CB could request that the debugger hide/release some/all of its UI, so it can be replaced with the UI of the alternate debugger. I guess this hasn't been an issue to date because the only current alternate debugger, CDB, is handled within GDBdebugger.

Quote
3. C::B passes UI messages to all plugins.

to test this i added a quick message box to report AddBreakpoint events hitting my plugin:

Code
virtual bool AddBreakpoint(const wxString& file, int line) {wxMessageBox(_T("Python Breakpoint!")); return true;}

unfortunately, these only seemed to make it when GDBdebugger was turned off. Does this mean:
A) CB passes messages to debuggers until the first true is returned?
B) CB passes messages only to the first debugger?

probably the former. if so, should GDBdebugger only be allowing breakpoints for its known filetypes or should the messaging be changed to send to all plugins regardless? probably better to send to all plugins (or the "active" plugin)

AFAIR, the only place in the sdk where a debugger plugin is checked for existence, is in the editor code to notify the debugger about setting/unsetting breakpoints.

with all the "virtuals" i wasn't sure which ones would get called by the framework. :D

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: cbDebuggerPlugin?
« Reply #3 on: November 05, 2006, 03:49:20 pm »
Quote
unfortunately, these only seemed to make it when GDBdebugger was turned off. Does this mean:
A) CB passes messages to debuggers until the first true is returned?
B) CB passes messages only to the first debugger?

probably the former.

It's (B). For no other reason than the fact that there exists only one debugger currently. This is subject to change though ;).
Be patient!
This bug will be fixed soon...

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: cbDebuggerPlugin?
« Reply #4 on: November 05, 2006, 04:05:33 pm »
I put up a patch to have CB message all debuggers. It does call GetOffers each time, but that could be changed to store a pointer to each debugger...

thanks
Damien
« Last Edit: November 05, 2006, 07:25:12 pm by dmoore »