fdc0257acb
A classic LLEventAPI subclass calls LLEventDispatcher::add() methods in its own constructor. At that point, addMethod() can reliably dynamic_cast its 'this' pointer to the new subclass. But because of the way LazyEventAPI queues up add() calls, they're invoked in the (new) LLEventAPI constructor itself. The subclass constructor body hasn't even started running, and LLEventDispatcher::addMethod()'s dynamic_cast to the LLEventAPI subclass returns nullptr. addMethod() claims the new subclass isn't derived from LLEventDispatcher, which is confusing since it is. It works to change addMethod()'s dynamic_cast to static_cast. Flesh out lazyeventapi_test.cpp. post() maps with "op" keys to actually try to engage the registered operation. Give the operation an observable side effect; use ensure_mumble() to verify. Also verify that LazyEventAPI has captured the subject LLEventAPI's metadata in a way we can retrieve. |
||
|---|---|---|
| .. | ||
| cmake | ||
| copy_win_scripts | ||
| doxygen | ||
| integration_tests | ||
| lib/python/indra | ||
| linux_crash_logger | ||
| llappearance | ||
| llaudio | ||
| llcharacter | ||
| llcommon | ||
| llcorehttp | ||
| llcrashlogger | ||
| llfilesystem | ||
| llimage | ||
| llimagej2coj | ||
| llinventory | ||
| llkdu | ||
| llmath | ||
| llmeshoptimizer | ||
| llmessage | ||
| llplugin | ||
| llprimitive | ||
| llrender | ||
| llui | ||
| llwindow | ||
| llxml | ||
| mac_crash_logger | ||
| media_plugins | ||
| newview | ||
| test | ||
| tools/vstool | ||
| viewer_components | ||
| win_crash_logger | ||
| CMakeLists.txt | ||
| edit-me-to-trigger-new-build.txt | ||
| fix-incredibuild.py | ||