Comments on: Parenting with Stata http://enoriver.net/index.php/2009/08/30/parenting-with-stata/ computing for fun and profit Wed, 18 Apr 2012 00:10:24 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Gabi Huiber http://enoriver.net/index.php/2009/08/30/parenting-with-stata/comment-page-1/#comment-1582 Gabi Huiber Mon, 31 Aug 2009 20:36:07 +0000 http://enoriver.net/?p=903#comment-1582 At the Stata conference in DC in July, Sergiy Radyakin gave a great presentation on how he tweaked Stata graphics to make graphs show patterns for true black-and-white printing (right now, Stata graphs only do solid colors, which in monochrome appear as different shades of gray, which works OK with the better printers we have these days). Sergiy accomplished this with the use of a few hidden commands, and he wondered aloud why they were hidden. I quote from memory, but Bill Gould gave him two reasons I remember. One is that though StataCorp uses these commands internally, it deems them of too little use to the typical customer to be worth documenting and maintaining. The other is that undocumented commands can be dropped or changed as needed. My guess is that the broken examples you mention made some clever use of such hidden commands that now work differently, or are gone for good. I expect that Numerics with Stata will open up all sorts of opportunities for third-party developers to build and sell stuff like data-entry GUI solutions. I agree that using do-files the way I did is unsatisfactory for field use. At the Stata conference in DC in July, Sergiy Radyakin gave a great presentation on how he tweaked Stata graphics to make graphs show patterns for true black-and-white printing (right now, Stata graphs only do solid colors, which in monochrome appear as different shades of gray, which works OK with the better printers we have these days). Sergiy accomplished this with the use of a few hidden commands, and he wondered aloud why they were hidden. I quote from memory, but Bill Gould gave him two reasons I remember. One is that though StataCorp uses these commands internally, it deems them of too little use to the typical customer to be worth documenting and maintaining. The other is that undocumented commands can be dropped or changed as needed.

My guess is that the broken examples you mention made some clever use of such hidden commands that now work differently, or are gone for good.

I expect that Numerics with Stata will open up all sorts of opportunities for third-party developers to build and sell stuff like data-entry GUI solutions. I agree that using do-files the way I did is unsatisfactory for field use.

]]> By: Eric A. Booth http://enoriver.net/index.php/2009/08/30/parenting-with-stata/comment-page-1/#comment-1571 Eric A. Booth Sun, 30 Aug 2009 18:28:59 +0000 http://enoriver.net/?p=903#comment-1571 Thanks Gabi, great post. I've recently been thinking a lot about Stata as a data entry tool and your post is an example of how to accomplish this. However, data entry via a do-file can be tedious & error-prone when: 1) the number/type of entries is large and 2) the person entering the data has little experience with Stata do-files. I am running into this problem where I give a data entry task to some research assistants who are not familiar with Stata do-files. I just end up creating a data entry screen in Excel (using the "Validation" tool) or by creating an online survey tool that is really just a controlled data entry screen. Then I import the data from these files, clean them up, and run the analysis. An additional challenge comes in when I am working on a client's remote secure server where they allow access to Stata or R, but not to MS programs or the internet. I wish there were a data entry screen, much like the one available in MS Access, so that the novice user could easily input data directly into a Stata dataset. I have found an old article and reference to the Stata user programs -winshow- -winset- and -diablo- which appear to work together to create a data entry screen using the stata dialog boxes -db- environment. However, it appears that these have not been updated in quite a while & when I try to run these on auto.dta, I get the error "control not allowed r(101)". -Trace- reveals that the error comes after the program issues the command -- window control clear-. Admittedly, I haven't yet put much time in trying to resolve this error or get into the source adofiles. DM63 in this PDF ( http://www.stata.com/products/stb/journals/stb46.pdf ) has a good explanation about the utility & capabilities of -winshow- and -winset-, but again I cannot get the examples to work. My suspicion is that it has something to do with features in Stata's -window programming- and -db- commands that have changed since it's creation & therefore broken -winshow- and -winset-. Anyways, I thought that this program, if someone could get it to work, would be ideal for repetitive data entry much like you've described, especially for novice user, & that this is a feature that is sorely missing from Stata. I've considered posting a question on Statalist when I've had a chance to dig deeper into the problems and made better attempts to come up with a working solution. Thanks Gabi, great post. I've recently been thinking a lot about Stata as a data entry tool and your post is an example of how to accomplish this. However, data entry via a do-file can be tedious & error-prone when:
1) the number/type of entries is large and
2) the person entering the data has little experience with Stata do-files.

I am running into this problem where I give a data entry task to some research assistants who are not familiar with Stata do-files. I just end up creating a data entry screen in Excel (using the "Validation" tool) or by creating an online survey tool that is really just a controlled data entry screen. Then I import the data from these files, clean them up, and run the analysis.
An additional challenge comes in when I am working on a client's remote secure server where they allow access to Stata or R, but not to MS programs or the internet. I wish there were a data entry screen, much like the one available in MS Access, so that the novice user could easily input data directly into a Stata dataset. I have found an old article and reference to the Stata user programs -winshow- -winset- and -diablo- which appear to work together to create a data entry screen using the stata dialog boxes -db- environment. However, it appears that these have not been updated in quite a while & when I try to run these on auto.dta, I get the error "control not allowed r(101)". -Trace- reveals that the error comes after the program issues the command -- window control clear-. Admittedly, I haven't yet put much time in trying to resolve this error or get into the source adofiles.

DM63 in this PDF ( http://www.stata.com/products/stb/journals/stb46.pdf ) has a good explanation about the utility & capabilities of -winshow- and -winset-, but again I cannot get the examples to work. My suspicion is that it has something to do with features in Stata's -window programming- and -db- commands that have changed since it's creation & therefore broken -winshow- and -winset-.

Anyways, I thought that this program, if someone could get it to work, would be ideal for repetitive data entry much like you've described, especially for novice user, & that this is a feature that is sorely missing from Stata. I've considered posting a question on Statalist when I've had a chance to dig deeper into the problems and made better attempts to come up with a working solution.

]]>