Hi,
I was somewhat mislead by the method names update() and updateHook() in the class TaskCore.
I suspected that the ExecutionEngine calls the update() and that the update in turn calls updateHook().
This would allow the framework to do stuff in the update() and allow the user to implement his code in the updateHook().
In real-life the situation is the other way around. What is your motivation?
Because update() calling updateHook() seems more logical to me, just like configure() and cleanup().
Sander
update, updateHook and friends.
Quoting Vandenbroucke Sander <Sander [dot] Vandenbroucke [..] ...>:
>
> Hi,
>
> I was somewhat mislead by the method names update() and updateHook()
> in the class TaskCore.
>
> I suspected that the ExecutionEngine calls the update() and that the
> update in turn calls updateHook().
> This would allow the framework to do stuff in the update() and allow
> the user to implement his code in the updateHook().
>
> In real-life the situation is the other way around. What is your motivation?
> Because update() calling updateHook() seems more logical to me, just
> like configure() and cleanup().
Your are completely right. Unfortunately, the old user code (RTT 1.0) was in
update(). In rtt 1.2, we changed the naming to updateHook(). In order
to support backwards compatibility, we needed to keep the update()
function, although it is deprecated (see the API docs). The code is
setup in such a way that if updateHook() is not implemented, update()
is called.
What I really wanted was that update() worked liked configure(),
start(),... and updateHook() was called by the ExecutionEngine. This
is so if you look at the scripting interface, there is an 'update()'
method, but it maps to the C++ function 'doUpdate()' instead.
We can only break this in RTT 2.0, which is not at the horizon at the moment.
Peter