Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

debugging plugin

<< < (2/3) > >>

DoMeN:
Btw does annione know which part of the code sets the color of breakpoints to red ?

dje:
Hi !!

codeblocks/sdk/cbeditor.cpp in void cbEditor::InternalSetEditorStyleBeforeFileOpen(cbStyledTextCtrl* control)


--- Code: ---control->MarkerSetBackground(BREAKPOINT_MARKER, wxColour(0xFF, 0x00, 0x00));
--- End code ---

Dje

DoMeN:
I have a question for the C::B dev team.
thomas told me the reasons why you don't want to add hardware breakpoint support in the main release but why wouldn't it be acceptable to have a text box to write how manny HW breakpoints are supported on the platform you are debugging and a check box to indicate whether you want to activate HW breaks or not. Then, during the debugging, could choose between HW and SW breaks and you would have two different colors for e.g. red for SW and green for HW breaks and when you reach HW breaks limit you can't add a new one untill you unset a previous one.

I think that since everyone using the HW breaks allso knows how manny breakpoints HW debugging unit supports this would be a usefull feature and there wouldn't be anny problems with the ussage.

What do others think about this?

r. Domen

Game_Ender:
I think it would be better if the editor knew nothing of breakpoints at all.  After all its just an editor why couple it so closely to the debugger.  You should have the ability to draw little arbitrary objects in the margin, for which you can register event handlers.  The event handlers can be called whenever the any of the little widgets are left or right clicked, or the line they are on changes.  You will probably have to pass some kind of "MarginWidget" object to the cbEditor which encapsulates this functionality.

This would allow you to have custom breakpoints icons, or even to use the little side bar to show other information.  This other information could be code coverage markers, line coverage etc.  For all those who care, this is what Eclipse does (a UI whose flexibility we should strive for).

P.S.-  Has anyone seen the wxPython 2.7 wxAUI + FlatNotebook class/integration?  It gives you tear away tabs!  Hopefully this will be available/ported to C++ version of wxWidgets.

DoMeN:
Yes I agree about this encapsulating object. I tried to change the cbEditor code as little as possible. I only added a new green colored breakpoint and if else statements to tel the cbEditor which of the two breaks should he draw. Then I added a variable to the debugger to indicate which type of breaks you want to use  and a function that you call from cbEditor to know there which break should be drawn.

The code isn't complete yet so I can't decide after the compile which breakpoint type should be used ( I don't have a dropdown list to select the type from). I'm allso not sure whether or not I will be able to continue because my boss told me that the changes were too extense and that I should somehow change our gdb so that it would first set all the HW breaks and then SW breaks so C::B wouldn't even see the difference. The problem with this approach is that you don't see whether you use HW or SW breakpoints so I think that this is somehow useless.

It would be werry helpfull for me if the main C::B release would have a way to choose between different breakpoints so where would it be the best place to write a feature request for

--- Quote ---You will probably have to pass some kind of "MarginWidget" object to the cbEditor which encapsulates this functionality.
--- End quote ---
this wrapper object?

Navigation

[0] Message Index

[#] Next page

[*] Previous page