Those of you with Windows 8 machines will soon find out that creating or running data entry applications using version 5.0.1 will cause CSPro to crash. We've fixed the problems, which will soon go out in the 5.0.2 release, but in the meantime, you can find out how to work around the problems in the CSPro Users forum.

Finally, the Unicode version of CSPro has been released. Thanks to all beta testers who worked with early versions of the software. The following is from the release email:

This version has some significant improvements:

• Internationalization. CSPro now has full support for non-Latin languages (Unicode). This is a large change to CSPro and even affects users who use only Latin languages. Read the "Unicode Primer" in the help documentation for more information on how this change will affect you.
• Data and specification files are saved in UTF-8 encoding instead of ASCII/ANSI format.
• New multiline alpha fields, useful for addresses, memos, or notes.
• The tick marks on alpha fields can be removed to support scripts with connecting features, such as Arabic, or scripts where multiple keystrokes comprise one character, such as Devanagari.
• Users can modify the font used in the CSPro Designer.
• A PDA (PocketPC) version is no longer supported.

Download the new version here, and as always, you can get older versions on the Software page.

One feature long-requested of CSPro has been the ability to select multiple fields and change the properties for all the fields at once. Now, with CSPro 5, you can do this. Highlight the fields using the mouse and then right-click and select "Properties," or use the shortcut to bring up the properties box: Alt+Enter. You will see this dialog box:

Selecting options will apply the changes only to fields that can accept such a change. For example, a numeric field will ignore the setting for "Upper Case."

Changing the data capture type for a group of fields all at once is really useful when working on CAPI surveys.

The Pack Application tool has a new feature: "Include Input Data Files":

Selecting this option will read the PFF for your application, if one exists, and include in the zip file the input data files that are referenced in the PFF. If you are running a large data entry operation with many data files, this may be of limited use, but if you are entering data for a small survey, you may only have one data file, and this option allows you to easily encapsulate all the important files for your application.

A longstanding debate among CSPro programmers concerns the naming convention to use when adding items to a dictionary. For example, you might have five questions: name, relationship, sex, age, and marital status. One approach is to match the item name to the question topic, like:

• NAME
• RELATIONSHIP
• SEX
• AGE
• MARITAL_STATUS

This can lead to very long names though. For example, you might ask: children ever born [males alive], children ever born [females alive], children ever born [males dead], children ever born [females dead], and so on. Having a name like CHILDREN_EVER_BORN_MALE_ALIVE is very descriptive, but typing it in logic is very cumbersome.

Another approach is to use the question number for the name, so the above might be something like:

• P01
• P02
• P03
• P04
• P05

These short names are very easy to type in logic so they are useful in batch programming, but they are cryptic to people who are looking at your code for the first time.

A third approach is a hybrid, combining the question number and the variable name:

• P01_NAME
• P02_RELATIONSHIP
• P03_SEX
• P04_AGE
• P05_MARITAL_STATUS

The advantage of this approach is that, unlike the first approach, it is easy to identify what section in the questionnaire each item comes from (P = population), but the downside is the names are the longest of all approaches.

I personally program using the second approach. I find that when you are working on a survey or census for weeks or months on end, after just a short time you will know the questionnaire contents in and out, and you will know what P03 is versus P23 versus H15. When I am writing batch edits, I like that I can write short names for the variables. However, if distributing a dictionary with the data set, I might create a duplicate CSPro dictionary with longer and more descriptive item names.

CSPro 5 has a feature, aliases, that simplifies this dilemma. If you want to use both long and short names, you can alias a shorter name to a longer name. An alias is another way to refer to the item in logic. This means that you can create your dictionary using long descriptive names and then use short names in logic. For example:

This code would be placed at the top of your logic in the PROC GLOBAL section. After the alias statement, P04 and P04_AGE are interchangeable in the code. Any "symbol" in logic can be aliased, including item and record names, form and group names, and working storage variables. Only one alias can exist for each symbol though.