I actually don';t like the ntoation, but I was trying to repeat standards they put, but what I actually learned is their standard changed so it;s only fdor NEW code.
As for the fix I can explain it I guess....
WARNING: BASIC OBEJCT ORIENTED PROGRAMMING AND MVC DESIGN PATTERN REQURIED TO UDNERSTAND THE FOLLOWING!
Basically, it's not hard to figure out even though I never used wxwidget, I had basic knowledge of c++, mvc design pattern (where you have your gui that has binding to object properties or command to triggers stuff) and it was jsut likely a little thign that was forgotten, these features aren;t targetted at end user so....I guess these thigns happens and they dont; matter this mcuh unless you are debugging stuff whcih is super advanced.
You can add a memory check by clicking next to an address in the memory view, it does add or delete the breakpoint, but the problem is if you ahd the breakpoint list opened soemwhere, it doesn;t do anything which tbh, it;s very confusing and I didn't like that. So I got into the code and after some hours of debugging session (I am not used to debug such large stuff let alone dolphin codebase), I found that basically, when the mouse down evvent happens, it toggles a breakpoint, update the memory view, creates an event command that is used to update the breakpoint list (the same used for the code view) and finally, this event gets added to the event manager.
It sounded right, but I noticed that the method used to update the breakpoint list (notifyupdate) never gets called on the memory check adding, but it does on the code view BP adding. Thankfully, debuggers has a call stack so I could go backward to see who called notifyupdate in the code view instance and it turned out to be the code window which grabs these event in a switch case. When it reaches that switch and finds it';s to update the breakpoin list, it calls notify update on the breakpoint window (for soem reasons, codeWindow is sort of a master for everythign debug UI related so it has access to the breakpoitn list).
So time to check what the memory view does, the event gets run, but the method that receives it has a switch with NO case for the breakpoint update comand, that was the problem.
Fixign this is as expected fairly trivial, you jsut add to the constructor fo the breakpoint window the code window (it;s done in code window functions whcih has these calling utilities) so now breakpoint widnow hjas access to notify update and......just manage that case when the breakpoint widnow exist in the switch.
To be fair, it's really small, 95% of people jsut won;t care about this, but I do and the other cool thing about this is I was finally able to contribute to an open source project with actuall code. I always wanted to do soemthing in an open source project so if this gets merged, it would be my first contribution and it jsut makes me happy