Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
DDD-like watches
oBFusCATed:
--- Quote from: m.29 on March 22, 2011, 11:12:27 am ---Pointers on structures in CDB is good now. But tests in debuggergdb_test_parser_cdb.cpp are wrong. Results would be t*=0x123456 instead of t=0x123456, because of inputs are pointers.
--- End quote ---
No, the test are correct, but the parser is broken if it returns t*=0x123456.
The tests work correctly on linux. I've not tried them on windows, probably I must do so in the next couple of days.
m.29:
Sorry, I changed GetSymbol with GetType. I tried it on Ubuntu, and it works correctly.
I resolved all collisions in my sources and created patch. Every feedback will be appreciated. Thanks for your time :D
oBFusCATed:
Why do you have GUI code in the plugin?
And why do you need AddVisualObject and DeleteVisualObject (probably because of the previous :) )?
Probably a better way is to use watches directly, so then your implementation will be common for all debugger plugins.
At the moment every plugin should reimplement your tree controls in order to implement this feature.
You should modify the watches, to mark them non visible in the Watches windows, but I think this is minor problem at the moment.
For testing purposes you can have them duplicated in both windows (Watches window and your new window).
p.s. For doing GUI the official way is through the use of wxSmith.
p.p.s. I was thinking if it would be possible to implement this whole visible debugging as a separate plugin, so its impact on C::B is minimal. What do you think?
m.29:
Hmm, because I have to display data structures? :? What other way is possible to display them? Or what is it wrong specifically?
Every plugin can implement this methods (AddVisualObject and DeleteVisualObject), and then create your own visual representation of watch. This representation will be created then by calling this method.
My idea was, that every plugin can implement your own representation of watch, which will be displayed on the canvas. My representation is tree control, but some other plugin can implement it other way.
This is great idea. I can try it :) But what is major problem then?
ad p.s. I tried to do things similar to nearest code. I read articles about formatting and other advices in C::B, but I saw that every piece of code has his own formatting and logic. I write GUI in xrc instead of wxs because all other windows was written in this format. This is what you point to? I can read about wxSmith, but I don't know where should I use it.
ad p.p.s. I was also thinking this way, but I followed by your advise:
--- Quote from: oBFusCATed on January 22, 2011, 11:36:39 pm ---m.29:
Probably you need to modify the sdk and put most of the drawing code and data structures there.
If you do so all plugins can implement this graphical mode, not only the current one and there will be minimal code duplication.
See how it is done for the other features (watches, breakpoints, etc).
--- End quote ---
I look at how it is done for watches and then create similar cbVisualObject. I tried implement it as a separate plugin, but I don't know how, because I want to add functionality to GDBDebugger and I haven't access to its structures (e.g.: GDBWatch) in separate plugin.
oBFusCATed:
--- Quote from: m.29 on March 23, 2011, 12:16:48 pm ---Hmm, because I have to display data structures? :? What other way is possible to display them? Or what is it wrong specifically?
--- End quote ---
Why don't you use cbWatch as your data structure?
This was my initial idea.
--- Quote from: m.29 on March 23, 2011, 12:16:48 pm ---Every plugin can implement this methods (AddVisualObject and DeleteVisualObject), and then create your own visual representation of watch. This representation will be created then by calling this method.
My idea was, that every plugin can implement your own representation of watch, which will be displayed on the canvas. My representation is tree control, but some other plugin can implement it other way.
--- End quote ---
No, you want the drawing and control code to be common for all plugins. The plugins should implement only data gathering.
See the MVC pattern. The View and the Controller should be common in the SDK or in additional plugin. Only the model should be implemented by debugger plugins.
--- Quote from: m.29 on March 23, 2011, 12:16:48 pm ---ad p.s. I tried to do things similar to nearest code. I read articles about formatting and other advices in C::B, but I saw that every piece of code has his own formatting and logic. I write GUI in xrc instead of wxs because all other windows was written in this format. This is what you point to? I can read about wxSmith, but I don't know where should I use it.
--- End quote ---
True, most of the GUI is done using XRC, but this has/had happened before wxSmith.
--- Quote from: m.29 on March 23, 2011, 12:16:48 pm ---ad p.p.s. I was also thinking this way, but I followed by your advise:
--- Quote from: oBFusCATed on January 22, 2011, 11:36:39 pm ---m.29:
Probably you need to modify the sdk and put most of the drawing code and data structures there.
If you do so all plugins can implement this graphical mode, not only the current one and there will be minimal code duplication.
See how it is done for the other features (watches, breakpoints, etc).
--- End quote ---
I look at how it is done for watches and then create similar cbVisualObject. I tried implement it as a separate plugin, but I don't know how, because I want to add functionality to GDBDebugger and I haven't access to its structures (e.g.: GDBWatch) in separate plugin.
--- End quote ---
You've not followed it, because you have GUI in the plugin and if you look at this http://forums.codeblocks.org/index.php/topic,10908.0.html topic you'll see that I've tried to extract the GUI from the plugin.
What info do you need in GDBDebugger or GDBWatch that is not accessible through the SDK interfaces cbDebuggerPlugin and cbWatch?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version