Saving breakpoint presets in debugging would be awesome

New comment
 
The problem is: you have a large piece of code and you want it to stop for debugging only in a very particular scenario. 

Okay: so you can put your first breakpoint only after the respective condition. Then it will run through til that point and then you just have to set all the other points that would have stopped the program at every tick for the last five hours of data. But after the first point you need to set nearly a hundred points manually if you want to know everything that happens next.

How nice would it be if you could save breakpoint presets similar to templates or bookmarks for different debug scenarios? 
Imagine how great the decrease of time consumption for tedious repetitive searching and clicking would be.
 
Why don't you encapsulate DebugBreak() into a class and apply that for your debugging?

That should give you the needed flexibility.
 
Dominik Christian Egert #:
Why don't you encapsulate DebugBreak() into a class and apply that for your debugging?

That should give you the needed flexibility.
Thanks. 
Do you mean to use conditions to have a hierarchical order of objects of the Debug break class? 
Sounds like an awesome idea. I will see what I can do about it.
 
Tobias Johannes Zimmer #: Do you mean to use conditions to have a hierarchical order of objects of the Debug break class? Sounds like an awesome idea. I will see what I can do about it.
    Maybe this will also help:
    Author: @Dominik Christian Egert
     
    Fernando Carreiro #:
      Maybe this will also help:
      Author: @Dominik Christian Egert

      Ah yes, I see:

      "Supports following features:

      • Debug string comments
      • VarDump variables and arrays
      • Different assert types
      • Trace
      • Conditional Breakpoints
      • Performance counters"

      I had seen in before when I wasn't on the level to look into it yet. I will be doing that now.

       
      The current version only has a call to DebugBreak() wrapped into an if statement.

      The next version will most likely introduce an object with distributed conditions to multiple spots in the code.

      Just like you already empathized in your reply to my post.

      Maybe you want to contribute to the code, I will publish it as a shared project over mql5 storage soon.

      Same goes for the error handler, I want this also to be a community project, but it needs a little more polish before publishing.

      Also some documentation would probably be helpful on the code itself.

      I have no urgency at the moment, so it will be without schedule.
       
      Dominik Christian Egert #:
      The current version only has a call to DebugBreak() wrapped into an if statement.

      The next version will most likely introduce an object with distributed conditions to multiple spots in the code.

      Just like you already empathized in your reply to my post.

      Maybe you want to contribute to the code, I will publish it as a shared project over mql5 storage soon.

      Same goes for the error handler, I want this also to be a community project, but it needs a little more polish before publishing.

      Also some documentation would probably be helpful on the code itself.

      I have no urgency at the moment, so it will be without schedule.

      You must be joking, not sure what I can contribute to that project. Your library is giving me headaches. Maybe I will try and error my way in there some day, but it didn't tell me much as is.

      After that I tried to build a little class with Debug Break inside a function with a condition. 

      #include <Object.mqh>

class CDebug : public CObject {

private:
   int               m_lvl;

public:
                     CDebug();
                    ~CDebug();

   void              Lvl(const int lvl) {m_lvl = lvl;}  //here the internal m_lvl can be set
   int               Lvl() {return(m_lvl);}             //and issued
   bool              Break(const int lvl);

};
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
CDebug::CDebug() : m_lvl(0) {
}

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
CDebug::~CDebug() {
}
//+------------------------------------------------------------------+
bool CDebug::Break(const int lvl) {       //It would have been written as Debug.Break(lvl);
   if(lvl > m_lvl) return(false);         //Level is compared to the private m_level to see if we can enter the
   if(lvl <= m_lvl) {                     //breakpoint already.
      DebugBreak();
   }
   return(true);
}

//+------------------------------------------------------------------+

      Problem is as soon as the condition is met, the function is called and I end inside the class code, because the debug break is there, not in the program code that I would like to debug.

      Then I tried this at the end of my code lines:

      if(0>=debug_lvl)DebugBreak();
//debug_lvl is set to zero in the beginning and then increased. Problem was that Editor just ignored the condition and went straight for the Debug break.
       
      Of course it will give you a break exactly there, you will need to use a macro to make it appear at where you want the break.

      Within the macro you would use the object only to determine if you want to break at that point.

      I will give it some thought and see if I can come up with something generalized to add to the lib_debug.

      As far as I understand, usually we would be looking for a break if a variable has a certain value. A condition needs to be met.

      Now as far as I understand, you want to have multiple breakpoints activated as this condition is met at a certain point in your code, right?

      So the macro needs to know what to reference, as it could be, you'd be using this for multiple instances or conditions.

      So they need to be linked in some way.

      So this could result in following parameters:
      #define DBG_BREAK_ON_CONDITION(cnd_id, cnd)

      Where cnd_id is some identifier and cnd is the true/false condition to be met.

      Now we would need another macro, something like:
      #define DBG_BREAK_ON_ID(cnd_id)

      Which would break as well as the condition has been met.

      Now this leads to the situation that the first macro must initially set the condition and after that all other breakpoints with the same ID would also halt the execution.

      Would that be satisfying?

      It should not be to hard to implement such a logic.
       
      The second attempt you showed is obviously wrong.

      Your if clause will always be true. Greater or equal to zero, initialized with zero. This is instantly true.


       
      I quite good understand, reading macros is not very fun, there is no real way to follow the code.

      It all needs to be done by macros and some compiler tricks, utilizing Templates to get all the stuff working.

      To me it was a pain always "reinventing" the debug code at every spot in the code where I needed it, so I started to build a small lib to support my case.

      It grew over the years of usage.

      Maybe some more docs could help.

      Tell me where you are stuck, maybe I can give some insight.

      Did you try the break on condition macro?

       
      Yes that would be something like this. I was thinking that you have that already since you wrote conditional breakpoints in the CodeBase description.

      Thanks for going the extra mile here, but I have a feeling that most of it is lost on me if I won't jump into macros beforehand.

      Well, the second attempt... yes, it should ve 0<=debug_lvl, and debug_lvl being zero initially.
      So if I wrote 

      if(1<=debug_lvl)DebugBreak(); it sould not be called. Okay, maybe my mistake was the reason why it didn't work out.

      So in the beginning I want only the breakpoints of lvl=0 to stop the program. After this initial hurdle, debug_lvl will be changed to 1, 2, 3 and so on.

      It will be useful when you need a very specific condition to enter debug but after that you need to observe a lit of very common parts like OnTick events. Is that already possible with your MQLplus program?

      12
      New comment
      Reason: