Common problems when using the Response Table macros.
o make the Response Table macros work correctly, you need to remember a few details. There are other pitfalls you may run into, but the mistakes we'll discuss here seem to be the most common.
First, make sure you declare your response function with the correct name and signature for the message. When the EV_WM_LBUTTONDOWN macro creates its entry in the Response Table, the compiler will expect your class to have a function named EvLButtonDown(), which takes an unsigned integer (UINT) and a TPoint object as arguments and returns void. If the signature doesn't match this, an error will point to the source line that contains the EV_WM_LBUTTONDOWN macro statement.
Table A The OWL framework defines four different forms of the Response-Table-definition macro.
| Macro Name | # of TEventHandler-derived base classes |
| DEFINE_RESPONSE_TABLE | 0 |
| DEFINE_RESPONSE_TABLE1 | 1 |
| DEFINE_RESPONSE_TABLE2 | 2 |
| DEFINE_RESPONSE_TABLE3 | 3 |
Depending on the number of event-handling immediate base classes you derive your class from, you'll need to call different versions of the DEFINE_RESPONSE_TABLE macro. You need to use the correct macro to ensure that it creates a call to the Find() function for each of the base classes.
However, don't pass this macro the name of a class that isn't an ancestor of the TEventHandler class. If you do, the macro will try to create a call to that class's Find() function, and the compiler will report an error.
Finally, if you directly inherit your class from more than three descendants of the TEventHandler class, you may run into trouble. OWL provides only the versions shown in Table A.