Conditional Break Point in Sage ERP X3

Note: The following advice is for the basic debugger in X3, not the Eclipse debugger.

Often in Sage ERP X3 customizations, you will find yourself debugging trying to determine which action or subprogram is setting or changing a screen value.  In most programming languages, this would be a simple task.   You would simply set a watch and place a breakpoint on it.   Unfortunately, the default debugger in X3 does not allow you to set breakpoints on watches.   The code below shows a way to quickly pause execution in your SPEXXX program only when the screen value changes.   This code has saved us hours of tracing through the X3 code.

$ACTION

#Set Error Trap in case the global variables are not defined
Onerrgo ERROR_GLOBAL_DEF

#If the field value is different from last time, then suspend
If clalev([M:MSK]) and [M:MSK]SOMEFIELD <> GLASTVALUE
    Dbgaff
   #While suspended, in Debugger check the value for the following variables:
   #GLASTACTION - This will contain the action that caused the field value to change
   #GLASTVALUE   - This will contain the value before it was changed
   #[M:MSK]SOMEFIELD - This will contain the new value for the field
Endif

#Save the current action and field value.  The will be used the next time $ACTION is called
GLASTACTION = ACTION
GLASTVALUE   = [M:MSK]SOMEFIELD
Onerrgo

#Run the default code in SPEXXX and SUBXXX
Case ACTION
 When Default
Endcase
Return

#########################################################################
$ERROR_GLOBAL_DEF
#########################################################################
#If we are hitting this error, then it is assumed that these global variables are not defined
Global Char GLASTACTION
Global Char GLASTVALUE
GLASTACTION = ""
GLASTVALUE   = ""
Resume Some quick notes:

• Change [M:MSK] and SOMEFIELD to be the screen mask and field that you wish to track
• Clalev() is the only function that we have in X3 for checking for a field's existence.  However, Clalev() does not work correctly on global variables.  That is why the Error Trap was used in the code above to declare the variables.   If you declare these variables before this program is called, then the error trapping is not required. 
• Of course, you would not keep this code in the production system.   Just in case you forget to remove it, I recommend placing an "IF guser = "MYID"" condition around this code. 
• If you have a better way of handling these breakpoints, please share here.