Wrapping Toolkit routines

Sometimes you would like to be able to override the behavior of a Synergy/DE Toolkit routine. Perhaps calls to the routine pervade your application to such a degree that replacing all of them with a call to another function would be onerous or risky. Perhaps the routine in question is often called from within other Toolkit routines, so replacing every instance of the call is not an option. Whatever your reasons, the downloadable code below demonstrates how to overload a Toolkit routine with your own version, and also how to call back to the original Toolkit routine in order to inherit its functionality.

To summarize the approach: first create your own version of the routine with the same name as the original Toolkit routine. Then link it into your program with a higher precedence than tklib.elb. In the example, use the batch file bldwrap.bat to build the executable (UNIX users will need to adapt the batch file to a shell script). Note that in the dblink command for twrap.dbr, wrapbell.elb comes before WND:tklib.elb. This causes it to have precedence, and even when the Toolkit calls U_BEEP, it resolves to our version. Another approach to achieving the same result would be to call OPENELB for your ELB.

The test program, twrap.dbl, has a menu entry to enable or disable the bell. It also has a menu entry for calling U_BEEP directly. To indirectly call U_BEEP through the Toolkit, press a shortcut key that is not mapped to any menu entry (F1, for example). If the bell is enabled, it should ring when you press the unmapped key (except when a menu is pulled down on Windows). Otherwise, not.

Caveat: I have not had any luck with using this approach on OpenVMS. The OpenVMS linker has a distinct dislike for encounters with multiple routines having the same name. I have used it successfully for several different Toolkit routines on Windows and UNIX systems.