Correct value table information

Author: udv2g

README.md

@@ -36,7 +36,7 @@ The system does not automatically timestamp *Write* output unlike the *Trace* wi
 
 The *CAPL* system can use the loaded database (`.dbc`, `.ldf`, etc.) to automatically interpret and set *signal* values, but nowhere is this concisely described.  The *signal* name itself is used to set or get the raw (on the wire) value of the *signal*.  To get or set the scaled value, append `.phys` to the *signal* variable name.  
 
-The values defined in a *value table* (enumeration) associated with the *signal* can also be accessed.  To get a string representing the current value of the *signal*, append `.name` to the *signal* variable name.  The *value table* values can be used as if they were defined as constants, but if (as is often the case) multiple *signals* use the same values, the system is not smart enough to figure out which one is meant.  `<signal name>::<value>` can be used in this case (e.g. `ShifterPosition::Park` would return the numerical value of `Park` as defined in the *value table* associated with the `ShifterPosition` *signal*).    
+The values defined in a *value table* (enumeration) associated with the *signal* can also be accessed.  To get a string representing the current value of the *signal*, use `((enum VtSig_<signal name>)<variable>).name()` (e.g. `((enum VtSig_ShifterPosition)this).name()`).  The *value table* values can be used as if they were defined as constants, but if (as is often the case) multiple *signals* use the same values, the system is not smart enough to figure out which one is meant.  `<signal name>::<value>` can be used in this case (e.g. `ShifterPosition::Park` would return the numerical value of `Park` as defined in the *value table* associated with the `ShifterPosition` *signal*).    
 
 ## Receiving data from the network