New test versions of EpiData Manager and EpiData EntryClient
Dear All.
Today we have released new test versions of both EpiData Manager (1.4.3.2) and EpiData EntryClient (1.4.3.1).
This release has two major focus points:
1) Handling the case where two users/programs tries to open the same file. 2) Make forms/windows behave uniformly in regards to storing position & size, and closing using shortcuts.
In addition a number of minor issue have been fixed and added:
With regards to (1) we have implemented a new principle to handle the case where two programs wants to access the same file simultaneously. This is done by maintaining a lock file (taking the name of the project file and adding a .lock as suffix), which contains the locking information. Keep in mind that this does not prevent two users from overwriting the same project file, but the programs have a much better chance of detecting a possible problem before it even arises.
We have tested the lock file system extensively and found it more reliable than the current method, which basically just checks the timestamp of the project. However since it is a very new feature some issues may still exist so if you experience any problems please report the problems on this mailing list or to the bugtracker:
http://www.epidata.info/flyspray/
The complete list of changes
Both programs: * All forms can be closed using ESC, and positions & sizes are kept on close. * Added a shortcut to browse data (Ctrl + D or Cmd + D) * The list of recent files is kept up-to-date, even if both programs are opened at the same time. * A short message is given when copying the version information to clipboard.
Manager: * Changed shortcut for "Extend Page" (Ctrl + Enter, Cmd + Enter) * Default field length for Integer field changed to 1 (was 2) * Other minor text changes in reports.
EntryClient: * Added shortcut to Print and Print With Data.
Please report comments and errors on this list, including version of the software in which you found the error.
The software is available from : http://www.epidata.dk/testing.php
If no major errors or bugs are reported the version 1.4.3 will replace the current public download version.
Regards
Torsten Christiansen and Jens Lauritsen Epidata Association, Denmark
Hi Torsten,
I probably will not get a chance to test the SPSS output for this version as my trial period expires tomorrow. However, the previous release did work for typical data files. The import fails for the example file included with EpiData, probably because of the RtL text in one record. Either that or there is a vertical bar in the data somewhere.
Jamie
On 2013-10-25, at 7:36 AM, epidata-list@lists.umanitoba.ca wrote:
Today we have released new test versions of both EpiData Manager (1.4.3.2) and EpiData EntryClient (1.4.3.1).
It would be good to know if the other SPSS users having problems with previous versions still have problems.
The data list command format in the sps file now looks like this: DATA LIST FILE = "/home/jens/data/bromar.1.3.txt" ENCODING="UTF8" FREE ("|") RECORDS = 1 / _DoubleEntry(F1) id(F4) sex(F1) error(F1) km(F3) kmgrp(F1) age(F2) agegrp(F2) dectime(F6.4) decgrp(F1) runok(F1) .
for the example bromar file. Notice, that the {} are no longer there.
regards Jens Lauritsen EpiData Association
On 25-10-2013 15:06, epidata-list@lists.umanitoba.ca wrote:
Hi Torsten,
I probably will not get a chance to test the SPSS output for this version as my trial period expires tomorrow. However, the previous release did work for typical data files. The import fails for the example file included with EpiData, probably because of the RtL text in one record. Either that or there is a vertical bar in the data somewhere.
Jamie
On 2013-10-25, at 7:36 AM, epidata-list@lists.umanitoba.ca wrote:
Today we have released new test versions of both EpiData Manager (1.4.3.2) and EpiData EntryClient (1.4.3.1).
EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
It might be useful to have an option in Manager to specify the delimiter, rather than force the use of a vertical bar. While this might seem to be a character that would never be used, it could be entered by mistake in a text field. This would be easy for an experienced SPSS user to track down, but an annoyance to the more casual user. <tab> as a delimiter would make sense, but that would make editing the .txt data file problematic. Jamie
On Oct 25, 2013, at 3:54 PM, epidata-list@lists.umanitoba.ca wrote:
It would be good to know if the other SPSS users having problems with previous versions still have problems.
The data list command format in the sps file now looks like this: DATA LIST FILE = "/home/jens/data/bromar.1.3.txt" ENCODING="UTF8" FREE ("|") RECORDS = 1 / _DoubleEntry(F1) id(F4) sex(F1) error(F1) km(F3) kmgrp(F1) age(F2) agegrp(F2) dectime(F6.4) decgrp(F1) runok(F1) .
for the example bromar file. Notice, that the {} are no longer there.
regards Jens Lauritsen EpiData Association
In addition, vertical bar is obtained directly only on QWERTY keyboard, it may cause problems on AZERTY keybord...
Gilles
*Dr Gilles DESVE Epiconcept consultant Mobile : 33 (0)6 87 73 50 88 Fax : 33 (0)9 72 12 20 81 *
2013/10/26 epidata-list@lists.umanitoba.ca
It might be useful to have an option in Manager to specify the delimiter, rather than force the use of a vertical bar. While this might seem to be a character that would never be used, it could be entered by mistake in a text field. This would be easy for an experienced SPSS user to track down, but an annoyance to the more casual user. <tab> as a delimiter would make sense, but that would make editing the .txt data file problematic. Jamie
On Oct 25, 2013, at 3:54 PM, epidata-list@lists.umanitoba.ca wrote:
It would be good to know if the other SPSS users having problems with
previous versions still have problems.
The data list command format in the sps file now looks like this: DATA LIST FILE = "/home/jens/data/bromar.1.3.txt" ENCODING="UTF8" FREE ("|") RECORDS = 1 / _DoubleEntry(F1) id(F4) sex(F1) error(F1) km(F3) kmgrp(F1) age(F2)
agegrp(F2)
dectime(F6.4) decgrp(F1) runok(F1) .
for the example bromar file. Notice, that the {} are no longer there.
regards Jens Lauritsen EpiData Association
EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
Hi All.
The major problem with the SPSS export is choosing a delimiter that :
a) Does not have a multi-byte UTF-8 encoding (it must be a regular ASCII character, eg. ¤ or does NOT work) b) It must be a character the normally is not used in text entry (or as separator for date, time, etc.)
In regards to b) the main issue is that the delimiter cannot be part of the data, not even if it is enclosed in quotations. Since a text field in EpiData may contain ANY kind of data (that includes all visible UTF-8 characters), I chose the vertical bar "|" to be the on LEAST likely to be used as part of a text field.
I know this is not a perfect solution, but in all fairness I consider the SPSS import to very buggy considering that not even text in quotations can contain the delimiter.
Regards, Torsten Bonde Christiansen. EpiData Association.
On 2013-10-26 02:27, epidata-list@lists.umanitoba.ca wrote:
It might be useful to have an option in Manager to specify the delimiter, rather than force the use of a vertical bar. While this might seem to be a character that would never be used, it could be entered by mistake in a text field. This would be easy for an experienced SPSS user to track down, but an annoyance to the more casual user. <tab> as a delimiter would make sense, but that would make editing the .txt data file problematic. Jamie
On Oct 25, 2013, at 3:54 PM, epidata-list@lists.umanitoba.ca wrote:
It would be good to know if the other SPSS users having problems with previous versions still have problems.
The data list command format in the sps file now looks like this: DATA LIST FILE = "/home/jens/data/bromar.1.3.txt" ENCODING="UTF8" FREE ("|") RECORDS = 1 / _DoubleEntry(F1) id(F4) sex(F1) error(F1) km(F3) kmgrp(F1) age(F2) agegrp(F2) dectime(F6.4) decgrp(F1) runok(F1) .
for the example bromar file. Notice, that the {} are no longer there.
regards Jens Lauritsen EpiData Association
EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
Den 2013-10-28 10:39 skreiv epidata-list@lists.umanitoba.ca:
In regards to b) the main issue is that the delimiter cannot be part of the data, not even if it is enclosed in quotations. Since a text field in EpiData may contain ANY kind of data (that includes all visible UTF-8 characters), I chose the vertical bar "|" to be the on LEAST likely to be used as part of a text field.
How about using character 0x1E (30) or 0x1F (31) instead. They were *designed* for precisely this problem: http://en.wikipedia.org/wiki/Delimiter#ASCII_delimited_text
On 2013-10-28 13:24, epidata-list@lists.umanitoba.ca wrote:
Den 2013-10-28 10:39 skreiv epidata-list@lists.umanitoba.ca:
In regards to b) the main issue is that the delimiter cannot be part of the data, not even if it is enclosed in quotations. Since a text field in EpiData may contain ANY kind of data (that includes all visible UTF-8 characters), I chose the vertical bar "|" to be the on LEAST likely to be used as part of a text field.
How about using character 0x1E (30) or 0x1F (31) instead. They were *designed* for precisely this problem: http://en.wikipedia.org/wiki/Delimiter#ASCII_delimited_text
That is true, but then you would have the problem with non-displaying characters in a file/text editor - leading to strange symbyls like a square (in Windows) or a questionmark (in eg. Linux). IMHO that is a less desired alternative that using a visible, but infrequently used symbol.
Regards, Torsten Christiansen EpiData.
Because SPSS software expects the .sps file to be readable by a human and editable by software, choice of a delimiter is really limited to visible characters that can be created with a keyboard. Localization of data requires UTF-8 coding of text, which is handled badly by SPSS in any format other than delimited.
I think that the Epidata team has chosen a good compromise.
Jamie
On Oct 28, 2013, at 8:47 AM, epidata-list@lists.umanitoba.ca wrote:
On 2013-10-28 13:24, epidata-list@lists.umanitoba.ca wrote:
Den 2013-10-28 10:39 skreiv epidata-list@lists.umanitoba.ca:
In regards to b) the main issue is that the delimiter cannot be part of the data, not even if it is enclosed in quotations. Since a text field in EpiData may contain ANY kind of data (that includes all visible UTF-8 characters), I chose the vertical bar "|" to be the on LEAST likely to be used as part of a text field.
How about using character 0x1E (30) or 0x1F (31) instead. They were *designed* for precisely this problem: http://en.wikipedia.org/wiki/Delimiter#ASCII_delimited_text
That is true, but then you would have the problem with non-displaying characters in a file/text editor - leading to strange symbyls like a square (in Windows) or a questionmark (in eg. Linux). IMHO that is a less desired alternative that using a visible, but infrequently used symbol.
Regards, Torsten Christiansen EpiData. _______________________________________________ EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
participants (1)
-
epidata-list＠lists.umanitoba.ca