You need to memories the actual direction of an actuator (motor) in a variable.
This is the state of the full bridge motor output.
Also in the API there is no method available to retrieve state information of the actuators.
An Quardratur-Encoder will give only information about the last sense of rotation.
This can difference from the direction.
Example:
Image a motor with less power and direction CW, which is turning into the opposite direction because of the load.
In this case the direction (CW) (of the full bridge power supply) difference from the real sense of rotation (CCW).
You will see this issue back with steppers: a stepper control has very often a Ihold and an Irun.
The Ihold has as function to maintain the position of the actuator when it is under load.
A stepper without Ihold can turn freely.
For this reason you will see in the FtTxService (MS-RDS drivers for the TX-C) a more complex definition of an motor.
Maintaining a position in robot application/models is very often an underestimated problem.
For this reason I always hope that at least a software implementation of a rotary-encoder or Quardratur-Encoder will be added to the TX-C and TXT.
This will cost two Fast Counter inputs for one encoder.
Creating/buying the sensor himself it not too difficult however without the software implementation these encoder systems could even not used.
See also:
http://forum.ftcommunity.de/viewtopic.php?f=15&t=2599