[EpiData-list] New EpiData Manager ready for (next) test

epidata-list at lists.umanitoba.ca epidata-list at lists.umanitoba.ca
Sat Jan 23 07:38:07 CST 2010


Good to see comments from users yesterday. I wish to comment on one of
them, which is the conversion from EpiData Entry (qes/chk/rec) to Epidata
Manager (recxml). 

It is of utmost importance that the basic way of working is NOT changed.
But also that we most do some changes to accomplish new possibilities such
as MAC/Linux versions or GCP compliance.

Jamie Hockin writes:
> - editor does not mind that a file is open in Manager (good!), but each 
> should recognize when a file has been changed by the other
> 
Let me expand on this issue. The decision just now is:
a. reading of QES files directly and/or pasting from the editor or
clipboard onto the data form (with subsequent saving in files) is
supported. (and errors in relation to this fixed).

b. The data form contains definitions for the structure and metadata
(labels etc) of a file. These definitions can be shown at any time in the
"view structure" form, which is activated by the right most button in the
toolbar, when a data form is shown. (Will get a function key). 

c. If any change is made on the data form, then the "view structure" is
updated.

e. Any change in the editor will NOT result in changes in other places,
such as the data form. Unless the user actively "pastes" these onto the
data form.

To support the current users - the editor has an easy way of creating data
forms by pasting contents onto a data form. This pasting is the same as
when we previously first saved a qes file, then created a rec file, and if
we changed the qes file, we would have to go into "enter data" before the
rec file changed. With the new manager we skip 2 steps in this. Steps which
often gave me trouble when teaching. 

We will implement (later) a conversion from the data form to a text based
representation, e.g. "Data form to qes" or "data form to rec file" - but
this is going to be a "one-way" route in the same manner as we can "import
a qes or rec file". Import/Export must be possible, but if we limit
ourselves to a 1:1 correspondance btw. data form (recxml) and old data file
(rec+qes) it will create other problems.

Jamies other suggestions of having labels before and after the entry
fields or possibility to define help notes in each field are good ones for
implementation later. Previously it was not that easy to define such
aspects and if we find an easy way of implementing this more users will be
encouraged to change to the new principles. 

Please give more comments, also on the choice of which current chk file
commands we should maintain as "core checks" and which ones are for the
more experienced. 

regards
Jens Lauritsen
EpiData Association


More information about the EpiData-list mailing list