Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Splitting debugger in two - specific debugger and common GUI
cbexaminr:
Ok.
oBFusCATed:
BTW, I've one problem with the just committed patch:
When the disassembly is in mixed mode, both c/c++ and asm lines are coloured as asm lines.
Does someone knows if it is possible to disabled the syntax highlight for single line or a block of text?
I've looked at the code, but I couldn't find anything that would do the job.
oBFusCATed:
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0017.7.patch (improved version of http://forums.codeblocks.org/index.php/topic,10908.msg89496.html#msg89496 )
1. Added GetIsRunning method to ProjectManager, it is used to query the plugin that is running the project (running the application, debugging the application, etc)
2. Added SetIsRunning method to ProjectManager, it is used to set the plugin that is running/executing the project, it is set only if the GetIsRunning returns NULL
3. Modified the Compiler plugin to use the new methods (set and reset correctly the running flag, modified the toolbar/menu updateui functions)
4. Modified the Debugger plugin to use the new methods (set and reset correctly the running flag, modified the toolbar/menu updateui functions)
5. Fixed all (almost), bugs I've encountered since v17.3
I think this patch could be applied now, Morten?
Also what about another nightly build, so the disassembly changes and the changes in v17.7 could be tested in the wild? :)
MortenMacFly:
...I got another 2 issues:
1.) I am not sure if this is related: But after applying the patch C::B does not startup anymore and I receive an error that the wxScintilla window could not be created in the constructor, in this line:
--- Code: --- m_pCode = new wxScintilla(this, wxID_ANY);
--- End code ---
...which goes back into the disassembly window (which was modified). I am still investigating though as in parallel I modified scintilla, too... unfortunately.
2.) From the logs I see a lot NULL pointer issues. meaning crash candidates, e.g.:
--- Code: --- m_MixedModeCB = (wxCheckBox*)FindWindow(XRCID("chkMode"));
m_MixedModeCB->SetValue(Manager::Get()->GetDebuggerManager()->IsDisassemblyMixedMode());
--- End code ---
...or here:
--- Code: --- DebuggerManager &manager = *Manager::Get()->GetDebuggerManager();
bool newMode = !manager.IsDisassemblyMixedMode();
--- End code ---
Please always make sure you verify pointers. The only exception might be singleton classes, but even then you must be careful if the app shuts down. The latter is strange anyways, why don't you operate with pointers here? This is the only place I know where a singleton class is used by reference. IMHO this is dangerous and violates somehow the concept of a singleton.
Concenring functionality: Well... I'll try to get it up and running... :lol:
oBFusCATed:
--- Quote from: MortenMacFly on November 25, 2010, 08:54:15 pm ---...I got another 2 issues:
1.) I am not sure if this is related: But after applying the patch C::B does not startup anymore and I receive an error that the wxScintilla window could not be created in the constructor, in this line:
--- Code: --- m_pCode = new wxScintilla(this, wxID_ANY);
--- End code ---
...which goes back into the disassembly window (which was modified). I am still investigating though as in parallel I modified scintilla, too... unfortunately.
--- End quote ---
Running HEAD of the branch and I can start and use C::B, even the disassembly window works.
--- Quote from: MortenMacFly on November 25, 2010, 08:54:15 pm ---2.) From the logs I see a lot NULL pointer issues. meaning crash candidates, e.g.:
--- Code: --- m_MixedModeCB = (wxCheckBox*)FindWindow(XRCID("chkMode"));
m_MixedModeCB->SetValue(Manager::Get()->GetDebuggerManager()->IsDisassemblyMixedMode());
--- End code ---
...or here:
--- Code: --- DebuggerManager &manager = *Manager::Get()->GetDebuggerManager();
bool newMode = !manager.IsDisassemblyMixedMode();
--- End code ---
Please always make sure you verify pointers. The only exception might be singleton classes, but even then you must be careful if the app shuts down. The latter is strange anyways, why don't you operate with pointers here? This is the only place I know where a singleton class is used by reference. IMHO this is dangerous and violates somehow the concept of a singleton.
--- End quote ---
Which logs?
Morten, you can find code like "SomeManager *manager = Manager::Get()->GetSomeManager();" all over C::B's sources and very few times the pointer is checked.
Also the "SomeManager *manager = Manager::Get()->GetSomeManager();" and "SomeManager &manager = *Manager::Get()->GetSomeManager();" is pretty much the same.
If you don't like it, you can rewrite it the style you prefer :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version