Sometimes an IDL procedure will be compiled, but IDL will think that the procedure call is a reference to an undefined variable.
% Variable is undefined: TRACE_ONE_LOOP. % Execution halted at: SHOW_LOOPS_ON_BST 57 /home/anny/FAn/show_loops_on_bst.pro % SELECT_LOOPS 86 /home/anny/FAn/select_loops.pro % ZOOM_IMAGE 31 /home/mimccart/programs/zoom_image.pro % SELECT_LOOPS 71 /home/anny/FAn/select_loops.pro % $MAIN$
In these instances, the work-around I have found is to break the program, then call the "undefined variable" procedure manually.
For the above example the "undefined variable" is in line 56 of 'show_loops_on_bst.pro'
55>> ;print,junk 56>> IF( keyword_set( bumps ) ) THEN ltr = trace_one_loop( bst, loops(i) )
Notice that there is a commented-out print statement in the preceeding line. In order to fix the compiliation issue (which might be the most rudimentary fix there ever was), uncomment out the print statement. Recompile and re-run. Because "junk" is not defined as a variable, the program will break at line 55. DON'T 'RETALL'.
Instead, manually call the "undefined variable" function. This won't return a "Variable is undefined" error message. Then re-comment out the "print,junk", re-compile the function, and re-run the procedure. The issue should be fixed.
This is annoying, and I have no clue why this happens. But at least this is a pretty straightforward fix, even if it is pretty labor intensive.