- EpiData-list - University of Manitoba Mailing Lists

RE: [EpiData-list] best text editor for complicated check files
by epidata-list＠lists.umanitoba.ca 20 Aug '06

20 Aug '06

I usually use EpiData itself, just by opening the CHK file under FILE, OPEN, and select the relevant file from all the files in the epidata working directory (make sure you select the correct file extension). For me the EpiData text editor works perfectly fine. I write all my check files from scratch and they are often very long and complicated. I do not use the check module and it has never occurred that comment lines were stripped away. Hope this is useful. Happy writing and best regards, Dr Henrica A.F.M. (Henriette) Jansen Epidemiologist, WHO Multi-country Study Violence against Women Department of Gender, Women and Health Tel direct: +41 22 791 3106 Fax direct: +41 22 791 1585 Mobile: +41 78 730 3035 E-mail: jansenh(a)who.int Website: http://www.who.int/gender/violence/multicountry/en/ -----Original Message----- From: epidata-list(a)lists.umanitoba.ca [mailto:epidata-list@lists.umanitoba.ca] Sent: 18 August 2006 21:36 To: epidata-list(a)lists.umanitoba.ca Subject: Re: [EpiData-list] best text editor for complicated check files I use Notepad for editing check files, although not necessarily creating them from scratch since it's easy to do from the check module. If there are repetitive checks in the file, I find it easier to use Notepad using cut-and-paste for complicated checks. One thing to note: if you like to have a lot of internal documentation in check files and you subsequently alter checks from the check module, comment lines in the .chk file get stripped away. epidata-list(a)lists.umanitoba.ca wrote: I am looking for a recommendation for a text editor that support Epidata check file language. Suggestions? Karen Wang Earth Institute at Columbia University 61 Route 9W P.O. Box 1000 Palisades, NY 10964 _______________________________________________ EpiData-list mailing list EpiData-list(a)lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list --------------------------------- Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta.

1 1

Efficient strategy for complicated check files (external editor)
by epidata-list＠lists.umanitoba.ca 19 Aug '06

19 Aug '06

1. Re: best text editor for complicated check files The problem of "stripping comments" is that essentially only actual commands are read into the programme. When writing (or exporting) a rec file then only lines with commands are known to the programme. Therefore the order of using Epidata Entry and external editor is important. An efficient strategy would be: a. Create the qes and rec file b. Open the rec file for definition of checks in EpiData Entry. Here it is easy to get copy and paste for all of the field names. E.g. 1. I define that one field must be mustenter (regardless of I wish to have this). 2. When that field is active I press Ctrl+C (which copies the mustenter status to a buffer like clipboard) 3. Then I can quickly get a block for all fields into the check file by: 3a Moving to next field with "arrow down" with my right hand 3b pressing Ctrl+V with my left hand 4. Once point 3 is done for all fields I see if any fields have the same "comment legal / value label" if so I repeat point 1-3, but instead of the "mustenter" I define the labels in the first field and similarly copy to all the other fields of same label. 5. Then I close Epidata Entry and open the chk file in an external editor I prefer PFE, which has also a macro facility and is listed as a utility on the download page. But any external editor of the users preferance will work. 5a. I then change the special blocks in the editor, save the file and keep the editor open. 5b. During this I add a lot of comments to the chk file. 6. In EpiData Entry I open the rec file and after correcting possible errors the system is ready. So in short, use a strategy which minimises key strokes and manual editing, but also note that there are limitations with the built in possibilities. The worst errors to catch are those due to improper blocks. E.g. a comment legal without "end" or similar. Therefore it can be good practice to only solve the first error mentioned by EpIData Entry (point 6 above) and then try again, since the remaining errors might be a consequence of the first one. An idea for extension of the programme would be to have in "tools menu" a point : "Create raw chk file for experienced users". Regards Jens Lauritsen EpiData Association

1 0

Date/ Date Range Selection
by epidata-list＠lists.umanitoba.ca 18 Aug '06

18 Aug '06

Dear Jamie, Thanks for the effort and time. I tried the TRUE FALSE option instead of Y and N , no luck. The examples you provided, were for European date format <dd/mm/yyyy> Actually the applications developed in EPI6 were running for many years. EPI6 liked <mm/dd/yyyy> format. So the data entered over many years had actually American <mm/dd/yyyy> format. I defined a new variable , AATDATE2 <dd/mm/yyyy> format, copied and converted American dates data to <dd/mm/yyyy>. Your last suggestion PQ= (ATTDATE2 >=DMY(1,1,2006) AND (ATTDATE2 <=DMY(30,3,2006) worked then. Epi Analysis does not feel comfortable with American date format. I am not professional programmer but still strongly feel that date/ date range selection should be simple and intuitive. Rather than posting fresh message, I request you to kindly help to solve following two queries also; 1.What is the EPI ANALYSIS equivalent of EPI6 command SET PROCESS=BOTH. EPI ANALYSIS processes only undeleted records. 2. While running long PGMs in EPI ANALYSIS, if no records are selected after a select condition, the programme aborts. The rest of the commands of the PGM are not processed. You might remember, EPI6 could run PGMs of any length, closing database, recoding, erasing and writing new .rec files easily. Jens and his Epidata Team have done a marvelous job of preserving the functionality of EPI6. May be few fine tuning are still required in this good effort. With regards Dr. Shavinder Singh Department of Community Medicine

1 1

Date Range selection in Epi Analysis
by epidata-list＠lists.umanitoba.ca 16 Aug '06

16 Aug '06

Dear Jens, I am trying to use Epi Analysis for the Tuberculosis data analysis. I wrote following PGM. The date formats are American (mm/dd/yyyy). The ATTDATE variable is the date of starting of Anti-tuberculosis treatment. I want to select a date range of last 3 months to see the patients put on treatment in the last quarter. This selection should provide "y" value to the PG variable defined. The error messages received on the EpiAnalysis screen after running the command given, are given below; *TBQ.PGM (Updated on 15th August 2006) *Program gives the QUARTERLY status report of Tuberculosis of area. READ "d:\epi6\FGTRY\TB2000.REC" SET STATISTICS=OFF *Types the DATE RANGE of ATTDATE 3 months prior to beginning of present Quarter. *defines the time interval of 3 months prior to present Quarter. DEFINE PQ <Y> IF ATTDATE > date("01/01/2006","mdy") AND < date("03/30/2006",mdy") THEN LET PQ="Y" ELSE LET PQ="N" Error Massages in Epi Analysis; Syntax Error Script resulted in errors Operation aborted IF (ATTDATE > date("01/01/2006","mdy")) AND (ATTDATE < date("03/03/2006","mdy")) THEN LET PQ="Y" ELSE LET PQ="N" Error Massages in Epi Analysis; Data type mismatch IF ATTDATE date("01/01/2006","mdy") AND ATTDATE < date("03/30/2006","mdy") THEN LET PQ="Y" ELSE LET PQ="N" Error Massages in Epi Analysis; Then is missing Script resulted in errors Operation aborted SET STATISTICS=OFF *End of PGM. I tried these command combinations one by one but bot no luck. The date ranges selection has been a tough challenge. The F1 help section also has no clue. Kindly help. Dr. Shavinder Singh Department of Community Medicine

1 1

Alignment Problem----Last Time
by epidata-list＠lists.umanitoba.ca 09 Aug '06

09 Aug '06

Dear Jens, Thanks so much for the time you took to respond to my concerns re alignment in ED. Now that I understand the technical problems you face in modifying the 'look' of the data entry screens, I will keep my mouth shut. I did not mean to give the impression in my original message that I will not continue to use ED. There are so many wonderful features you guys have developed on top of the EI features that you carried over that I will mess with the QES files to get the alignment I want. I have been using EI/ED for almost 20 years and have no intention of switching to anything else on earth, despite the fact that I have the resources to do so! There is simply nothing better, in my opinion, for epidemiologic studies and data. Thanks again Steve Blum $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ [EpiData-list] Aligning of fields and development priorities epidata-list at lists.umanitoba.ca epidata-list at lists.umanitoba.ca Fri Aug 4 16:27:42 CDT 2006 Previous message: [EpiData-list] Epidata alignment problem Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Steve has written about the: "Epidata alignment problem" The basic difference to remember from Epi Info v6 to EpiData and other windows based interface programmes is the change from character based to pixel based interface. The Epi Info screen V6 has 80 characters on aline which can either contain a space or some letter. Therefore what from simple logic could be phrased: (Quoted from Steve's mail:) "What EI does is remove the left bracket in field A and shift the REST OF THE LINE one space to the left. It then removes the right bracket from A and again shifts the REST OF THE LINE one space to the left. It then does exactly the same thing for field B. Everything would now be out of alignment with the next line, except that EI then adds two spaces IMMEDIATELY to the right of EACH field from which the brackets have been removed." is not simple in the Windows environment, because the width of a space is not easily attainable. The basic choice in developing EpiData could then be: a. We skip the rec file format altogether and create a new variant where alignments are measured in pixels instead of in characters. We develop a "drawing interface" where placements of fields are freely floatable. b. We maintain the rec file standard which has as a consequence that all sizes for the screen are measured in characters of variable width. The problem is that the header only allows for small numbers to describe placement of entry fields etc. c. We try to fiddle with a combination of calculations to estimate the length of "one space" and based on this use the REC file format as a basis of creating a "usually nice looking" entry screen. d. We add a new file type defining the exact positions of fields. e. We restrict choice of fonts to known types where alignment is possible. The point C is actually what we have done. The problem being that even with fixed size fonts the width of a space or a given letter is not very easy to calculate on a given screen. Many aspects of this is also bound to language. Some solutions are very good for one language, but not for other languages with special letters. EpiData Software is typically downloaded from nearly 100 countries every month, so to do development and accomplish only one or a few is not fair. Already basing all on the english language (and now website also in Spanish) is a restricted policy. E.g. obviously I would prefer that everything was written in my native language Danish, but only about 5 mio people speak that language. Users who have been along since 1999 will remember that in the beginning there were many problems of combinations of fields and texts which ended messed up/overlapped or hidden from the interface. So the current principle is a "parsimoneous" balance of different tests and principles creating exactly the alignment problems pointed out. So what are the solutions to the problem a. Someone find or develop very good algoritms which can in a standardised way replicate alignment properties and submit them to us. b. Persons who are very keen on this uses other software which is not tied to the limitations of the rec file format. There are plenty of commercial solutions to choose among. c. We find another solution. Option A: Anyone keen to experiment and spent time on this can find freeware tools at http://www.freepascal.org/ So the statement "If ED is indeed legacy EI then the face presented to the world should work properly." obviously is a very nice goal, but as mentioned not easy to attain. Focus is on the data entered NOT on the visual quality of the interface. The fact is that interface handling is a whole different story than: >But if there are resources for doing things like import/export, >pack, codebook, validate, consistency, compress, archive > which can all be handled by standard logic, and which tends not to be included in other software. What we have done with the EpiData development is to accomplish needs which we found possible and desirable within the time frame we had for this project. Data quality has the main driving priority - quality of alignment on screens has not. My suggestion is to add the issue "enhancements of data entry screen and design" to the development list for the plan 2006-2010. If someone are willing to find funding for this on top of the already planned activities it can be added, but otherwise it will not be added. Whether the patience of users of the software is sufficiently large for this approach or they decide on option B above is not up to me to decide. Kind regards Jens Lauritsen Initiator and Coordinator of development. EpiData Association Previous message: [EpiData-list] Epidata alignment problem Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the EpiData-list mailing list

1 1

Aligning of fields and development priorities
by epidata-list＠lists.umanitoba.ca 04 Aug '06

04 Aug '06

Steve has written about the: "Epidata alignment problem" The basic difference to remember from Epi Info v6 to EpiData and other windows based interface programmes is the change from character based to pixel based interface. The Epi Info screen V6 has 80 characters on aline which can either contain a space or some letter. Therefore what from simple logic could be phrased: (Quoted from Steve's mail:) "What EI does is remove the left bracket in field A and shift the REST OF THE LINE one space to the left. It then removes the right bracket from A and again shifts the REST OF THE LINE one space to the left. It then does exactly the same thing for field B. Everything would now be out of alignment with the next line, except that EI then adds two spaces IMMEDIATELY to the right of EACH field from which the brackets have been removed." is not simple in the Windows environment, because the width of a space is not easily attainable. The basic choice in developing EpiData could then be: a. We skip the rec file format altogether and create a new variant where alignments are measured in pixels instead of in characters. We develop a "drawing interface" where placements of fields are freely floatable. b. We maintain the rec file standard which has as a consequence that all sizes for the screen are measured in characters of variable width. The problem is that the header only allows for small numbers to describe placement of entry fields etc. c. We try to fiddle with a combination of calculations to estimate the length of "one space" and based on this use the REC file format as a basis of creating a "usually nice looking" entry screen. d. We add a new file type defining the exact positions of fields. e. We restrict choice of fonts to known types where alignment is possible. The point C is actually what we have done. The problem being that even with fixed size fonts the width of a space or a given letter is not very easy to calculate on a given screen. Many aspects of this is also bound to language. Some solutions are very good for one language, but not for other languages with special letters. EpiData Software is typically downloaded from nearly 100 countries every month, so to do development and accomplish only one or a few is not fair. Already basing all on the english language (and now website also in Spanish) is a restricted policy. E.g. obviously I would prefer that everything was written in my native language Danish, but only about 5 mio people speak that language. Users who have been along since 1999 will remember that in the beginning there were many problems of combinations of fields and texts which ended messed up/overlapped or hidden from the interface. So the current principle is a "parsimoneous" balance of different tests and principles creating exactly the alignment problems pointed out. So what are the solutions to the problem a. Someone find or develop very good algoritms which can in a standardised way replicate alignment properties and submit them to us. b. Persons who are very keen on this uses other software which is not tied to the limitations of the rec file format. There are plenty of commercial solutions to choose among. c. We find another solution. Option A: Anyone keen to experiment and spent time on this can find freeware tools at http://www.freepascal.org/ So the statement "If ED is indeed legacy EI then the face presented to the world should work properly." obviously is a very nice goal, but as mentioned not easy to attain. Focus is on the data entered NOT on the visual quality of the interface. The fact is that interface handling is a whole different story than: >But if there are resources for doing things like import/export, >pack, codebook, validate, consistency, compress, archive > which can all be handled by standard logic, and which tends not to be included in other software. What we have done with the EpiData development is to accomplish needs which we found possible and desirable within the time frame we had for this project. Data quality has the main driving priority - quality of alignment on screens has not. My suggestion is to add the issue "enhancements of data entry screen and design" to the development list for the plan 2006-2010. If someone are willing to find funding for this on top of the already planned activities it can be added, but otherwise it will not be added. Whether the patience of users of the software is sufficiently large for this approach or they decide on option B above is not up to me to decide. Kind regards Jens Lauritsen Initiator and Coordinator of development. EpiData Association

1 0

Epidata alignment problem
by epidata-list＠lists.umanitoba.ca 03 Aug '06

03 Aug '06

Dear Jamie Thanks for your response to my alignment problem. Unfortunately, neither solution offered is acceptable. Using one field per line is unmanageable when you have hundreds of fields. Using the '@' method, if you can figure out the pixel business, results in entry fields that are aligned, but the associated text is scattered all over the place and may be on different lines. The data entry screens and printed forms are the public face of ED. If ED is indeed legacy EI then the face presented to the world should work properly. Otherwise, either the QES file must be intentionally misaligned or the REC file will not be acceptable. But then the QES file is a mess. It seems to me that the code can be changed to correct this problem as indicated in my original message(see below). If it cannot be corrected, I would appreciate it if someone on the development team would let me know so I can switch to something else and be done with this problem. If it can be corrected, will it be? I understand and appreciate the enormous effort that has been expended by the team. But if there are resources for doing things like import/export, pack, codebook, validate, consistency, compress, archive ......., then how can the entry screens and printed forms remain unusable in a routine, typical manner? Steve ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DEAR Jens and Michael , I have delayed composing this letter for quite some time because I so much appreciate the efforts and accomplishments of the Epidata(ED) team over the years. I was one of the early users and continue to use ED extensively in our very many projects here at the hospital. My problem is that what I see in the QES file is not translated, as it appears, to the data entry screens in the REC file. In other words, the form is not WYSIWIG; in fact, what you see is NOT what you get. What you sometimes get in data entry screens are fields that are scattered all over and the allignment between the lines is comletely lost. This does not happen in EpiInfo(EI). This problem is not apparent in the sample files because they only have one item on a line. To see the misalignment, the QES file must have multiple lines and fields that use the brackets, such as date and boolean fields. I examined the header portion of the REC file generated by both EI and ED and they are essentially identical. The brackets and their conversion are the problem! Consider the following very simple QES file: A<mm/dd/yyyy>B<Y>C___ D___________ E___ F___ Note: the font may be changed by you email client. To see the point being made, letter D should be right under letter A, E should be right under B and F under C using a fixed-width font, such as 'courier new' with no spaces between the fields. I have six fields(A-F) and have intentionally placed B right after A and C right after B. If this file is converted to a REC file in EI, everything is aligned exactly as it appears above. If it is converted in ED, it is not. What EI does is remove the left bracket in field A and shift the REST OF THE LINE one space to the left. It then removes the right bracket from A and again shifts the REST OF THE LINE one space to the left. It then does exactly the same thing for field B. Everything would now be out of alignment with the next line, except that EI then adds two spaces IMMEDIATELY to the right of EACH field from which the brackets have been removed. In fact, if you look at the data entry screen in EI, you will notice that after shifting to the left as described above, two spaces now appear right after field A and two space appear right after field B, and this maintains the alignment with the lines below. ED does exactly the same shifting as EI, but fails to add two spaces to the right of each of these bracketed fields. Changing the font in ED data entry screens to fixed-width does not help. I develop QES files with hundreds of fields of all types, and bracketed fields hopelessly mess up the alignment in both the screen version and in printed forms. While I can now(since I figured it out) make these adjustments in the QES file to maintain alignment, I cannot recommmend ED to any of my less experienced colleagues because the entry screens and printed reports will look disorganized, resulting in a less aesthetic experience and more data entry errors. I must therefore either personally design every form (which I do not have time for), or have them use something horrible like Excel. EpiData is a splendid product and is indeed legacy EpiInfo because it maintains the elegant features of the latter, while adding many new and really useful ones. The loss of alignment between lines, however, sort of ruins things for me although it probably does not affect most users. If my analysis is correct, I hope the program can be modified relatively easily. If I am wrong, maybe you can’t do anything. Either way, thanks again for all you have done for the rest of us EpiInfo lovers. Sincerely Steve Blum, PhD Associate Professor Albert Einstein College of Medicine Dept of Epidemiology and Population Health Steve Blum Steve, If you want to line up the entry fields and are less concerned about the text around them, put @ before the entry field. It is quite easy, with minimal trial and error, to get the entry fields to line up. In my experience, most questionnaires align the spaces to capture text and with judicious use of spaces to separate field names/text, you can get a questionnaire on screen that is quite easy to use. We teach our field epidemiologists to enter data one field per line, for simplicity and because this produces a nice companion to the codebook (we suggest using "first word" for field names). However, I also liked the fixed font approach of EI when creating questionnaires. Over the years, we realized that data entry fields scattered across the page were not ideal and shifted to the single column (with exceptions where it makes a lot of sense). The help file with ED doesn't say much about @, but does point it out in the explanation of differences from EI. In your example, I tried this: A @<mm/dd/yyyy> B @<Y> C @___ D @___________ E @___ F @___ and, while E is not under B, the entry fields line up very nicely. When you add the field descriptions, it looks better. Some fields may need more than one @, or add spaces before the field name. I prefer to use 'First word' because the questionnaire then documents the field names. Your colleagues should be able to master this easily. A date goes here @<mm/dd/yyyy> B key y/n answer @<Y> C this is a name @___ D the address @___________ E diagnostic code @___ F outcome code @___ Jamie Hockin Public Health Agency of Canada

1 0

EpiData Entry: issue with numeric fields and legal values
by epidata-list＠lists.umanitoba.ca 02 Aug '06

02 Aug '06

Dear all, I have a problem with numeric fields of more than one digit in length, e.g. ##. All legal values (and their value labels) for the variables in my questionnaire are precoded in the CHK file. Currently, if a legal value is defined as "1", the data entry program does not accept "01" and vv: if a legal value is defined as "01" the data entry program does not accept "1". The typists usually type without looking the whole time at the screen so they prefer the legal values to be precoded 01, 02, 03 etc because if they enter "1" they would need to press ENTER before the cursor moves to the next field (which they do not need to do if the length of the field is one digit). Precoding "01" etc initially seemed to work fine, but as soon as the record is saved, when the typist needs to return to the same record, e.g. to make a correction, the value "01" is reflected as "1" on the screen, and when passing through this field again, e.g. to move to a part that is further down in the questionnaire, an error message pops up: "illegal entry", and the typists believe they should change the "1" again into "01". This is at times quite a bit of a nuisance. I think that one possible solution (I have not tried this yet) could be to define for all digits under 10 both "1", "2", "3" as well as "01", "02", etc as legal values (with the same value labels), but I think it is not very elegant. Is there another solution? PS. is there a command that can used in the CHK file to that after every entry the typist needs to press enter before the cursor moves to the next field? Thanks a lot, Henriette Dr Henrica A.F.M. (Henriette) Jansen Epidemiologist, WHO Multi-country Study Violence against Women Department of Gender, Women and Health Tel direct: +41 22 791 3106 Fax direct: +41 22 791 1585 Mobile: +41 78 730 3035 E-mail: jansenh(a)who.int Website: http://www.who.int/gender/violence/multicountry/en/

1 5

RE: EpiData 3.1 - Viewing value label in data entry window?
by epidata-list＠lists.umanitoba.ca 30 Jul '06

30 Jul '06

Thanks, I've worked it out... I needed to add this code to the start of the check file: BEFORE FILE TYPE COMMENT ALLFIELDS BLUE END cheers leanne. -----Original Message----- From: epidata-list-bounces(a)lists.umanitoba.ca [mailto:epidata-list-bounces@lists.umanitoba.ca]On Behalf Of epidata-list-request(a)lists.umanitoba.ca Sent: Saturday, 29 July 2006 3:06 AM To: epidata-list(a)lists.umanitoba.ca Subject: EpiData-list Digest, Vol 33, Issue 8 Send EpiData-list mailing list submissions to epidata-list(a)lists.umanitoba.ca To subscribe or unsubscribe via the World Wide Web, visit http://lists.umanitoba.ca/mailman/listinfo/epidata-list or, via email, send a message with subject or body 'help' to epidata-list-request(a)lists.umanitoba.ca You can reach the person managing the list at epidata-list-owner(a)lists.umanitoba.ca When replying, please edit your Subject line so it is more specific than "Re: Contents of EpiData-list digest..." EpiData-list mailing list ___________________________________ Today's Topics: 1. EpiData 3.1 - Viewing value label in data entry window? (epidata-list(a)lists.umanitoba.ca) 2. Re: EpiData 3.1 - Viewing value label in data entry window? (epidata-list(a)lists.umanitoba.ca) ---------------------------------------------------------------------- Message: 1 Date: Fri, 28 Jul 2006 11:22:52 +1000 From: epidata-list(a)lists.umanitoba.ca Subject: [EpiData-list] EpiData 3.1 - Viewing value label in data entry window? To: <epidata-list(a)lists.umanitoba.ca> Message-ID: <0FE7A7717D7DB745B5097135D3892EFD01CB09FC(a)accvnt71.accv.org.au> Content-Type: text/plain; charset=iso-8859-1 Hi there all! I have a question regarding viewing value labels when I'm in the data entry window of EpiData 3.1. In the booklet called "Introduction to EpiData" it said that 'blue explanatory text' based on labels in the check file is added to the right of the field by EpiData after data entry ... this is not happening in my file. Can anyone suggest why this might be? All of my files for the data are located in the same subfolder (ie. the qes, rec and chk files for the dataset are in the one folder). many thanks in advance, Leanne. ------------------------------ Message: 2 Date: Fri, 28 Jul 2006 09:46:12 -0400 From: epidata-list(a)lists.umanitoba.ca Subject: Re: [EpiData-list] EpiData 3.1 - Viewing value label in data entry window? To: epidata-list(a)lists.umanitoba.ca Message-ID: <44CA1524.4010402(a)binghamton.edu> Content-Type: text/plain; charset=ISO-8859-1 What sort of statement pertaining to the problematic variable(s) do you have in your check file? I've also noticed that in my version of EpiData, the blue text appears only after I tab or enter out of a variable, to the next one. Even if a record already has all its variables filled in, the blue text won't appear until I move to a variable and then tab/enter away from it. --Chris -- Christopher W. Ryan, MD SUNY Upstate Medical University Clinical Campus at Binghamton and Wilson Family Practice Residency, Johnson City, NY cryanatbinghamtondotedu GnuPG and PGP public keys available at http://pgp.mit.edu "If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea." [Antoine de St. Exupery] epidata-list(a)lists.umanitoba.ca wrote: > Hi there all! > I have a question regarding viewing value labels when I'm in the data entry window of EpiData 3.1. In the booklet called "Introduction to EpiData" it said that 'blue explanatory text' based on labels in the check file is added to the right of the field by EpiData after data entry ... this is not happening in my file. Can anyone suggest why this might be? All of my files for the data are located in the same subfolder (ie. the qes, rec and chk files for the dataset are in the one folder). > many thanks in advance, > Leanne. > _______________________________________________ > EpiData-list mailing list > EpiData-list(a)lists.umanitoba.ca > http://lists.umanitoba.ca/mailman/listinfo/epidata-list > ------------------------------ ________________________________________ EpiData-list(a)lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list End of EpiData-list Digest, Vol 33, Issue 8 *******************************************

1 0

EpiData 3.1 - Viewing value label in data entry window?
by epidata-list＠lists.umanitoba.ca 28 Jul '06

28 Jul '06

Hi there all! I have a question regarding viewing value labels when I'm in the data entry window of EpiData 3.1. In the booklet called "Introduction to EpiData" it said that 'blue explanatory text' based on labels in the check file is added to the right of the field by EpiData after data entry ... this is not happening in my file. Can anyone suggest why this might be? All of my files for the data are located in the same subfolder (ie. the qes, rec and chk files for the dataset are in the one folder). many thanks in advance, Leanne.

1 1