Forum > Debugger
No break where expected
Martin_fr:
You can use "Find identifier references" (or search in files) to find all source locations, and then filter search results for ":=" (hoping that it isn't on a new line).
Or just look through the unit that implements the class. (find next word occurrence)
440bx:
Thank you Martin and rvk.
Is there a way I can find out the _first_ function/procedure that is called when an option is selected ? e.g, in pure API procedural programming I can simply go to the message handler and see the code that will be executed when an option is clicked on, how is that done with this OOP code ?
Martin_fr:
Define "first function"....
As rvk already pointed out there are different ways to select an option, and they change the FItemIndex in different places. So there are many first functions.
You can breakpoint each location, and then go through all triggers, and look at the stack of each.
Below is a stack for the click on a radio (taking out windows kernel)
What is the first function?
RunLoop pulls a message from the Win-API. So the first thing it calls is TApplication.HandleMessage
Closer to what you may expect the first thing called would be
TCustomCheckBox.DoChange
which handles the message LM_CHANGED. So that message is the first thing that goes into code specific to the control.
But maybe you are more interrested in the Click or Changed method?
--- Code: Text [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---#0 TCustomRadioGroup.UpdateRadioButtonStates at radiogroup.inc:627#1 TCustomRadioGroup.CheckItemIndexChanged at radiogroup.inc:455#2 TCustomRadioGroup.Changed at radiogroup.inc:550#3 TButtonControl.DoOnChange at buttoncontrol.inc:49#4 TButtonControl.Click at buttoncontrol.inc:54#5 TCustomCheckBox.DoClickOnChange at customcheckbox.inc:281#6 TRadioButton.DoClickOnChange at radiobutton.inc:74#7 TCustomCheckBox.DoChange at customcheckbox.inc:107#8 TObject.Dispatch at objpas.inc:684#9 TControl.WndProc at control.inc:2304#10 TWinControl.WndProc at wincontrol.inc:5474#11 DeliverMessage at lclmessageglue.pas:114#12 TWINDOWPROCHELPER.DoWindowProc at win32callback.inc:2621#13 WindowProc at win32callback.inc:2786#14 ButtonWndProc at win32wsstdctrls.pp:1973...#18 TWINDOWPROCHELPER.DoCmdCheckBoxParam at win32callback.inc:1333#19 TWINDOWPROCHELPER.DoWindowProc at win32callback.inc:2176#20 WindowProc at win32callback.inc:2786#21 GroupBoxWindowProc at win32wsstdctrls.pp:680...#29 CallDefaultWindowProc at win32callback.inc:125#30 TWINDOWPROCHELPER.DoWindowProc at win32callback.inc:2529#31 WindowProc at win32callback.inc:2786#32 ButtonWndProc at win32wsstdctrls.pp:1973...#35 TWin32WidgetSet.AppProcessMessages at win32object.inc:420#36 TApplication.HandleMessage at application.inc:1306#37 TApplication.RunLoop at application.inc:1449
Of course key presses may do different stuff. You can use the cursor keys and select with afaik space.
Or if you have captions with & then you can press the letter that is underlined in the caption.
In the end the OOP really should not make it much difference, except that some calls go through base classes. But for each action something comes from the OS, and it calls a function. Only then the OOP means that tracking it becomes a bit harder, because once codetool took you into the base class, it wont use the original class for further lookup of called methods.
440bx:
Thank you Martin.
I realize now that the situation is totally different than when programming non-OOP and pure API.
Looking at the call stack definitely helps.
Martin_fr:
--- Quote from: 440bx on November 28, 2024, 05:55:17 pm ---Thank you Martin.
I realize now that the situation is totally different than when programming non-OOP and pure API.
Looking at the call stack definitely helps.
--- End quote ---
None OOP you can still have lots of different entry points for API reporting keys (for each different key) or mouse.
And none OOP you can still go through a dispatcher, that decides what to do for each event, and searches some list for the handle that the API would have given for the control.
This is probably more the difference between using a framework (that must do a lot of checks because of all the things it supports), or pure API only implementing the exact stuff that the current app needs.
As far as OOP goes in this context, IMHO the only different is tracking virtual methods (other methods that may be on several classes, are just like same-name-functions (plain / non-oop) across different units. Because you can't just take the declared class of the caller, but you need the instance class. So you need an earlier caller that decided the instance.
Navigation
[0] Message Index
[#] Next page
[*] Previous page