This page is a collection of some debugging tips for the program.

Another tip. Running debug, you can tell the string of procedure/functions that preceded where you are at:

VIEW/DEBUG WINDOWS/CALL STACK

Addl tip: use multiple editors. My preference is Notepad++, but the point is that you are referencing many codepoints, so using external editors can greatly ease the task of moving from one codepoint to another. Unfortunately (most) editors have common navigation keys (Ctrl-F for search, etc), not true with Delphi. 'GExperts IDE Menu Shortcuts' can help standardize but you have to be careful re: what keys are already reserved.

This is intended to be an ongoing document where we can add hints on how to debug, fix, enhance the TR4W product. Hopefully it will be of use to our successors. Please feel free to contribute any hints, this is just a 'stake in the ground'.

It will be assumed you have a copy of Delphi compiler and understand how to run a compile.

Ok, lets get started.

One way to think of the process is in two steps:

Firstly finding the Unit you need to hook and secondly locating the variables that need to be changed. Interestingly, the third step of writing the code is usually not to difficult.

NO MAGIC BULLETS ! Initially, it is difficult to locate WHERE in the code you want to set your hooks.

A few hints, Delphi units have names that assist to assessing their funcition. So something, like MainUnit is just what is sounds like. TR4W.DPR is THE program itself- if tracing a program and returning there, you have probably gone to far and returned to his main callback dispatcher. DPR also shows you which of the TRlog units are exploited (in its USES section). Note that each unit (module) has a USES section. This tells you know whose procedure and functions will be exploited by the unit you are looking at. More help is provided by the SEARCH Find in FIles and Find. You will discover that FIND IN FILES is slightly more powerful. Also note that add on program GExperts will allow you to set shortcut keys for search. I am habitually welded to CTRL-F being Search so this has proven useful. Here is an extra hint, Linux is a more powerful OS than Windows and has a lot of good built in's. One of those is GREP (another is GIT itself). A big portion of the linux tools may be exploited by you using the SourceTree terminal - which functions as a linux command box. Just to give one example, say you want to search a secondary or tertiary directory where you have another level of TR4W. Using the terminal, 'cd new directory' This is linux, so use forward slashes: 'cd i:/sandbox' would put you into your sandbox directory on the I: drive. Now you can search for code there by entering something like 'grep -ir "//gav" .' This says "show me all entries, irrespecitve of case that contain '//gav'. The dot at the end will allow search of subdirectories (for us that will be TRDOS). Within your project directory, you can accomplish the same thing by SEARCH FILES. Note the results appear in the bottom information window which you can resize. Are you searching for a function/procedure ? In the resultant list of hits, the first one for the funciton/procedure usually will be the declaration. Typically you want the second one.

Next notice that the top of the unit has a list of declarations-- this can be VERY useful as, again, the names are indicative of the purpose of the function or procedure. Functions and procedures are very similar, but a function returns a value to the caller. Especially, initially, your time will be spent locating the code you want to patch. Not easy ! The good news is that the more you do it, the more you know where to look. It is probably worth pointing out that Delphi code is basically a collection of procedures and function within the network of units. A class Object action initiates a sequence- it can easily be thousands of instructions long.

You will need sheet(s) of paper to map flow and variable candidates. Speaking of flow, Ok after exhaustive study you have a candidate procedure of function. Unfortunately, you will find that many times the candidate is not involved. How to establish ??? IDE DEBUG IS YOUR FRIEND

The basic idea is to set a BREAKPOINT at the codepoint you suspect. If you modified ANYTHING, do an F2 (save) followed by control-f9 compile. To proceed, the compile must run without errors. Now you can press F9 and start TR4W. Give him the startup parms you wish and invoke the tr4w selection you are interested in. Did you hit the breakpoint ?? If not, back to the drawing board. There is much dead code and many paths that are not active like you thought, so do not be discouraged.

Finally, you hit your breakpoint ! This tells you that you have correctly interpreted that the codepoint is exploited by TR4W when you invoked the action you are exploring. Before stepping, you may wish to control-F4 to examine variable values or invoke WATCHPOINTS to monitor the values of variables. Note that you may want to move the watchpoint box down to the bottom of your screen (information area).. Ok, you are more than halfway there. There is still the daunting task of determining/finding the variables you want to change. They may or may not be in the unit that you successfully established a breakpoint on. Recall the variables can be in any unit identified in USES.

If you have not already done so, pls go to issue tracker, find a bug/enhancement that has been signed off. If GMOGAV, he comments using '//Gav' . Likewise N4AF is //N4AF. Issue tracker lists the modules hit, so using latest source or source from n4af.blountscreek.org/TR4W under the mod level, walk the code and see what they did. Not only may it be instructive, but in some cases it can provide a model. An example would be if you are adding a contest. Why re-invent the wheel ? Find the N4AF Marconi Memorial Contest mods. Another example is adding to the CONTROL-J options using Gav's Band Map Display Limit addition. Additionally, if working at contest specific level, you may want an overview of parms.exploited. http://tr4w.com/supportedcontests/index.html provides such a vehicle. Click on a suspect contest to examine. Once you are more used to it, there are units that accomplish the same thing. Contest specs tend to reside in VC unit. Control-J in uCfg. TR4W main menu pulldowns in uMenu and their processing in MainUnit. I am sure this list can be added to !

Finally, recall that your HARD WORK in finding your codepoint is NOT in vain -- each subsequent time will be slightly easier !

AUTOSPOT

There is a conditional define called AUTOSPOT. You set this in the Directories/Conditionals tab of the project options. In the Conditionals frame, in the Conditional defines field, you add AUTOSPOT.

When you compile, the rig will automatically tune to each spot that comes in. If you are running on TWO RADIO mode, it will alternatively tune each radio as each spot arrives. If you want to drive this quite fast, connect to a CW spotter and your rigs will start switching away. I found that if I set the spot for the same band (set dx filter band=40), that the internal relays on the radios do not switch. You may not want to drive the hardware and such.

When this option is not in the conditional defines, the code is omitted from the compile.

Of course, it is critical that this NOT get compiled into any production code. To make sure of this, there is a ShowMessage dialog when the program starts in AUTOSPOT mode. Again, this is only compiled in when the option is defined.

Writing to the Telnet Console

Many places in the code will enable a display to the Telnet console as sort of a running debug window. AddToTelnetSession