Customer's feedback: In both test steps and screen elements, it is possible to use data binding with coded variables - this is very useful, even in testcases which do not use iterative data-binding. However, this feature does not work properly if the testcase property 'DataEnabled' is not enabled. The front end still allows both test cases and screen elements to be defined using coded variables, as if this feature were enabled; but at runtime, the steps are run as if no data-binding had been defined at all. Steps to reproduce: 1) Create a test, initially with simple data binding. 2) Remove the data binding. 3) In place of the data binding, add a coded test step which uses SetExtractedValue to save a coded variable. 4) Add a test step which uses the coded variable in data binding - e.g. an Enter Text step. 5) Define a screen element which uses the coded variable in data binding, and add a test step which uses this screen element. 6) Run the testcase; the run fails, because neither of these test steps use the coded variable. 7) Examine the test properties - note that the DataEnabled flag is unticked. 8) Tick the DataEnabled flag. 9) Rerun the testcase; this time it works, with both test steps using the coded variable correctly. . Conclusions: a: When data binding is removed, it automatically disables the DataEnabled property - but this is unhelpful because this property may still be necessary for using coded variables. b: Even if the DataEnabled property is unticked, the front end lets me develop the test using coded variables even though these will not work at runtime. c: At runtime, if the DataEnabled property is unticked, any steps which use coded variables do not run properly - but there is nothing useful written to the log to explain what is going wrong. Recommendations for preventing this kind of problem in future: 1) When removing data binding from a testcase, do not disable the DataEnabled property. 2) When editing a test: If a test has the DataEnabled property disabled, do not allow coded variables to be used in a test step definition. Instead, warn the user that the test is not data-enabled. 3) When editing a test: If a test has the DataEnabled property disabled, do not allow coded variables to be used in a screen element definition; instead, warn the user that the test is not data-enabled. 4) When running a test: If a test being run has the DataEnabled property disabled, and includes a test step which relies on using a coded variable, throw an error instead of silently passing. 5) When running a test: If a test being run has the DataEnabled property disabled, and includes a screen element which relies on using a coded variable, throw an error instead of silently passing.