Neville Verlander posted three good design issue questions. Some of this has been decided and other not yet settled completely, but we have an indication of what will be the situation:
1. Will there be a possibility to define properties for fields at the project or database level ? Exemplified by missing values and confirm field.
1a Regarding "confirm fields". Confirm as well as "entry mode" are single properties. For these we will consider an easy way of applying same definition for all fields.
1b The missing value implementation is now part of the value label definition.
The easy way to apply file wide properties such a missing value of 9999 with the current implementation is: a define a value label - say "miss9999" -with one numeric input marked as missing, e.g. 9999. b apply that "valuelabel" to one field c. add a range to that same field. e.g. 1 - 900 d. while the field is active (focused) press ctrl+c e. move cursor to all other relevant fields one by one and press ctrl+v this will copy as well the range as the missing value definition to these other fields.
We will discuss internally how to allow for simplified definitions of missing value status properties for several fields. But most likely this will not be changed in version 1.
2. import of chk files. The decision here is rather clear. - all recfiles can be imported and all data will be secured - for chk files containing labels in a block - these labels will be imported into the project, but not assigned to the fields - for other chk commands there will be NO import
An easy way of securing import of data and maintaining all value labels attached to all fields is to do this: a In EpiData Entry export the data to Stata format (any version) b In the manager import or add structure from that file.
If other chk commands should be imported we would have to make a new chk file parser and interpreter. The time to do this is better spend on issues of future function.
3. Regarding "paste as qes" including aspects, such as first word or automatic field naming and the use of curly brackets {}:
"Paste as" functionality will be available in the Manager - obviously. For instance: say you have 10 questions of food items "did you eat ....." in a questionnaire document, then you could just mark these as a block and in "edit" choose the "paste as integer" - in this way you can quickly create many items by pasting fields onto the form based on information on the clipboard.
However we expect to remove the "paste as qes" from the next test release, since there is an overall need of clarification and simplification. The extended definition contained in a qes file will be replaced by the possibility to define templates (see point 4 below):
Users wishing to continue the use of qes file and curly bracket principles will then have to: a. Create rec files in EpiData Entry b. Import the rec file into the manager.
The time we should spend on accepting paste as qes is far better used for other aspects of the revised software.
4. EpiData Template A new extended definition for creation of xml structures has been developed and the first internal tests are now ongoing. The idea will be, that a complete datafile structure, including value label, range, and sections can be made from a "white space" separated flat file. The addition is a reflection and consequence of suggestion from the project collaborations with MSF (www.msf.org) and a specific outbreak toolbox project financed from the European Union ECDC office. More information on this will come later.
regards
Jens Lauritsen EpiData Association