Check commands and field naming
Well done to Jens and Torsten on the progress of the manager and entry client.
I have a few questions. I see that there is a confirm field check in the manager, but appears to be applied to the field in question only. So if one wishes to make every field a confirm field, then such an edit would need to be made for every field. I wondered if there were plans to enable the user to set such a thing for the whole database by having it as a global setting. Similarly for a missing value (9999 might always be a missing value code). Another question is whether there any plans to enable chk files created in EpiData Entry to be imported into the manager and/or rec files containing such checks to be brought into the manager with the checks preserved (at present they are ignored). A final question concerns the pasting of a qes file into the manager which uses EpiData Entry automatic field naming (i.e. the curly brackets to define filed names) and whether this will be supported in the manager. At present, the brackets are ignored by the program.
Regards,
Neville
----------------------------------------- ************************************************************************** The information contained in the EMail and any attachments is confidential and intended solely and for the attention and use of the named addressee(s). It may not be disclosed to any other person without the express authority of the HPA, or the intended recipient, or both. If you are not the intended recipient, you must not disclose, copy, distribute or retain this message or any part of it. This footnote also confirms that this EMail has been swept for computer viruses, but please re-sweep any attachments before opening or saving. HTTP://www.HPA.org.uk **************************************************************************
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
participants (1)
-
epidata-list＠lists.umanitoba.ca