Copyright: © 1996-2009 Joerg M. Sigle - www.jsigle.com
Citation: Jörg M. Sigle's AnyQuest for Windows Help - © 1996-2009 - www.jsigle.com - www.ql-recorder.com - www.anyquest.de


Table of Contents

Welcome to Jörg M. Sigle's Quality-of-Life-Recorder and AnyQuest for Windows!

Preface

Acknowledgements

Before you continue to use this software, please read this License Agreement!

You can take advantage of registering this copy of the software!

A crash course: Essentials

Quick guide for users: How to install, prepare and use the Quality-of-Life-Recorder

Quick guide for designers and researchers: How to make your questionnaire go electronic and how to export data

Jörg's Magic Questionnaire-o-Matic: How to save a lot of time in the preparation of your electronic questionnaire

Basic information about the Quality-of-Life-Recorder

General information about this software

Easy to use - for doctors and patients

More details about the Quality-of-Life-Recorder

i.  	What appears on the screen

ii. 	More about objects...

iii.	Formulas: Skipping, jumping, calling, computation of results

iv. 	Jörg's Magic Questio-Morph-o-Matic

v. 	Configurable options

vi. 	Data storage, printout, retrieval, analysis, export and further processing

vii. 	Applying questionnaires

Delayed processing of paper questionnaires

Fast-Input-Form mode to record and score paper questionnaires

Advanced features to support the preparation of electronic questionnaires

Support of different display resolutions

Translation utilities

General editing tools

Faster editing with keyboard command sequences

Jörg's Magic Questionnaire-o-Matic

Intelligence is not a business of computers

Using prototype and anchor questions

Formula consistency check

Undo and crash recovery

Integrated support for documentation and questionnaire libraries

Questionnaire definition file copyright and history

Questionnaire definition file language and version

Preparing international environments

Other topics

Command line parameters

Temporarily available diagnostic commands

Data compression

AnyQuest for Windows and Linux, X11, Wine, KDE

Glossary - Nomenclature

Where do we go from here...?

How to get updates and how to re-distribute AnyQuest for Windows

Contact addresses, sources of further information and other references

What has been done and what will be: Product and document history

Additionall documentation and tutorials are available in the "Docs+Support" section of my WWW site at http://www.ql-recorder.com - especially, there are three PDFs from the eSIRO project (German language, with many images) which detail installation, customization, practical use and data analysis with the QL-Recorder. Additionally, the CD-ROM copy of the site provides several videos.

This document contains some trademarks which are owned by Intel, Microsoft, Apple, Adobe Systems, Linus Torvalds, Aladdin Software, Ghostgum Software.


Updates and re-distribution

Where do we go from here...?

How to get updates and how to re-distribute AnyQuest for Windows

How to get updates

How to re-distribute AnyQuest for Windows


Updates

Where do we go from here...?

How to get and install updates

Precautions

Before you consider updating, you should figure out the pros and cons of doing so. Without a good reason, stick to the primary rule of experienced computer folks: "Never change a running system!"

Before you install an update, please make a backup copy of your complete AnyQuest for Windows related files and directory structures. Be sure that you know what you are doing, especially, when you're going to overwrite customized configuration files or similar valuable files.

Please make sure that you do not accidentally overwrite a licensed version or self-made, customized initialization files or questionnaires with contents from an evaluation copy when you do not have a backup copy of the more important version!

Evaluation version

You can get the most recent evaluation version of AnyQuest for Windows in the following ways:

•	Download from my homepage in the WWW:

http://www.ql-recorder.com

http://www.anyquest.de

http://www.jsigle.com

http://www.jsigle.de

http://jsigle.cjb.net (outdated)

•	As attachment to an e-mail:

Ask me to send it to you.

•	If you do not have an Internet access, you can ask me to send you a disk.

At the moment, you need not, but in the future, you might have to send me a self addressed, stamped envelope and an empty disk.

•	There is a CD-ROM available, too. It contains copies of my own WWW-site and additional material, including my doctoral thesis about routine quality-of-life measurement in a university outpatient clinic with the original QL-Recorder.

For simple evaluation version settings, it will be most appropriate to proceed like in the previous installation and install the whole package via the automatic installation routine.

Licensed or personalized versions

If your license entitels you to this service, I will inform you whenever a major update of the software has become available. You may also receive this information if you are a member of a QL-Recorder mailing list. More information is available on my WWW site at http://www.ql-recorder.com

This information will also tell you, by which means and conditions the update is going to be distributed.

In most cases, it will be sufficient to overwrite the old files of anyquest.exe and anyquest.hlp with new versions; if questionnaire definition files are corrected, these files have to be updated respectively.

If you update an old personalized version, that did not carry its personalization information in an external anyquin.lic or *.lic file, please contact me and ask me to provide such a file for you.


Re-distribution

Where do we go from here...?

How to re-distribute AnyQuest for Windows

While you are not allowed to redistribute a personalized version of AnyQuest for Windows (namely any personalized *.lic files you may have received) except under the terms and conditions defined in this License Agreement, there are versions of AnyQuest available from its WWW-site which may be redistributed for evaluation purposes.

If the License agreement grants you such a right, you can perform a redistribution of its contents in a technical way similar to the one described for the evaluation version. In this case, you would apply them to demopak.exe instead of anypak.exe.

This section describes the technical details of such redistribution:

If you received it on a disk, you can use diskcopy for multiplication of this disk.

If you want to make a disk from what you downloaded, you should place the file anypak.exe onto the new disk.

If you want to include a reference in a Web page, please reference my homepage only, which is noted elsewhere in this help file. Please do not include a link to a copy of the package stored at another site, because that file might not be updated automatically.

If you want to send the package by e-mail, it might be easiest to send anypak.exe.

Thank you very much for your help spreading the concept of the Quality-of-Life-Recorder!


General information

Basic information about the Quality-of-Life-Recorder

General information about this software

About This Documentation

Overview: AnyQuest for Windows and its applications

Functionality of AnyQuest for Windows

Supported hardware

Supported operating systems


Take it easy

Basic information about the Quality-of-Life-Recorder

Easy to use - for doctors and patients

Installing AnyQuest

Starting AnyQuest

Running the fastest demonstration available

Basic handling concepts

Presenting questionnaires to a patient

Collecting patient identification data

How the patient handles AnyQuest for Windows

Generated Results

Keyboard support

»»Note on data storage and data protection««


What appears on the screen

More details about the Quality-of-Life-Recorder

i. What appears on the screen

General concepts

Electronic questionnaires

The file menu

The edit layout mode

The editing grid

The transport bar, simpler navigation buttons and anchors

Display options

Context menus

An alternative way to context menus

Objects

Available objects

Adding objects and using prototypes

Selecting objects

Manipulating and cloning objects

Deleting objects and clearing text

Text, numeric and text values, images and digitized sound

• Glossary - Nomenclature

• Quick guide to making and applying electronic questionnaires


More about objects

More details about the Quality-of-Life-Recorder

ii. More about objects...

Line breaks in text objects

The size of text objects

Colours and fonts

Digitized sound

Images

Question options

Answer field options

Additional text Input

Direct text Input


Behind the screen (1): Formulas

More details about the Quality-of-Life-Recorder

iii. Behind the screen (1): Formulas

AnyQuest's UPN formula definition language

Operating principles of AnyQuest's UPN (RPN) machine

UPN functions of AnyQuest for Windows and UPN debug mode

Skipping, Jumping, Calling...

General information about conditionally asked questions or modules

Conditional Branch Formulas and text inline formulas

Practical definition of Conditional Branch Formulas

Computation of questionnaire results (scoring)

Defining formulas to compute questionnaire results

More formula related features...

Automatic formula consistency check

Communication with external software

Inline formulas to compute text to be displayed on the fly

Pleae note: Data exchange with external applications, and calling of external applications to provide external data processing services, is technically possible from all places where UPN formulas can be used. Most commonly, however, it will be used to have questionnaires scored by an external program, or to interface with databases during questionnaire administration.

Please note: Dynamically morphing questionnaires, which can be realised using conditional branching formulas, as well as text inline formulas, are covered in a separate section further below.

• Data storage, printout, retrieval and further processing

• Multiple configurations

• Dynamically morphing questionnaires.


Configurable options

More details about the Quality-of-Life-Recorder

v. Configurable options

Display options

PC speaker sound

Digitized sound

Printer setup

*.anq output file options

Advanced options, multiple configurations, multilevel cascaded configuration files

Running multiple studies concurrently on one hardware system

Preparing international environments

Preparing a secure configuration

The UPN debug mode

Fast-Input-Form mode to record and score paper questionnaires


Applying questionnaires

More details about the Quality-of-Life-Recorder

vii. Applying questionnaires

The "AnyQuest Navigation" window

Automatic check, calculation, output & erase after the last question

Remove menu & start asking questions

Endless question asking = unattended kiosk mode

Interrupting a session and resuming it later

Preferred settings for the supplied quality-of-life questionnaires


Dehind the screen (2): Collected data

More details about the Quality-of-Life-Recorder

vi. Behind the screen (2): Collected data

Immediate and deferred printout, data storage and export

Printer setup

Selecting a data file folder

Question numbering and the output file data format

Changed output file contents compared to AnyQuest for MS-DOS

Printing simple cumulative statistics

Selecting results from earlier sessions, generating printouts and lists using built in statistical analysis tools)

Exporting the results to mathematical, statistical or database applications

Measurement of the duration to complete a questionnaire

Searching and viewing an individual patient's data

Marc-André Sigle's AnyQuery for Windows

Selecting, viewing, printing results from earlier sessions using built in Statistical Analysis tools

Integrated statistical analysis tools functionality

Selecting results from earlier sessions, generating printouts and lists

Statistical analysis of selected questionnaire administration results

Advanced information on data storage, integration and further processing

Detailed description of the output file format of AnyQuest for Windows *.anq files

Communication with external software

Hints for writing import routines into third party applications

»»Note on data storage and data protection««

• Formulas: Skipping, jumping, calling, computation of results

• Multiple configurations

• Running multiple studies concurrently on one hardware system

• Preparing a secure configuration


Contact addresses and other information

Where do we go from here...?

Contact address and other references

The Quality-of-Life-Recorder's author's address

IBSQOL contact addresses at Glaxo Wellcome plc.

EORTC contact addresses

Sources of further information

The Quality-of-Life-Recorder team

The eIBSQOL team

Literature reference


What has been done and what will be

Where do we go from here...?

What has been done and what will be

Known problems

QL-Recorder and AnyQuest for Windows product history

On-line Help document history


Preface

Before I write about any other topic, I would like to thank you for having a look at this software.

It makes me especially happy, because the motivation to program and to distribute it grew from the following ideas:

In my opinion, feedback is important to do anything well. Among others, the concept of measuring standardized subjective quality-of-life is an important way of getting feedback from patients. However, this has not traditionally been included in general medical practice, in contrast to measuring weight or blood pressure.

Usually, measuring quality-of-life is not exactly as common and as easy as reading a dial on scales or on a blood-pressure meter. Instead, it involves things like paper questionnaires and guidelines for their interpretation, maybe even using a calculator. And when it is measured, different instruments are applied in different manners. Often it seems to be difficult to get data of good quality, referring to patient compliance and questionnaire completeness. Resulting data of different origin are hardly easily comparable. In fact, apart from study results, the original data might hardly be available, because paper questionnaires can be lost, and data stored in computers might require the right expert to get them out again.

So the concept of the Quality-of-Life-Recorder has the following goal: To make quality-of-life measurement something for which there is a routine way to do it, which is cheap, which is feasible and the results of which can be easily retrieved, exchanged and compared.

This goal can only be achieved by spreading this idea widely among all researchers, and maybe among any medical professional. You reading these lines may now contribute to this spread. That is, why it makes me happy, and why I would like to thank you.

The term "Quality-of-Life-Recorder" was chosen to remind you of the image of any common tape recorder you know: It is a well defined unit, it performs a well defined task (which is recording), and it is easy to operate. Easy for the doctor, and easiest for the patient.

AnyQuest for Windows was designed to be used without any training by patients. It is built upon experience gained with my Quality-of-Life-Recorder for MS-DOS, which was already accepted extremely well by patients.

Even as an investigator, performing more difficult tasks than just filling in questionnaires, you might choose to use AnyQuest for Windows without consulting its manual. This is definitely feasible in the era of windows based computing. However, I've been programming already before this era. The extreme case might have been a product being called "broken-down", or "requiring a specialist" by someone, who never has had a look at its manuals. Of course, with exactly the same product bringing major benefit to other people, who may have had just one glance...

Even if you are a person with abundant computer experience, you might miss a bit of knowledge about the underlying concepts and some helpful hints, which otherwise might speed up your work. So I'd suggest you to read this manual.

If your time is actually extremely rare, just look at the introductory chapters and at the practical questionnaire examples you received with this package. Scan the table of contents - you might wish to read the more detailed chapters later and specifically when you require them.

Even giving the whole manual a quick look won't take very long. And although afterwards you still might not know all of AnyQuest's features by heart, you might know about what is there and where to look it up. Being so prepared, you'll let your favourite questionnaire go electronic in no time!

Because I love both, I added colour and sound support to AnyQuest for Windows just a little bit more than required. If you, however, would like to make suggestions about what to add to its functionality, or what to improve, or if you just want to comment on it, you are invited to contact me.

The project was started and brought to a usable state during my visit to Australia, 1996. I hope that all Australians among you are happy about this :-).

Jörg M. Sigle, Sydney, July 1996


Acknowledgements

I would like to thank the following persons and institutions, who contributed to this project:

Alan Coates, Associate Professor of Cancer Medicine at the Royal Prince Alfred Hospital in Sydney, who, by supplying the machine and the setting to use it, enabled me to realise my old idea of putting the Quality-of-Life-Recorder onto a pen-computer.

David Rawlinson of Broadcast Engineering Services, Sydney, contributed little practical things like Windows 3.1 for software testing, together with some invaluable ones like happiness, friendship, Ξενοφιλια and lessons in Greek. - Greetings to Sofie!

My brother Marc-André Sigle, communication electronics specialist and student, who recorded some of the digitized sound files of the first pre-release for me and sent them through the Net. He is also my preferred beta-tester...

Dr. Timm Volmer at Glaxo Wellcome plc. for supporting the QL-Recorder project by initiating the eIBSQOL project.

Franz Porzsolt, Professor of Medicine at the AG Klinische Ökonomik for pointing me towards Outcome Measurement, and the interesting co-operation sustained over a long period of time.

As well as various friends and colleagues who have expressed interest, used, and supported this software in 16 years (as of 2009, and counting...).

Thanks to every rainbow which adds colour to grey skies, and to :-) and · who co-exist happily within this document. :-)


The Quality-of-Life-Recorder team

The following people are actively participating in the development of the Quality-of-Life-Recorder:

QL-Recorder concept, programming of AnyQuest and preparation of applications:

Dr. Jörg Sigle, Germany

Assistance, quality assurance and additional programming:

Alexandra Piffel, Germany

Marc Sigle, Germany

Quality-of-Life-Recorder applications:

Several people have contributed to the development of integrated applications of the QL-Recorder. The main projects and their participants are listed below:

AnyQuery for Windows - a simple data retrival and printing tool: Marc Sigle

Integration into TREG - import of QL-Recorder data into an electronic tumor documentation database and statistical analysis system: Dr. Friedrich von Bültzingslöwen; Rosenberg Software Development.

Integration into AKQUASI - import of QL-Recorder data into an electronic psychotherapy documentation database and statistical analysis system: Dr. Hans Kordy, Anke Herrmann.

Integration into FEBROSKRIPT - import of QL-Recorder data into an electronic hyperthermia monitoring, documentation and analysis system: Stefan Heckel, Oliver Seifert.

eIBSQOL - an international, indication specific outcome measurement tool introduced together with a new drug: Dr. Timm Volmer and his colleagues at Glaxo Wellcome plc.

eSIRO - a psychosomatic instrument to diagnose the need for psycho-oncologic support in radio-oncology patients developed in coopreation with Prof. Peter Herschbach et al. at the TUM and LMU Munich, funded by the Deutsche Krebshilfe e.v.


The eIBSQOL team

The following people have contributed to the development of eIBSQOL:

Project initiation and coordination at Glaxo Wellcome plc.:

Dr. Timm Volmer, United Kingdom

Generation of original IBSQOL at Glaxo Wellcome plc.:

Dr. Beth Hahn, USA

Translation, testing, support at Glaxo Wellcome plc.:

Dr. Agostina Aimola, Italy

Monika Behrens, Germany

Claire Bertin, France

Per Boström, Sweden

Giuseppe Caputo, United Kingdom

Steven Crowley, Australia

Dr. Jos Heuijerjans, Netherlands

Korina Karampela, United Kingdom

Rhoda Luer, United Kingdom

Margareta Nordström, Sweden

Anna-Lena Nyth, Sweden

Isabel Pérez, Spain

Dr. Maria E. Watson, USA

Commercial support at Glaxo Wellcome plc.:

Diana Stokes, United Kingdom

Rob England, United Kingdom

QL-Recorder concept, programming of AnyQuest and preparation of eIBSQOL by:

Dr. Jörg Sigle, Germany

Assistance, quality assurance and additional programming:

Alexandra Piffel, Germany

Marc Sigle, Germany

CD-ROM-integration was accomplished at Digital image by:

Simon Beard, United Kingdom

Stephen Brabbins, United Kingdom


How to use the registration form

Registration and licensing

How to use the registration form

Please fill in the registration form to register your copy of AnyQuest for Windows, according with the License Agreement.

You can just print the form by selecting "File - Print topic" from the help menu.

Alternatively, you can copy the form into your e-mail client or word processor by selecting "Edit" - "Copy" from the help menu and "Edit" - "Paste" in your destination application.

Of course, in a future version, I might supply this form as an AnyQuest-for-Windows-questionnaire. :-)


Registration form - payment

Registration and licensing

How to include payment

If you want to receive a more personalized version of AnyQuest for Windows as soon as possible, you may include payment with your registration form. If your payment has cleared, you will receive a personalized license key without delay.

Please be sure to pay in a way which does not cause additional costs to me, e.g. using a bank cheque drawn on a German bank. I don't take any responsibility for cash money sent. You will receive a receipt for the sum you paid.

Customers inside Germany, and customers outside Germany, but inside the EU and without a valid VAT-ID-Nr. please add EUR 10,- for shipping costs + 19% VAT.

Customers inside the EU with a valid VAT-ID-Nr. please add EUR 10,- for shipping costs.

Customers outside the EU please add USD 10,- for shipping costs + USD 20,- for bank fees (to cover the costs of international money transactions and/or the money conversion). If applicable (e.g. for Switzerland, as far as I know not for the US), local VAT may be charged upon delivery of the package, depending upon local legislation and legal practice.

For your information, completely computed end-user prices for a single personalised license including shipping cost and VAT are listed on the registration form for customers from the EU and the US.


Registration form

Please read this note, then send/e-mail the completed form to:

Dr. med. Jörg M. Sigle  	Phone: +49-176-9643-5413
Im Vogelsang 2                                   	  +41-76-276-8694
                                                      	joerg.sigle@jsigle.com
75438 Freudenstein                               	http://www.ql-recorder.com
Germany                                          	http://www.jsigle.com

I would like to register AnyQuest for Windows for:

Person or institution, address, Phone, Fax, e-mail:

Number of copies to be registered:

Accepting the License Agreement, a registration is requested...

O 	for free evaluation of version            only. (I appreciate your feedback!)

O 	as licensed user at the standard registration rate: USD 150,- or EUR 150,- per copy (Please see below for details regarding VAT, see License Agreement for what's considered fair use of one registered copy).

O 	for multiple licenses or use within a specially funded project. (Please supply details.)

O 	for a user who can't afford the standard registration fee. (Apply for registration at reduced rate or for free, please supply details.)

Please supply further information about yourself and the intended use, if necessary:

Other costs and total prices for a single license at the standard registration rate are:

For customers inside Germany: EUR 10,- for CD shipping + EUR 30,40 for 19% VAT = EUR 190,40.

For other customers inside the EU with valid VAT-ID-Nr.: EUR 10,- for CD shipping = EUR 160,-.

For other customers inside the EU: EUR 10,- for CD shipping + EUR 30,40 for 19% VAT = EUR 190,40.

For customers in the USA: USD 10,- for CD shipping + USD 20,- for bank fees = USD 180,-.

For payment, I include the amount of:

I would like to contact other registered users of the QL-Recorder:  (yes)   (no)

I would like to participate in the QL-Recorder mailing list:  (yes)   (no)

Date, place, signature:

Thank you for your registration!


Quick Guide: How to install and use the Quality-of-Life-Recorder

A crash course: Complete essentials

Quick Guide: How to install and use the Quality-of-Life-Recorder

This is a brief and very practical introduction to the Quality-of-Life-Recorder.

It contains all necessary information to aid you from its installation to the first questionnaire session. Section 11 of this guide can be printed and serve as an everyday-help to clinical users of the electronic questionnaire.

Reading this document, setting up the Quality-of-Life-Recorder for use with one of the provided questionnaires and completing a first test-questionnaire will take less than an hour, depending on your computer experience. - Have fun!

This quick guide contains the following sections:

1. 	Overview

2. 	What is the Quality-of-Life-Recorder?

3. 	What do you need?

4. 	What else should you consider to use?

5. 	Patients' data protection - Are there legal obligations?

6. 	Installation: Basic setup

7. 	Installation: Advanced and network setup

8. 	The Quality-of-Life-Recorder, AnyQuest for Windows, eIBSQOL and other applications

9. 	Setting up the environment according to local needs

10. 	Which patient identification options should be recorded?

11. 	Presenting a questionnaire to a patient

12. 	Authors, license, further information, disclaimer

1. Overview

For normal users, this is the overview. For those without fear, it may be all they need to read in this file. :-)

•	Install the software running anypak.exe, demopak.exe or the specific package you have.

•	Consider data protection and patients' privacy well.

•	Start "DESIRED_QUESTIONNAIRE YOUR_LANGUAGE" or "AnyQuest for Windows" for configuration.

•	Press "Help" button. Go to the table of contents, read at least the license agreement and the introductory comments, if you like. Close the online-help again.

•	Press "Setup" button.

•	Setup site specific options (only once), mainly patient identification options to ask for and sound.

•	Exit the Quality-of-Life-Recorder to save changed configuration.

•	Having read at least section 11 of this guide is very highly recommended now.

•	Invite the patient to provide a QoL assessment with a standardized invitation.

•	Move the task-bar away, configure it as described in section 11.

•	Start "DESIRED_QUESTIONNAIRE YOUR_LANGUAGE".

•	Press "Go!" to start a questionnaire session.

•	Recommended: Enter patient identification data yourself or let a qualified person do that, to ensure data reliability.

•	Give the system to the patient, let him complete the questionnaire, informing him, that you're around when he should require assistance.

•	Review generated printout together with patient.

•	Exit the Quality-of-Life-Recorder.

If you require more details, please go on reading this file or use the remaining on-line-help. It provides further sources of information including a literature reference.

2. What is the Quality-of-Life-Recorder?

The Quality-of-Life-Recorder is a tool, that allows patients to fill in questionnaires directly at a computer. For patients with no computer experience, you should use a touch-screen or a pen-computer. The Quality-of-Life-Recorder will work on such devices, but if you are on a very small budget, it will also work on any usual PC with its mouse, track-ball or any other pointing device.

It is so easy to install and to use, that you can operate it already, if you have very basic computer knowledge.

This tool can be available to you within the following packages:

anypak.exe - A shareware package distributed via my WWW-site. General purpose, several example questionnaires provided.

glaxopak.exe - eIBSQOL: Indication specific, everything-prepared, supported and distributed by Glaxo Wellcome plc.

eortcqlq.exe - eQLQ, electronic EORTC QLQ: a preliminary, everything-prepared, implementation of the EORTC QLQ-C30 and some of its modules in several languages to serve as basis for evaluation and discussion within the EORTC QL-study-group.

3. What do you need?

The minimum computer system required is a PC compatible with...

•	80386sx CPU

•	8 MB RAM

•	10 MB free hard disk space

•	VGA graphics card and display

•	any pointing device (e.g. a mouse)

•	MS Windows 3.x compatible operating system

This is indeed a more basic system than you will find available at any shop today, so you could use an old PC of yours. The Quality-of-Life-Recorder itself will run quite well on such a system because it does not require many resources.

The Quality-of-Life-Recorder also runs on Windows 95, Windows 98, Windows NT 3.x, Windows NT 4.0 as well as on Linux + Wine + xfsft and several other emulators e.g. for the Macintosh.

If you have not received an everything-prepared package, you may either require to obtain electronic questionnaire definition files or prepare them from your paper versions yourself.

4. What else should you consider to use?

For data protection issues, if you can have set it up, the free operating system Linux is recommeded in connection with Wine and the font server xfsft, because it is probably the most secure platform you can use as well as a totally free one.

If you do not know how to do that, then if your budget should allow it, Windows NT 4.0 would be the system of choice. So, for a more secure system, you require:

•	Windows NT 4.0 or Linux together with Wine and xfsft, and to run these operating systems smoothly:

•	Pentium CPU with 75 MHz or above

•	32 MB RAM or more

To make the system very easy to handle for patients untrained in computer use, a touch-screen, a touch-screen add-on or a pen-computer are highly recommended. Please review the section "hardware" of the on-line help to get more information. This also comments on sound output and other possibilities.

If you plan to use a laptop or a pen-computer, please make sure that its display has a good readability; especially a high contrast is useful. A colour TFT display is recommended if you have patients with reduced visual capabilities.

If you want to get immediate printouts with results, a printer is of course required. However, you could also use a print-preview utility like FinePrint (shareware) for this purpose.

If you want to set up a very comfortable system, you should use Pen-Computers which are integrated into a wireless network. This would allow to measure patients' Quality of Life anywhere in your hospital, and to have the data stored on a central server, to produce a printout on the ward that it requires, immediately after the patient finishes a questionnaire without any required additional steps.

5. Patients' data protection - Are there legal obligations?

European or national law regarding the protection of patients' data and privacy may require special precautions before recording patients' data. It may be necessary and reasonable to contact a person who handles these issues at your institution or a knowledgeable person from the local data processing staff for advice. Scientific use of data may be subject to other regulations than use for routine treatment.

The following list suggests some options to take into consideration. In any case, you should try to make a computer based system at least as well secured against theft, abuse or destroying of data as a conventional paper based system.

However, if security issues prevent you from using electronic questionnaires, think over the security of paper based data.

It may be very reasonable or required, to record only a coded patient identification instead of patient names, together with or without patients' date of birth, depending on your exact situation.

In the absence of other data protection measures, it may be critical to make sure that computer systems which provide access to recorded data are not used in an undesired way. This means e.g., that a laptop containing patients' data must be kept physically safe from unauthorized access.

If you use a single computer system for the purpose of data collection, it may be reasonable or required - depending on the safety requirements and safety levels provided by your operating system and third party tools - to remove software that could be used to view or copy data by unauthorized persons from such a system.

It might as well be reasonable or required to protect such a system by means like removing or locking its floppy drives.

It may be required to guarantee a safe encryption of recorded data using additional tools, especially when you are going to communicate these data or store them off-site.

Usually, the more you know about national law and computer security, the more you can do legally and with the feeling of treating your patients' data right.

6. Installation: Basic setup

The Quality-of-Life-Recorder comes as everything-prepared self-installing package.

It will install itself into c:\anyquin, so that you need write access to the drive c: which usually is your first local hard-drive.

The Quality-of-Life-Recorder itself does not write anything into your \windows or \winnt directories.

1. 	To start the installation, please run the file anypak.exe, glaxopak.exe or eortcpak.exe.

2. 	Read all information screens carefully; if you understand them, then answer "yes" twice. Afterwards press the button "Install to c:\anyquin".

3. 	After setup has completed, read any final messages of the setup program, then press "ok" to end it.

The created program group "AnyQuest for Windows" will remain open to give you easy access to the new software; later you can close it and access the Quality-of-Life-Recorder via the Start-Menu or the Program Manager.

7. Installation: Advanced and network setup

By fixing the default installation path completely in the basic setup, we want to ensure easy support of users with basic computer knowledge.

More advanced users, however, can use the included on-line help and then tailor their setup completely to their needs. This includes configuration for multiple concurrent studies, multiple QL-Recorders and so on.

If you wish to install the Quality-of-Life-Recorder onto a network drive or onto another harddrive, you can only do this by moving the resulting c:\anyquin away to your target drive and updating all required shortcuts, program group entries and AnyQuest configuration files as described in the AnyQuest for Windows on-line help-file.

8. The Quality-of-Life-Recorder and AnyQuest for Windows vs. its applications

The eIBSQOL is an electronic version of the IBSQOL Quality-of-Life-questionnaire. Its preparation has been supported by Glaxo Wellcome plc.

The electronic EORTC QLQ is an electronic version of the EORTC Quality-of-Life-questionnaire. It is a preliminary package, available only within the EORTC QL-study-group for evaluation and discussion.

Both packages have been built using AnyQuest for Windows, a software implementing the general concept of a Quality-of-Life-Recorder by Jörg Sigle.

After installation your Start-menu or your Program-Manager will contain a variety of new entries. One will read "AnyQuest for Windows", and another one "How to use AnyQuest for Windows".

If you installed either the eIBSQOL or the electronic EORTC QLQ packages, there will be additional entries reading "eIBSQOL English", "QLQ-C30 French" and so on.

All of these entries will bring up a special version of the software which offers a simplified menu, only including options related to presentation and evaluation of the designated questionnaire.

The icon labelled "AnyQuest for Windows" will bring up a full version of the Quality-of-Life-Recorder software which also includes more advanced options for questionnaire design. The help files may be different between the packages, but all will include a full explanation of AnyQuest's possibilities.

9. Setting up the environment according to local needs

After starting AnyQuest for Windows, you will see a screen that offers buttons either to "Go!" or to "Setup".

Please chose "Setup" to set some configurable options to exactly fit your individual needs.

After you press "Setup", the window disappears and you can use AnyQuest's menu to find out what's available. Changed settings will remain effective even after exiting and restarting, but you need to chose the settings you like once for every pre-prepared or self-made configuration, including different languages or sets of questionnaires, you wish to use.

All options are explained in the included on-line-help file, but here is a list of the most important ones, together with their position in the menus:

•	"File" - "Clear all"

This removes all currently questionnaires from AnyQuest's mind. Use it before you prepare a new configuration, or between looking at several questionnaire definition files.

•	"File" - "Load"

This opens a dialog that allows you to load questionnaire definition files. Use this to prepare a set of (one or many) questionnaires which will be asked in one session.

•	"Navigation" - "Patient identification options to ask for..." - "..."

This is by far the most important option. The recommended setting totally depends on your environment, the purpose of your data collection and is also affected by how much you know about operating a computer securely and about local law. Please review the information in the on-line help regarding "data protection" and the hints given below when you decide about what patient identification data shall be recorded.

•	"Sound" - "..."

The sound production of AnyQuest can be configured to be either completely quiet, to use Wave-files or to confirm or announce several actions by some signals. If you are going to interview patients with little or no computer experience, or if you use a touch-screen or pen-computer, it is highly recommended to activate a signal that confirms given answers. The experience shows that this is a great help for patients.

Depending on your patient population, your environment (and your personal preferences) you should select a signal that is loud enough but still not annoying.

If the given configurability is too little, you should consider using a soundcard that has the ability to control the volume of the PC-speaker output. AnyQuest for Windows allows the connection of individually recorded sounds to any event, too, but this is advanced users' work described in the on-line-help.

•	"Display" - "Reset cursor position..."

Using this option, you may make the cursor move to a defined point whenever a new question is shown, to avoid a tendency to select the answer where the cursor already is.

Although useful from a scientific point of view, this option is quite annoying when used without suitable input devices like touch-screen or pen-computers.

•	"Display" - "Show Can't / Don't want to answer"

•	"Display" - "Show additional text input windows"

This options can be left turned OFF as long as your system has a keyboard, or any possibility to type [Ctrl]-[F5] during the questionnaire session, or if you want to force patients to give an answer to any question even if they feel they can't or don't want to answer an individual one.

If during a session the patient signals that he has trouble and asks for your assistance, you can always press [Ctrl]-[F5] to bring up the specific fields to state "Can't to answer this question" or "Don't want to answer this question". After checking one of these options, you can even record a reason if you want to.

Then, you press [Ctrl]-[F5] again to hide the respective answer fields again.

Only if your system has no possibility to press [Ctrl]-[F5], you should turn on the first option by default and set the additional option according to your needs.

•	"Printing" - "Printer setup..."

You can set up a printer or a fax device in advance, otherwise the program will ask you automatically after the first completed questionnaire.

All configuration options are stored in the file anyquin.ini or an alternative configuration file specified when invoking AnyQuest for Windows.

10. Which patient identification options should be recorded?

Please note that all data you selected for recording, must be entered. It may be sufficient to enter only a single character in the respective screens, but definitely, they cannot be left empty.

So the most robust and recommended option would be to record a well-defined patient identification code, generated by an algorithm that makes it at least difficult or even impossible for an unauthorized person to identify the patient to whom a given data set refers. A date of birth should be recorded, if age computation and documentation is required.

It is recommended, that these data are entered by qualified personnel in front of the patient. First, this gives him an example of how to use the input device (e.g. a touch-screen, a pen, a mouse...), and second, this ensures data reliability.

Here are the details and other options:

Depending on the operating system you use, it might be more or less difficult to protect recorded data from unauthorized access.

Generally, it should be rather safe to record only a coded patient identification, as long as the key to these icons is kept in a safe place (this may be a safe computer system or in an encrypted file even on an otherwise unsafe system).

If you want the Quality-of-Life-Recorder to record and print the age of a patient, it requires his date of birth.

For general practice use, it may be desired to record patients' initials or patients' names, but then recorded individual files are definitely attributable to a single patient, and may thus become subject to special legal terms. These data are very critical to handle or communicate.

If you want to process your data in third party systems later and record all patient identification data somewhere else anyway, then you may only need a reliably entered patient ID code to enable the target software to import individual patients' data.

According to my own experiences, you cannot rely on patients initials for identification of individuals. People will mix the sequence of christian and family names, they will enter two or three initials and so on.

In several applications, it may even be desirable to check the entered patient ID by recording further redundant data.

11. Presenting a questionnaire to a patient

Finally...!

This is easy:

•	Invite the patient to fill in the questionnaire. You should use a standardized invitation like:

"Dear patient. We have prepared a questionnaire to find out, how you would rate your own Quality-of-Life from your own point of view (and NOT merely from the doctors')..."

If you work scientifically, it would be very useful to publish the invitation you used because it may well be the most important determinant of patient compliance.

Scientific guides on how to present questionnaires to patients are available.

•	If not done already, move the task-bar on your system away from the bottom, e.g. to the top of your screen. Set it's properties to "automatically in the background" and, optionally, "always in the foreground". (So, a patient won't be distracted by the taskbar, and won't activate it accidentally when trying to click the "Continue"-button.)

•	Start the language or questionnaire set specific preparation of the Quality-of-Life-Recorder via your Start-menu, your Program-Manager or a prepared link.

•	Show the patient the system. In front of him, start the session pressing "Go!". Note that the program's menu disappears now.

•	Ask him for his name and date of birth, if you do not already know them, or get his patient ID code.

•	Enter the required data, thereby demonstrating and explaining to the patient how to use your mouse, touch-screen, pen or other input device. And: ensuring ID-data quality.

•	When the first introduction screen appears, hand over the system to the patient.

•	Assist him in finding and pressing the "Continue..." button after he has read the first introduction.

•	Watch the patient filling in the first question, if necessary (mostly: not necessary) give some additional explanation of how to use the hardware, or: give positive feedback when you see that he knows that well.

•	Step into the background, telling the patient, that you are around in case he should have questions or difficulties.

•	Avoid to counsel the patient in which answer to select.

•	Avoid to explain unclear questions or make unvalidated translations or explanations of translations to people who have difficulties in understanding a question or an answer field label.

•	Know every important thing about keyboard support, but don't confuse the patient with that.

•	If a patient has such difficulties and decides he can't or doesn't want to answer a question, proceed as described above, in the section about individual configuration.

•	If a patient finds that he erratically answered a question, and that question has already disappeared, you can help him by using the Page-Up-Key to show the last question(s) again. (This option has one minor flaw and pitfall: if there were some questions before the currently displayed one, they will be shown too. This can cause difficulties in extremely rare circumstances; it may be improved until the final release version).

•	If a session must be interrupted or aborted, do this by selecting one of the controls normally used to close a window (Windows 3.x: System menu, top left; Windows 95: same or Close window button, top right). Then select whether to abort or temporarily save that session. You can resume saved sessions later, and the navigation window will indicate the availability of resumable sessions.

•	After the last question has been answered, the Quality-of-Life-Recorder shows a "Thank you." You can thank the patient for his cooperation, too.

•	Automatically, all entered data will be processed, saved, printouts generated if configured.

•	Now, the navigation menu appears again. You can press "Exit" to leave the Quality-of-Life-Recorder.

12. Authors, license, further information, disclaimer

AnyQuest for Windows and the concept of the Quality-of-Life-Recorder are copyrighted products of Dr. Jörg M. Sigle, Germany. The electronic EORTC QLQ is an application of this product. This product comes under a special license agreement, described in the on-line-help file.

The original IBSQOL questionnaire was developed by Beth Hahn; © Glaxo Wellcome plc., 1999.

The original EORTC Quality-of-Life-Questionnaire was developed by the QL-study-group of the EORTC. It is a copyrighted instrument which may be used freely for academic research, while a fee has to be paid when it is used in industrially supported research.

Names of people involved in the development of the Quality-of-Life-Recorder, contact addresses, literature references and sources of further information are given here.

If you have questions not answered in this quick guide, please consult the remaining online-help. It has introductory sections, sections for advanced users and another hands-on "quick guide" leading you step-by-step through the preparation and presentation of an electronic questionnaire as well as towards data export into third party applications.

Should you still have questions, suggestions or other feedback, please contact the authors or people whose addresses are given here.

This document contains some trademarks which are owned by Intel, Microsoft, Apple and Linus Torvalds.


Quick Guide: How to make your questionnaire go electronic

A crash course: Complete essentials

Quick Guide: How to make your questionnaire go electronic

If you are new to AnyQuest for Windows and fear getting lost in the manual, this page gives you a practically oriented overview. You may print it as a guideline to editing and applying questionnaires.

You should follow this guide once, and do exactly, what is suggested in it. Hereby you will generate a demonstration questionnaire, and many "How do I..." questions will be answered. Then, you can follow the steps described herein to make your own questionnaires go electronic. However, keep in mind: this is a quick-guide; it remains far from exploiting all features of this software!

Well, if you want to make your own questionnaire go electronic with this program, you need the following:

•	A questionnaire, usually printed on paper, as a word-processor document file, or as a PDF document. Preferrably, it contains checkboxes and/or linear analogue scales (I will use a made up demo questionnaire here).

•	A collection of algorithms which are used to score the questionnaire (i.e.: "To compute 'Physical function': Add questions 1..5, subtract 1, divide by 4 and multiply by 100").

•	A PC with a suitable input device (mouse, trackball, trackpoint, trackpad, touch-screen, pen of a pen-computer or Tablet-PC) and a MS Windows compatible environment that can run AnyQuest for Windows (i.e. Windows 3.1x, NT 3.5x, 95, 98, NT 4.x, 2000, XP, 2003, Vista... or Linux with WINE or SoftWindows or anything similar on the Macintosh or SGI).

•	AnyQuest for Windows installed in the default directories.

Since January, 2001, a file c:\anyquin\questns\demo\prototyp.qdw is available. It includes prototypes for numerous question layouts and should speed up your questionnaire construction enormously. Please read here about using prototype and anchor questions when you finished this quick guide.

This version of the quick guide has been reviewed in October, 2009, to reflect recent improvements in AnyQuest for Windows questionnaire definition editing functionality until version 3.37. If you observe inconsistencies between this quick guide and your actual experience, and if you are using an older version of the software, please consider an upgrade according to information availabel on www.ql-recorder.com or elsewhere in the on-line help.

I have also added explanations to some steps, that give insight as to the meaning of some item, or why you should adopt something as a standard policy when designing your own electronic questionnaire definitions.

Required time:

It will probably take you between 1 and 4 hours to complete all the steps of this guide, depending on your concentration and your computer literacy.

Thoughtful preparation of your editing environment:

This section refers to technical matters like screen resolutions etc. If this appears too theoretical for you, and specifically, if you want to prepare questionnaire definition files on the same computer which you will use to administer the resulting electronic questionnaires, you may as well skip this section.

If you prepare a questionnaire definition files on one computer, that shall be used on another computer later on: Please try to set up the computer used for editing to match the one used to administer the resulting electronic questionnaires as closely as possible. This may refer to display proportions (width:height), display resolution, font size, available fonts, window decoration size, number of colors, and sound playback capability.

If the target computer differs from the editing computer, AnyQuest for Windows will try to display the electronic questionnaire and try to compensate for the differences. However, you may find, that e.g. a questionnaire defintion file designed on a 1024x768 (1:1.33) display looks somewhat "bold" (having been stretched horizontally) when displayed on a 1400x900 (1.55:1) widescreen display. Answer fields that would have been quadratic in the original would get slightly flat. The other way round, an answer field that is a perfectly round smiley on your 1024x768 editing machine, will become a slight egghead on a 1280x1024 (1.25:1) LCD. Text field contents may also be affected: changes in the available horizontal space may especially change automatically performed line breaks. Similar (though usually small) effects can be caused by differences in font rendering (with or without smoothing), and in availability of language settings and fonts - the latter will especially affect questionnaires that use Asian fonts or anything else which goes beyond the Latin/Western/ANSI scope.

I usually set my computer to 1024x768, using the standard "small fonts" Windows setting for editing purposes: After all, 4:3 has been one of the most common screen formats, and many touch-screens and pen-computers have offered 640x480, 800x600 or 1024x768 pixels. It's still common for Tablet-PCs in "slate" format as of 2009, and a 1024x768 design will usually also work on widescreens, apart from looking stretched. I also prefer manual linebreaks to achieve clearly and quietly looking multiline text items. As a side effect, manual linebreaks remain consistent in the widescreen environment.

If you specifically prepare a questionnaire definition for a widescreen questionnaire administration system, however, you may as well use a widescreen system for editing. Before you exploit higher pixel resolutions, however, please keep in mind that simple screen layouts, with a lot of clarity, can be understood by a patient much more easily than overloaded fine-print ones. :-)

When you chose to temporarily set the screen resolution of a widescreen display to 1024x768 for questionnaire layout editing, you may chose to NOT extend the display to the physical screen dimension. While this only uses smaller portion of the physical screen, it keeps the proportions intact, so that quadratic answer fields appear quadratic on such a screen. Some displays also offer you to scale up 4:3 content to physical widescreen size while maintaining correct proportions.

Finally, I recommend to use the same display size for all editing steps of a given questionnaire definition file, in order to avoid any rounding errors (with regard to item size, font size, answer field distance etc.) that might otherwise be introduced by editing it repeatedly using various different display resolutions.

Conventions for this guide and further general instructions:

•	You should be familiar with the general use of MS Windows (or any other operating system and graphical user interface you're about to use). If not: embark on the MS Windows introduction tour and ask a friend for assistance.

•	Remember: If any text in input fields is highlighted, it will probably be replaced by the next character you type.

•	When I ask you to ACTIVATE a menu option, please open the menu and look whether there is a checkmark left of that option. If yes, this option IS ALREADY activated, so just close the menu. If no, this option IS NOT activated YET, so select it. You can open the menu another time to confirm that it is activated thereafter.

•	When I ask you to DEACTIVATE a menu option, ... vice versa.

•	When I ask you to type [Ctrl][Enter], I'd like you to hold down the key labelled "Ctrl" (or "Strg" on German keyboards) and then press the "Enter" (or "Carriage Return"). key.

•	When I ask you to type "example", I'd like you to press the keys: [e] [x] [a] [m] [p] [l] [e]. Don't type the quotation marks!

•	When I ask you to Click-Left, I'd like you to press the primary button of your input device, usually the left mouse-button. On some systems, mouse buttons might be swapped intentionally to accomodate left-handed mouse users. On a pen-computer or Tablet-PC, the Click-Left is typically issued when you simply tap or click the stylus onto the screen.

•	When I ask you to Click-Right, I'd like you to press the secondary button of your input device, usually the right mouse-button. On a pen-computer or Tablet-PC, this may be holding down a button on the stylus, or a button on the computer itself, and then clicking the tip of the stylus at the screen. If Click-Right functionality is not available, it might have been intentionally disabled to avoid the distraction of untrained patients who might unintentionally hold the stylus button while answering questions. If this is the case, you should re-enable this function for the duration of your questionnaire editing work.

•	Please don't mix up left and right mouse clicks, because then this guide will not work. E.g., if you click left on an object before you click right, it receives a selection frame - and this will make its context menu change.

•	Most context menu entries for editing activities have corresponding shortcut keyboard command sequences. You can print the respective on-line help page; using them can significantly speed up the editing process.

•	I'd suggest you to print this guide and to strike out every single operation you completed. So you won't get mixed up.

Here are the suggested steps to make a questionnaire go electronic:

The most prominent task is to prepare a questionnaire definition file *.qdw (binary, recommended format) or *.qdt (text, for special purposes). This file contains information about questions or screens to display, type of question, question and explanation text, answer fields, images, sounds, and so on, formulas for conditional branching (non-linear questionnaires) computation of results and basic instructions on how to produce result files and result printouts.

AnyQuest has a graphic editor to accomplish this task. Alternatively, you could produce a questionnaire definition file in text format *.qdt directly with a text editor or third party software. This option is, however, less intuitive; you can look up that topic elsewhere in the on-line-help.

•	Make sure that you have a usable installation of AnyQuest for Windows. Theoretically, it is sufficient to have the two files anyquin.exe (or a specially "branded" version of that file) and bwcc.dll to be able to edit questionnaire definition files and to create usable configurations. It is, however, recommended that you rather install the simple demonstration package anypak.exe available from www.ql-recorder.com, which will also provide an on-line-help, several language files, and examples for questionnaire definition files and complete configurations.

•	Start up AnyQuest for Windows. For questionnaire definition file editing, please use the "AnyQuest for Windows" or "AnyQuest for Windows - Your own..." entries which are supplied with the simple demonstration package anypak.exe available from www.ql-recorder.com.

•	Set up the AnyQuest environment in a way optimal for editing:

•	In the navigation window, click-left on the button "Setup".

•	Select "File" - "Clear all". This removes all questionnaire definitions from AnyQuest for Windows' memory, and thereby ensures that the new questionnaire definition which you will create in a minute uses standard defaults. Otherwise, a newly created questionnaire definition would be modeled after some already loaded one.

•	Make sure that these options are active:

•	"Edit" - "Edit layout".

•	"Edit" - "Show text rectangle size". This lets you see the space in the screen layout which is provided for each text element.

•	"Edit" - "Formula consistency check". We don't use this option right now but it is usually helpful.

•	Make sure that these options are disabled:

•	"Edit" - "Edit result formula..."

•	"Edit" - "Edit conditional branch formula...".

•	"Edit" - "Questionnaire descriptors...".

•	"Edit" - "UPN formula debug mode...". This option can be very annoying when unintentionally activated.

•	"Edit" - "Auto adjust text rectangle size...". This option can be somewhat annoying when unintentionally activated.

•	Make sure that these options are active:

•	"Display" - "Show long questionnaire name".

•	"Display" - "Show short questionnaire name".

•	"Display" - "Show Can't/Don't want to answer". This shows special answer fields a patient may use when they cannot or do not want to answer an individual question. For usual questionnaires, where you would expect that patients do not regularly have any difficulties, I recommend to keep these fields hidden by default, and only to bring them up when a patient expresses the need to use them. I nevertheless recommend very decidedly to add these fields to the layout of almost any question in any questionnaire (if you don't use the specific functionality AnyQuest offers to support such fields, then at least provide some continuously visible fields with numerical/text reserved values defined by your specific questionnaire for the same purpose). If you would not be prepared by providing a field to handle the occurence of an intentionally, knowingly missing answer properly, then (depending upon the type of the question) you may have to check any other field just to get the questionnaire completed, and thus you would effectively turn into collecting random answers without highlighting them as such. So please provide fields to handle intentionally missing answers in a controlled way; AnyQuest includes comfortable functionality to collect, document and process them adequately.

•	"Display" - "Show questionnaire number". This information is useful for questionnaire layout editing. Whereas you can also use it in questionnaire administration, I recommend to turn it off (as well as the following two options) - I prefer clarity and simplicity of anything presented to the patient.

•	"Display" - "Show question number".

•	"Display" - "Show numeric and string results of question".

•	"Display" - "Show graphical progress indicator". This indicates the number and the length of all currently loaded questionnaire definition files, as well as the current position within them. Patients usually understand it intuitively, without explanation, and I regularly keep this display during questionnaire administration (technical note: the intuitive understanding is perfect, as long as simple linear setups are used; and for non-linear setups, it is usually still practical). Since version 3.52, it uses black colour for unmodified, and red colour for modified (edited and not yet saved) questionnaires. These colours can also be configured.

•	Make sure that this option is disabled:

•	"Display" - "Reset cursor position when question is displayed". This option is for touch-screens and pen-computers. It moves the mouse cursor off the screen, when a new question is displayed. This avoids the possibility that the mouse cursor could attract the patient's attention and thereby might influence the selected answer. On a touch-screen or pen-computer, the mouse curser jumps directly to any position at which the patient points to answer a question. So there's no extra effort required to bring it back after it has been moved off the screen. On standard systems however, which only have a mouse, track-ball, track-pad or track-point, bringing back the mouse cursor onto the screen after each question, and re-locating it, would be tedious. Thus, its position should be left unchanged between questions on standard systems.

•	Find the undo functionality:

•	In the "Edit" menu, look for the entry "Undo". This provides a relatively high resolution undo functionality, and the menu entry shows which steps it would undo.

•	As you don't need the function right now, click on the "Edit" menu entry again to close the menu.

•	Remember where this function is located for later use if required.

•	Generate a new questionnaire:

•	Click-Right into main window area to open context menu.

•	Select "Add questionnaire". Please note that adding a questionnaire, also adds one question to that new questionnaire. If no other questionnaire has been loaded before, the new questionnaire and the new question appear in some standard layout. This was recently enhanced to include helpful information on questionnaire editing in the main text items. The new standard layout also includes 7 regular answer fields, and 2 special answer fields for your convenience. It is easier for you to delete unneeded answer fields, than to add (and correctly position) additionally required ones.

•	Click-Right into questionnaire long name (by default:"New questionnaire - long name"..

•	Select "Text".

•	Enter a long questionnaire name, i.e."General Quality of Life Questionnaire 8 Core".

•	Click-Left on "ok".

•	If your long name is too long for the text area: Click-Left on long questionnaire name. Then, drag the left middle handle further left, in order to provide more space for this text field. Please note that this instruction applies for questionnaire names which appear right aligned in the top right corner of the screen. I recommend to put them there (and have them invisible during questionnaire administration), so the left top area remains usable to e.g. display the current patient's name, date of birth, or other identification. Earlier versions of AnyQuest would, by default, position the long and short questionnaire names to the top left corner instead.

•	Click-Right into questionnaire short name (by default:"NewQuireX". Make sure that you do not click into the area where the questionnaire short name and the explanation text fields do overlap.

•	Select "Text".

•	Enter a short (!) but supposedly unique (!) questionnaire name, i.e."GQLQ8C". Usually, the short questionnaire name should not contain any colon ":", because AnyQuest itself uses the colon to separate parameter names and values in the result file. It may be a good idea to use only standard characters A..Z, digits 1..9, and the underscore. You should also make sure that the short questionnaire name starts with a character or an underscore. The short questionnaire name will appear in the result file generated after each questionnaire administration, at the beginning of each line that was generated for this questionnaire definition file. This name will also be included in each column header generated in a data export table, and thus arrive at the beginning of each column header or at the beginning of each variable name in your third party statistics or spreadsheet software which you may use for advanced analysis of collected data. It will also be propagated to table- and column names automatically generated by the AnyQuest-to-SQL data processing tools which I made. After all, the requirements of your ultimate target application used for data analysis or data processing actually determines what are suitable or unsuitable short questionnaire names, but the recommendations given above should usually suffice.

•	Click-Left on "ok".

•	Toggle, and finally activate the editing grid:

•	Make sure that the AnyQuest for Windows main window is active (has the input focus). If it isn't, use the mouse to click on the main window's title.

•	Reset the current keystroke sequence (just to make sure): press the key "ESC". You should hear a sound signal (reset) for this key if your system speaker is active. (And if this sound signal is very much too loud, and you cannot control the PC speaker channel volume via your Windows soundcard mixer, you can select "Sound" - "PC speaker keyboard edit control" to turn it off.)

•	If you do not see an editing grid already, press the keys "g" - "s" (Grid - Show). You should hear a sound signal (key pressed) for each key if your system speaker is active.

•	You can use the same key sequence "g" - "s" repeatedly to toggle the visibility of the editing grid on and off.

•	To change the grid resolution, press the keys "g" - "1", or "g" - "2" or anything up or "g" - "9" or "g" - "0". Finally, use "g" - "2" for 20 pixels in either direction.

•	Press the keys "g" - "l" (Grid - Lock) to toggle grid locking. While grid locking is active, whenever you move a handle of a selected item (i.e. to resize or to reposition a text item), the center of the handle will snap to the grid. This simplifies the creation of layouts with well aligned, equally sized and equally spaced items.

•	You can look up additional grid related keyboard commands here. Alternatively, you can find menu entries to control the editing grid in the "Edit" menu.

•	Finally, please make sure that the grid is visible, and that grid locking is active (by reviewing the checkmark in the "Edit" - "Grid" menu.

•	Please note that blue grid lines indicate the middle of the screen, and red grid lines indicate additional quarters.

•	Prepare a patient introduction screen:

•	Click-Right somewhere into the main window, where there is no questionnaire object.

•	Select "Insert Question". This inserts a new question before the currently displayed one. Please note the increased "total question count" in the status display at the lower right corner of the screen. Please also note that the newly inserted question is now being displayed.

•	You should see 7 regular answer fields and 2 special answer fields. If you do not find the two special answer fields, please make sure that "Display" - "Show can't/don't want to answer" is active.

•	Click-Right into the red frame of one answer field.

•	Select "Delete".

•	Delete all other answer fields (regular and special ones) in the same way. To speed up editing, you can use a keyboad shortcut: Simply position the mouse pointer over an answer field and type [a][d] on the keyboard.

•	Click-Right onto"New explanation".

•	Select "Clear text".

•	Click-Right onto"New explanation 2".

•	Select "Clear text".

•	Click-Right onto the main question text "New question".

•	Select "Text".

•	Enter:"Dear Patient," + [Ctrl][Enter] + [Ctrl][Enter] +

"we would like to ask you some questions concerning your quality of life." + [Ctrl][Enter] + [Ctrl][Enter] +

"Please fill in the following questionnaire by answering each question." + [Ctrl][Enter] + [Ctrl][Enter] +

"Thank you for your cooperation."

or the introduction specific to your questionnaire. You can enter up to 65535 characters here; line breaks are entered by pressing [Ctrl][Enter] (or [Strg][Enter] on German keyboards).

•	Click-Left on "ok".

•	Probably this introduction won't fit in the supplied text frame. So Click-Left on that frame and then drag the lower middle handle of the selction frame further down, until all text has become visible.

•	Don't be confused by the two overlapping text areas for explanations. They are empty and will not be visible in the final electronic questionnaire.

•	Click-Right on the newly entered introduction, avoiding the explanation text areas.

•	Select "Text alignment" - "Left".

•	Click-Left somewhere into the main window, where there is no other object, to make sure that no object is selected.

•	Click-Right on the newly entered introduction, avoiding the explanation text areas, again.

•	Select "Options".

•	Check"Infoscreen". This setting informs AnyQuest that a patient is not supposed to provide an answer on this screen.

•	Click-Left on "ok".

•	Navigation (moving around) within all currently loaded questions:

•	Locate the transport bar in the lower middle region of AnyQuest's main window. It is a means to move within loaded questionnaires and questions and it consists of four buttons, labelled "|<<", "<", ">", ">>|".

•	Click-Left on ">" to go to the next question. Please note the changed "current question" in the status display at the lower right corner of the screen.

•	Transfer questions from paper to AnyQuest:

•	Have a close look at your paper questionnaire: How many answer fields does the first question have?

•	My example has 5 regular answer fields for each of the first three questions. The new standard question layout has 7, so two regular answer fields must be removed:

•	Prepare the first question, defining the layout for the first set of similar questions:

•	Click-Right on the rightmost of the regular answer fields.

•	Select "Delete".

•	Click-Right on the rightmost of the regular answer fields.

•	Select "Delete".

•	You should now have 5 regular and 2 special answer fields. Above every answer field, you see a notice in the format: "n: v". This shows the number of that answer field within this question, and its value. For the special answer fields, the value is not displayed, but you see either "¬Can" (Not Can) or "¬Want" (Not Want).

•	Optional detour: adding answer fields, and nonstandard layouts:

•	Please note that in the new standard layout, the two special answer fields are the first ones (Number 1 and Number 2) that have (automatically) been added to a question, whereas in many previously made questionnaire definition files, they were (manually) added last.

•	The reason for adding the special fields first, is this: When you "add" another answer field (while there is no neighbouring question that contains a sufficient number of answer fields to be useful as a template), AnyQuest extrapolates the position and the size of the new answer field from the positions and sizes of the two preceeding ones.

•	You can try out now what that means:

•	Click-Right onto the question background, where there is no other object, and select "Add answer field".

•	A new answer field number 8 will appear to the right of answer field number 7; it will be a regular answer field, and it will have the same size as answer fields number 7 and 6. The distance between answer field number 8 and number 7 will be the same as the distance between number 7 and number 6. If you add another answer field, it is positioned and sized using the same method.

•	But if the last answer fields of this question had been one or two special ones (special type, special size, special position), extrapolation wouldn't have worked in such a useful way. Nor would it have worked in any predictable and consistent way for any question containing either two or any higher number of regular answer fields.

•	So designating answer fields number 1 and 2 to be the two special ones, is a very good and very useful idea that should be observed whenever you design a new question layout (even more true, as I have not provided a menu entry to "Insert" an answer field yet - maybe that will be added later).

•	If you want to add more answer fields fast, you can simply type [a][a] (Answer field - Add) repeatedly.

•	Position extrapolation is limited to available screen space, so that the newly added answer field and its label should remain on the screen.

•	Note regarding nonstandard layouts: Having added one or multiple answer fields in this way, you can either manually move them to their target positon, or apply the auto-arranger buttons from "Question" - "Options" as described below. You can arrange them in vertical or multiple-row layouts, and both, position extrapolation for new answer fields, and manual or automatic arrangement, may both be used as required e.g. specifically to generate multi-column layouts. Should you prefer programming over graphic editors, you could write a "*.qdt" questionnaire definition text file, which AnyQuest could execute - all of this is beyond the scope of this quick guide.

•	If you added one or more answer fields just now to experiment with that function, please delete them again right now. If you changed positions of the first 5 answer fields, please try to coarsely re-arrange them so that they have the same vertical position, and the same horizontal and vertical size (optionally using the grid lock feature). The quick guide needs exactly 5 regular answer fields to continue as expected (and if you didn't perform too many editing steps on this detour, you can try out the "Undo" functionality right now).

•	Back from the answer field adding detour...:

•	Click-Right onto the text area of the question (currently reading: "New question").

•	Select "Options".

•	Make sure that "Selected items only" is not checked.

•	Make sure that "Only regular answer fields" is checked.

•	Click-Left on "Center H". Your remaining regular answer fields are being arranged horizontally, with their midpoints in the specified distance, and the center of all midpoints in the middle of the screen. Please note: The "rel" button next to the "Center H" button would also arrange the applicable answer fields. However that button would spread them across the space defined by the leftmost and the rightmost applicable answer field, while making sure that the distance between adjoining answer fields is the same throughout. Whereas the "Center H" button is more suitable to produce a simple standard arrangement very quickly, the corresponding "rel" button is more suited to distributing answer fields of the same size or of different sizes equally in a freely selectable area of the screen. The "Center V" and the corresponding "rel" button work similarly in the vertical direction.

•	Just for fun:

•	Enter "20" at "Distance of labels".

•	Make sure that "Selected items only" is not checked.

•	Make sure that "Only regular answer fields" is checked.

•	Click-Left on any of the four buttons right to that field and watch the labels move.

•	Finally, Click-Left on the lower button of the four.

•	Please note: If you want to automatically arrange the labels of special answer fields with this function, you can either select these labels first, and then apply the function to "Selected items only". Or, you can first arrange all labels (i.e., having neither of the two options checked) (typically) to the right of their answer fields, and then check the option "Only regular answer fields" to re-arrange only the labels of regular answer fields in a different manner (typically below their answer fields).

•	Click-Left on "ok", to close the "Question" - "Properties" dialog.

•	Click-Left somewhere into the main window, where there is no questionnaire object, to make sure that no object is selected.

•	Press and hold down the [Ctrl]-key (On German keyboards: [Strg]).

•	Still holding down the [Ctrl]-key: Click-Left once on every answer field label of any regular answer field (the label is the text below each answer field).

•	Release the [Ctrl]-key. Now, all labels of all regular answer fields should be selected, and surrounded by one selection frame.

•	Click-Right somewhere into the middle of the selection frame around the answer fields, avoiding the handles.

•	Select "Text".

•	Enter "extremely bad" and Click-Left on "ok".

•	Enter "quite bad" and Click-Left on "ok".

•	Enter "average" and Click-Left on "ok".

•	Enter "quite good" and Click-Left on "ok".

•	Enter "extremely good" and Click-Left on "ok".

•	The standard answer fields come with default numerical values. Answer field values are usually predefined and numeric, and they are typically used to score a questionnaire. The following steps demonstrate how to change the predefined value of an answer field:

•	Click-Left somewhere into the main window, where there is no questionnaire object, to make sure that no object is selected.

•	Click-Right on the leftmost answer field.

•	Select "Numeric or text value".

•	Enter "0" and Click-Left on "ok".

•	Alternative method, to speed up editing:

•	Position the mouse pointer over the leftmost answer field.

•	Using the keyboard, type [a][n] (Answer field - Numerical or text value).

•	Enter "1" and Click-Left on "ok".

•	We're now back at the original value. You could change the value of each answer field individually as described here, according to the requirements of your questionnaire.

•	(Another method is available to transfer multiple values from a text file onto multiple answer fields very fast.)

•	(That said, AnyQuest supports text, special or undefined, and dynamically changing answer field values, as well as other approaches to get from patient answers to questionnaire scores.)

•	Click-Left somewhere into the main window, where there is no questionnaire object, to make sure that no object is selected.

•	Click-Right on the text area of the question (currently reading "New question").

•	Select "Text". (To speed up editing, instead of clicking and selecting, you could have typed: [q][t][e] (Question - Text - Edit).)

•	Enter "How did you feel physically?" and Click-Left on "ok".

•	Click-Right on the text area of the explanation (currently reading "New explanation").

•	Select "Text". (To speed up editing, instead of clicking and selecting, you could have typed: [e][t][e] (Explanation - Text - Edit).)

•	Enter "During the last week..." and Click-Left on "ok".

•	Click-Right on the text area of the explanation 2 (currently reading "New explanation 2").

•	Select "Clear Text". (To speed up editing, instead of clicking and selecting, you could have typed: [2][t][x] (Explanation 2 - Text - eXtinguish).)

•	In the new standard layout, the positions of all text items have been pre-arranged to a typical questionnaire requirement. However, you can freely reposition all elements, e.g. if you require a vertical or multicolumn arrangement of answer fields. If you want to try out:

•	Click-Left somewhere into the main window, where there is no questionnaire object, to make sure that no object is selected.

•	Click-Left in the middle of the text area of the explanation (currently reading "During the last week...") and drag it upwards to between the short questionnaire name and the question.

•	Click-Right on the text area of the explanation (currently reading "During the last week...").

•	Select "Position" - "Center x at 0.5 window".

•	Click-Left in the middle of the text area of the question (currently reading "How did you feel physically?").and drag it further downwards about to the middle between the answer fields and the first explanation text area.

•	Click-Right on the text area of the question (currently reading "How did you feel physically?").

•	Select "Position" - "Center x at 0.5 window".

•	If you want to return to the originally suggested positions, use the "Undo" functionality as required.

•	(You could also move any border of one or multiple selected items separately; and you could youse various functions to align selected items, or to copy and paste positions and sizes.)

•	(You can use the grid lock functionality to easily achieve properly aligned items, distances conforming to a given raster, symmetry etc. - but you can also monitor the displayed position and size of the cursor and a selection in the left bottom area of the screen.)

•	(Should your questionnaire include a series of similarly constructed questions with varying amount of text (e.g.: 1 line, 2 lines, 3 lines), I recommended the following approach: Use the same question text field size and position for all questions, that can accomondate the longest question text. For questions with a single line, add 1 empty line above the question text. For questions with 3 lines, don't. For questions with 2 lines, decide depending upon your remaining layout. Thereby, all text lines of all questions will fall into the same y-raster, providing a consistent screen appearance, without any work to align the upper or lower text field border individually per question.)

•	Adding further questions in the same layout as the first one:

•	Click-Left somewhere into the main window, where there is no questionnaire object, to make sure that no object is selected.

•	Click-Right somewhere into the main window, where there is no questionnaire object.

•	Select "Add question". Note changed status display at lower right corner. And note that the new question appears in the layout of the last one!

•	Click-Right on the text area of the question (currently reading "New question").

•	Select "Translation utilities" - "Copy text from previous similar item". (To speed up editing, instead of clicking and selecting, you could have typed: [q][t][f][p] (Question - Text - From - Previous).)

•	Click-Right on the text area of the question.

•	Select "Text".

•	Change text to"How did you feel mentally?". (If you have actually copied the text dictated above, you can just mark "physical" with your mouse and then immediately type "mental".)

•	Click-Left on "ok". (Or just press [Enter].)

•	Click-Right somewhere into the main window, where there is no questionnaire object.

•	Select "Add question". Note changed status display at lower right corner. And note that the new question appears in the layout of the last one!

•	Click-Right on the text area of the question (currently reading "New question").

•	Select "Text".

•	Enter "How would you judge your ability to work in your job?".

•	Click-Left on "ok".

•	Adding further questions in another layout, streaming in text from a text-file:

•	The next five questions will use a Visual Analogue Scale, and I will illustrate a quicker mode of question generation. So please:

•	Click-Right somewhere into the main window, where there is no questionnaire object.

•	Select "Add question". Note changed status display at lower right corner. And note that the new question appears in the layout of the last one!

•	Click-Right on the question text area (currently reading "New question").

•	Select "Options".

•	Select "LASA / VAS".

•	Click-Left on "ok".

•	Now you can see that your question type has changed from "Discrete answers" to "Linear Analog Scale"/"Visual Analog Scale".

•	You can also see that AnyQuest supports LASA / VAS with multiple anchors; the value of each anchor can be freely defined just like the value of an answer field. When a patient places a cross anywhere on the LASA / VAS, AnyQuest will interpolate linearly between the two neighbouring anchors to obtain the numeric value of this question. (If you want other methods of interpolation, you can use result formulas in a later stage.)

•	Click-Right on the middle anchor (or position marker, or ex answer field).

•	Select "Delete".

•	Click-Right on the anchor (ex answer field) left of the middle.

•	Select "Delete".

•	Click-Right on the anchor (ex answer field) right of the middle.

•	Select "Delete".

•	Click-Right on the leftmost anchor (ex answer field).

•	Select "Numeric or text value".

•	Enter "0" and Click-Left on "ok".

•	Click-Right on the rightmost anchor (ex answer field).

•	Select "Numeric or text value".

•	Enter "100" and Click-Left on "ok".

•	Click-Right on the leftmost answer field label (currently reading "extremely poor").

•	Select "Text".

•	Enter "lousy".

•	Click-Right on the rightmost answer field label (currently reading "extremely good").

•	Select "Text".

•	Enter "excellent".

•	Click-Left on "ok".

•	Look at your new LASA / VAS scale. Is its width is too small or too large? You can easily change it:

•	Click-Right on the question text area (currently reading "New question").

•	Select "Options".

•	Triple the number in the "Distance" field and Click-Left on "Center H". (The original number specified the distance between two adjoining answer fields; we've taken out three, so the LASA / VAS scale was originally four distances long. The value is specified in pixels on the screen. I think a standalone LASA / VAS scale might cover about 60% to 80% of the screen width. You may repeat the procedure to find a length that you like, and you may move the "Question properties..." dialog to the side if it obstructs your view of the scale, by grabbing its title bar with the mouse.)

•	When the length of your scale is quite right, Click-Left on "ok" to close the "Question properties..." dialog.

•	(You can just as well select and move the anchors individually (just as if they were still answer fields), but using the "Question properties..." dialog is more comfortable, as most standalone LASA / VAS scales shall be horizontally centered on the screen.)

•	(The height of the scale-whiskers (or x-markers) is determined by the y-range covered by all of the included answer fields. To change it, you can either select each involved answer field and change its vertical size separately, or select all included answer fields by holding [Ctrl] and then clicking onto each included field, and then change the size of all fields at the same time.)

•	(As of version 3.37, there is no support for vertically arranged or two dimensional LASA / VAS scales yet. If you need that, please tell me; it can be added. Alternatively, if you use a pen computer or tablet PC, you can just place it into portrait orientation, and optionally use text elements which have been pre-rendered in bitmap images rotated by 90 degrees.)

•	Now for accelerated generation of questionnaire definition files:

•	If you have your source questionnaire in a word processor file already. you can probably transfer it rather easily into a simple text file.

•	You can import such a text file into a questionnair definition in one step. This will save you from typing (or copy-and-pasting) the text of all questions individually by hand.

•	For this example, I shipped the file 5demoqns.txt, which you will find in your directory c:\anyquin. This file includes the text of one question per line.

•	You can open and review this file with the simple text editor "notepad", usually available via "Start" - "Programs" - "Accessories" - "Notepad" or "Start" - "Programme" - "Zubehör" - "Editor".

•	If you do not know how to generate such a text file from your questionnaire, that comes as word processor document or PDF, then you can still proceed as shown during the last sections - or ask a knowledgeable friend for help. In MS Word (or OpenOffice) you can specifically deploy the advanced text search and replace options to extract (and possibly reformat) question text lines from complete questionnaires in semi-automized manner. This can save a lot of typing, especially for technically cleanly prepared word documents. More advanced users might also deploy editors with "regular expression" support going beyond the capabilities of the common office products.

•	To quickly import the prepared demo-text-file, however, do the following now:

•	From the menu "Jörg's Magic Questionnaire-o-Matic", select "Spread a text file to questions".

•	Select the file c:\anyquin\5demoqns.txt and Click-Left on "ok". Please note the changed status display, showing a new total number of questions, at the lower right corner of the screen.

•	Other Questionnaire-o-Matic functions can import and spread explanations, answer field labels and answer field values from text files. If you start the import process at any given question (screen), AnyQuest will use up update the text for any succeeding questions/items which are available, and afterwards add new questions using the same layout as the preceeding one or any currently set prototype question.

•	One specialized Questionnaire-o-Matic function can aid in the distribution of sound filenames onto text items to simplify creation of talking questionnaires.

•	Reviewing all questions:

•	On the transport bar, Click-Left on "<" and ">" to have a look at all questions - 3 created manually, and 5 completed automatically after the preparation of one question with the desired layout. (Alternatively, you can use the [PageUp], [PageDown], [Home] and [End] keys, or [BildHoch], [BildNachUnten], [Pos1] und [Ende] on a German keyboard.)

•	Defining a conditional branch formula, to implement non-linear questionnaires:

•	In this section, you will learn how to ask one question ("Did you need pain medication?"), and to skip another one ("How effective was it?") depending on the answer to the first one.

•	Using the buttons "<" or ">" in the transport bar, display question nr. 7 referring to pain control.

•	Click-Right somewhere in AnyQuest's main window, where there is no other object.

•	Select "Insert question".

•	Click-Right on the question text (currently reading "New question").

•	Select "Text".

•	Enter "Did you require medication for pain control?" and Click-Left on "ok".

•	Click-Right on the question text.

•	Select "Options".

•	Select "Discrete Answer, Single Check".

•	Reduce the value in"Distance". If you doubled it before, now divide it by two. Or try something around 20% of your screen width in pixels.

•	Click-Left on "Center H".

•	Click-Left on "ok".

•	Click-Right on the left answer field label.

•	Select "Text".

•	Enter "No" and Click-Left on "ok".

•	Click-Right on the right answer field label.

•	Select "Text".

•	Enter "Yes" and Click-Left on "ok".

•	Click-Right on the right answer field.

•	Select "Numeric or text value".

•	Enter "1" and Click-Left on "ok".

•	Click-Left on the button ">" on the transport bar to display question nr. 8 of 10 referring to pain control.

•	From the menu"Edit", select "Edit conditional branch formulas...".

•	In the field "UPN Condition for execution of command", please enter: "v7 0 =". This formula means: take the value of question nr. 7 and test wether it is equal to zero. If yes, the result of the formula will be "true", and the command specified below will be executed.

•	The preselected command, "Skip this question", is adequate here.

•	Click-Left on "ok" to close the CB formula editing window.

•	Defining result formulas for computation of questionnaire results (scoring a questionnaire):

•	From the menu"Edit", select "Edit result formulas".

•	When the edit window opens, the last result formula of the current questionnaire definition is displayed and selected.

•	At the moment, no result formula is defined. So result formula number 0 is displayed.

•	If you wish to, you can use the transport bar even while the formula editing window is displayed to review your questions while constructing formulas.

•	Click on the upward arrow right to the "0" in the field "Formula# to add the first formula to this questionnaire definition.

•	Click into the field "UPN Formula"

•	The field is probably empty right now. Otherwise, erase what is in there completely, or if it is completely selected, leave it selected: What is selected, will be replaced by the next character you enter.

•	Then type "v2 1 - 25 *" into the field. This formula means: Take the value of question 2. Subtract 1. Multiply by 25. As question 2 is of the "Discrete answers, single check" type, and all its regular answer fields have numeric values, the numeric value of that question will be the numeric value of the single checked answer field, or "undefined" if "Can't answer" or "Don't want to answer" have been checked.

•	As the answer field values ranged from 1 to 5, the result of this operation will range from 0 to 100. So the "Bar Min" and "Bar Max" settings, which control whether this result shall be displayed as a (bar- or other)graph, and which range that graph shall cover, are ok.

•	Click-Left into the input area for "File output label".

•	Type "Physical wellbeing".

•	Click-Left into the input area for "Single printout label".

•	Type "Physical wellbeing".

•	Click-Left into the input area for "Cumulative printout label".

•	Type "PWB".

•	Delete everything from the three fields for "Suffix". (AnyQuest supports a suffix (like %, kg, m etc., it should not contain a space), many third party programs do not and its use generally makes formally correct postprocessing of result files more difficult.)

•	Click-Left onto the arrow pointing upwards next to "Formula#" (top left area of window). Formula #2 should appear.

•	Recent versions of AnyQuest will analyze the content of the "UPN Formula" and "... Label" fields of the preceeding (or succeeding) formula, when pre-filling the input fields of a newly added or inserted formula. If the old content ends with any decimal number, that number will be incremented by 1 if possible, and the result will be pre-filled. For the "... Label" fields, however, if the old content begins with "Result Nr. ", the pre-filled content will be synthesized from "Result Nr. n", where n is the current formula number. Otherwise, the old content of the preceeding (or succeeding) formula will be copied without change and pre-filled. This approach turns out to match various real life requirements quite well, thereby supporting efficient definition of result formulas.

•	Please note that all other options of the formula definition dialog have been copied from the preceeding formula to the new one. Therefore, when you define a number of similarly structured formulas: Make sure all options are correct for the first one, before you add the others.

•	Click-Left into the input area for "UPN Formula", just right of the "v2".

•	Change "v2" into "v3". The formula "v3 1 - 25 *" now means: Take the value of question 3. Subtract 1. Multiply by 25.

•	Click-Left into the input area for "File output label".

•	Change into (or type) "Mental wellbeing".

•	Click-Left into the input area for "Single printout label".

•	Change into (or type) "Mental wellbeing".

•	Click-Left into the input area for "Cumulative printout label".

•	Change into (or type) "MWB".

•	Click-Left onto the arrow pointing upwards next to "Formula#". Formula #3 should appear.

•	Click-Left into the input area for "UPN Formula", just right of the "v3".

•	Change "v3" into "v4". The formula "v4 1 - 25 *" means: Take the value of question 4. Subtract 1. Multiply by 25.

•	Click-Left into the input area for "File output label".

•	Change into (or type) "Role function".

•	Click-Left into the input area for "Single printout label".

•	Change into (or type) "Role function".

•	Click-Left into the input area for "Cumulative printout label".

•	Change into (or type) "RF".

•	Click-Left onto the arrow pointing upwards next to "Formula#". Formula #4 should appear.

•	Click-Left into the input area for "UPN Formula".

•	Clear the currently displayed formula using backspace, [Del] or [Entf]. Enter "v5 v6 2 avg". This formula means: Take the values of questions 5 and 6. Compute the average of these 2 values.

•	Please note: For the avg and sum functions, AnyQuest honours the "required quota of answered questions": If the given percentage of individual questions which are processed to compute an average or a sum have been answered, then the numerical result is computed. If fewer answers are available, the result is returned as "undefined". So if your questionnaire scoring manual states that you should compute (and extrapolate) a result if 50% of the answers are available, you can simply use the avg or sum functions, specify the required quota, and you're done. (To sum up multiple questions of the same answer value range with extrapolation, you may use avg and multiply with the number of questions - please understand the different effects of summing and averaging when individual answers are missing. Finally, the requrired quota setting can be changed within a formula, so yes, you can specify different quotas for different components of a given computed result...)

•	If you want to allow one missing answer (out of two), and still have this result computed: Enter 50 (or anything between 0 and 50, as we only process two questions here) into the "required quota of answered questions" field for this result formula.

•	Click-Left into the input area for "File output label".

•	Change into (or type) "Social function".

•	Click-Left into the input area for "Single printout label".

•	Change into (or type) "Social function".

•	Click-Left into the input area for "Cumulative printout label".

•	Change into (or type) "SF".

•	Click-Left onto the arrow pointing upwards next to "Formula#". Formula #5 should appear.

•	Click-Left into the input area for "UPN Formula".

•	Clear the currently displayed formula using backspace, [Del] or [Entf]. Enter "v7 y7". This formula means: Take the value of question 7 to produce the numeric result of this result formula - and take the text from the labels of all checked answer fields of this question to produce the (character-)string result of this formula.

•	Click-Left into the input area for "Bar max".

•	Change into (or type) "0". The numerical result of the question will be either 0 or 1 (or undefined). But we do not want a bargraph here at all. We want to see the text result instead, so using 0 for both "Bar min" and "Bar max" effectively turns the bargraph off.

•	Click-Left into the input area for "File output label".

•	Change into (or type) "Pain medication required".

•	Click-Left into the input area for "Single printout label".

•	"Pain medication required".

•	Click-Left into the input area for "Cumulative printout label".

•	Change into "PMR".

•	Click-Left onto the arrow pointing upwards next to "Formula#". Formula #6 should appear.

•	Clear the currently displayed formula using backspace, [Del] or [Entf]. Enter "v8". This formula means: Take the value of question 8.

•	Click-Left into the input area for "Bar max".

•	Change into "100", because this scale (and the following ones) will return results from 0 to 100, and we want to get bargraphs again.

•	Click-Left into the input area for "File output label".

•	Change into "Pain control".

•	Click-Left into the input area for "Single printout label".

•	Change into "Pain control".

•	Click-Left into the input area for "Cumulative printout label".

•	Change into "PC".

•	Click-Left onto the arrow pointing upwards next to "Formula#". Formula #7 should appear.

•	You don't need to update the UPN formula - AnyQuest has already done it automatically by the mechanism described above.

•	The automatically adjusted formula "v9" means: Take the value of question 9.

•	Click-Left into the input area for "File output label".

•	Change into "Appetite".

•	Click-Left into the input area for "Single printout label".

•	Change into "Appetite".

•	Click-Left into the input area for "Cumulative printout label".

•	Change into "AP".

•	Click-Left onto the arrow pointing upwards next to "Formula#". Formula #8 should appear.

•	You don't need to update the UPN formula - AnyQuest has already done it automatically by the mechanism described above.

•	The automatically adjusted formula "v10" means: Take the value of question 10.

•	Click-Left into the input area for "File output label".

•	Type "Global QoL".

•	Click-Left into the input area for "Single printout label".

•	Type "Global QoL".

•	Click-Left into the input area for "Cumulative printout label".

•	Type "GQL".

•	Now, just close the formula editing window (Windows 95/NT 4.0 etc.: Click-Left on "X" in its top right corner, Win 3.x: From AnyQuest's main menu, deactivate "Edit" - "Edit result formulas", or use [Alt]+[F4], or click right on the dialog window title bar, or use [Alt]+[Space] to bring up the system menu of the dialog and then select "Close".

•	Please note that AnyQuest's UPN formula definition language provides much more sophisticated possibilities than demonstrated here. Notably, it includes statements to communicate with external programs, so questionnaire scoring can also be completely or partly delegated to them, or routines for cryptographic signing or for database exchange could be called and their results included in AnyQuest's result files or printouts. Text inline UPN formulas enable you to substitute portions of questionnaires by dynamically computed expressions, and advanced printout definition and reference files, as well as quite versatile printing target options, provide a multitude of possibilities beyond what is shown in this quick guide.

•	Please don't forget to review the respective sections in this on-line help to learn more. You may also study the examples given by the provided questionnaire definition files (result formulas, conditional branching formulas, and text inline formulas).

•	Adding comments on questionnaire copyright, history, or literature references:

•	If you generate or modify an electronic questionnaire definition file, you can add some documentation in a protected area of the questionnaire. Information from this area cannot be removed easily, after a questionnaire definition file has been saved.

•	From the menu "Help", select "Questionnaire Copyright & History".

•	Click-Left on "Add information".

•	Write "AnyQuest for Windows demonstration Quality-of-Life-Style-Questionnaire."

•	Type [Ctrl][Enter] (on German keyboards: [Strg][Enter]).

•	Type [Ctrl][Enter] again.

•	Write "Generated by " + your name + ", following the Quick guide from AnyQuest's help file on the " + the current date.

•	Type [Ctrl][Enter] twice.

•	Write "AnyQuest was first developed for the original Quality-of-Life Recorder:"

•	Type [Ctrl][Enter] twice.

•	Write "Sigle-JM, Porzsolt-F: Practical aspects of quality-of-life measurement: design and feasibility study of the quality-of-life recorder and the standardized measurement of quality of life in an outpatient clinic, Cancer Treatment Reviews (1996) 22 (Supplement A), 75-89"

•	Click-Left on "Add information permanently".

•	You can review all added information using the scrollbars.

•	Click-Left on "Close".

•	Saving your newly generated electronic questionnaire definition:

•	Select "File" - "Save as".

•	Keep your directories tidy: double-click on the subdirectory questns under c:\anyquin. This is, where questionnaire definition files should go.

•	Enter the filename: qldemo. You do not need to supply an extension, but please be sure NOT TO enter a trailing dot, either!

•	Click-Left on "ok".

•	Please note: Originally, I devised a directory tree structure that has separate directories for questionnaire definition files, configuration files, collected data etc. directly below the AnyQuest for Windows main directory. Project specific, or questionnaire category specific subdirectories were arranged below them.

•	However, in the meantime I found it more useful to generate one project specific subdirectory directly under the AnyQuest for Windows main directory - and to arrange all the standard subdirectories for questionnaire definition files, configuration files, collected data etc. which belong to one project below this project specific subdirectory. Thereby, you can handle (backup, copy, move, inspect) all project related ressources from one subdirectory, and that turned out to be more practical than the original suggestion: When you want to copy the questionnaires required by your project to another machine, you will usually also want to copy the configuration files prepared for the same project. Etc.

•	Changing the AnyQuest environment from optimal for editing to optimal for applying questionnaires:

•	Deactivate "Edit" - "Edit layout".

•	Deactivate "Display" - "Show long questionnaire name".

•	Deactivate "Display" - "Show short questionnaire name".

•	Deactivate "Display" - "Show questionnaire number".

•	Deactivate "Display" - "Show question number".

•	Deactivate "Display" - "Show numeric and string results of question". (You can keep these activated, if you wish to test drive your newly generated questionnaire. I do not regularly show them to patients to keep the display simple.).

•	Deactivate "Display" - "Show Can't/Don't want to answer". While you should display these fields during the editing process, I recommend you to hide them for most common questionnaire administrations and for most patients. Do however instruct patients that they shall call you (or a nurse) when they have any difficulties with the questionnaire. If a patient reports that they cannot or do not want to answer a given question, you can bring up (and hide) the special answer fields by clicking for times in a row in the lower left region of the screen (if you should not have intentionally disabled that option in the configuration file).

•	If you wish to receive any printout, Select "Printing" - "Printer setup". You can either leave everything as it is. Or you can specify one printer to be used for all kinds of printouts, and leave all other fields empty. Or you can specify different printers for the different printout types - and you can even specify a second printer for certain printout types. This feature can be used to e.g. print a cumulative result onto real paper first, and a second copy to a virtual printer that places a PDF in a predefined directory (for archiving or for insertion into an electronic patient file or just for comfortable, paper-less access from a physician's workstation).

•	If you wish to receive a questionnaire-filled-in-alike printout, then activate "Printing" - "Automatic QFI printout". Otherwise, deactivate "Printing" - "Automatic QFI printout". I recommend to produce QFI printouts into PDF files, which are automatically placed into a predefined directory. So when doctors want to review a patient's answers in detail (after an interesting computed test result, or to complement the history obtained in person), they can have a look at the QFI PDF, which can be much more easily understood than the questionnaire raw data in the AnyQuest result file.

•	If you wish to receive a single printout, then activate "Printing" - "Automatic single printout". Otherwise, deactivate "Printing" - "Automatic single printout".

•	If you wish to receive a cumulative printout, then activate "Printing" - "Automatic cumulative printout". Otherwise, deactivate "Printing" - "Automatic cumulative printout". This printout type automatically provides course over time graphical output for all numerical variables.

•	Activate "Navigation" - "Automatic proceeding to next question".

•	Activate "Navigation" - "Use filler blind when automatically proceeding". This inserts a white screen between two questions, so that patients can see more easily that a new question appears (even when e.g. only a single word has changed on the screen).

•	Activate "Navigation" - "Automatic check, calculate, output & erase after last question".

•	Activate "Navigation" - "Disable questionnaire browsing in setup mode". This protects your patients from accidentally filling in a questionnaire in setup mode, i.e. without starting a new session and entering a PID etc. first. Questionnaire functionality in setup mode is, however, useful if you want to test individual questions (especially with regard to conditional branch formula functionality) during the editing process, without having to complete the whole questionnaire.

•	Deactivate "Navigation" - "Show transport bar".

•	Activate "Navigation" - "Show individual transport buttons". This leaves the patient the option to go back exactly one question without the need to call you for support. More details can be specified in the configuration file.

•	Activate "Navigation" - "Patient identification options to ask for" - "Ask for first name". All of these fields can be accessed (for reading and writing) by AnyQuest's UPN formula definition language. This means that you can display a patient's ID throughout a questionnaire, or that you can use custom fields to collect any standard patient ID variable. Moreover, functionality is provided to obtain patient information data from external systems. The fields can be "tuned" or abused; as the invitations displayed for all parameters, as well as on printouts etc. can be specified in the applicable *.msg file.

•	Activate "Navigation" - "Patient identification options to ask for" - "Ask for last name".

•	Activate "Navigation" - "Patient identification options to ask for" - "Ask for date of birth". This is required if AnyQuest shall compute the patient's age at the date of test. The applicable date formats (DD.MM.YYYY or YYYY-MM-DD) for collection and for printout can also be selected in the applicable *.ini file.

•	Activate "Navigation" - "Patient identification options to ask for" - "Ask for patient ID code". An alphanumeric PID code is recommended to reliably identify one person (even when their name or date of birth might change - both things may occur in real life). If you activate PID recognition, AnyQuest will recognize a PID and fill in the other PID fields from data obtained in previous questionnaire administrations.

•	Activate "Navigation" - "Patient identification options to ask for" - "Ask for PID first".

•	Activate "Navigation" - "Patient identification options to ask for" - "Recognize PID in followup sessions".

•	Deactivate "Navigation" - "Patient identification options to ask for" - all other ID options. These options include the fields from the German Health Insurance Card, as well as fields for many parameters commonly used in clinical studies. If you combine them with PID recognition, be sure to indicate fields that shall be manually filled in at each questionnaire administration, even if a patient has been recognized (e.g. and most commonly: therapy cycle).

•	Now close AnyQuest for Window, e.g. by selecting "File" - "Exit". This saves all currently selected options and the currently loaded set of questionnaires (only one, in this example) in the currently used initialization file (if that file is not write protected, either by the operating system's mechanisms, or had a respective parameter set inside the file).

•	More comprehensive guides on how to plan, prepare and secure AnyQuest for Windows configurations are avaliable elsewhere in this on-line-help and on www.ql-recorder.com in the "Docs+Support" section.

Performing questionnaire administration sessions:

•	From the Windows 95 / NT 4.0 etc. start menu or from the Windows 3.x program manager, start AnyQuest for Windows (with a specifically prepared configuration, or with the one that you used to generate your questionnaire definition file).

•	Please note that the navigation window appears and that your questionnaire is already loaded. (Otherwise, your configuration file was write protected, has not been prepared, or has not been specified in the link used to start the program, or the specified questionnaire definition file could not be loaded.)

•	Please note that the content of the background behind the navigation window, and the buttons displayed in the navigation window, can also be configured.

•	Click-Left on the "Go" button.

•	Follow the instructions and answer all questions once.

•	Click-Left on the "Go" button again, if you wish to perform further questionnaire sessions, or Click-Left on the "Exit" button, if you're done.

•	More comprehensive guides on how to plan and perform questionnaire administrations are avaliable elsewhere in this on-line-help and on www.ql-recorder.com in the "Docs+Support" section.

Data export and evaluation:

•	Now let's go for data export into MS Excel 97 as an example:

•	From the Windows 95 / NT 4.0 etc. start menu or from the Windows 3.x program manager, start AnyQuest for Windows. Note that the navigation window appears and that your questionnaire is already loaded.

•	Click-Left on the "Setup" button.

•	Select "File" - "Generate export file...".

•	Click-Left on "ok", leaving the export options unchanged (but note the export data file name).

•	Click-Left on "ok".

•	Close AnyQuest for Windows.

•	Open MS Excel 97.

•	Select "File" - "Open".

•	In the file-open-dialog, select the file c:\anyquin\data\anyquin.dif (or another export data file name as noted above) and click on "open".

•	Confirm the import-options suggested by Excel's ASCII-File-Import assistant.

•	Scroll around in your table and enjoy your data.

•	More comprehensive guides on how to export and analyze collected data are avaliable elsewhere in this on-line-help and on www.ql-recorder.com in the "Docs+Support" section.

Beyond the questionnaire definition file:

To produce one or multiple complete configuration(s) for a given project, study, or patient group, you would typically add the following steps:

•	Select, and optionally adopt to your needs, a "message file" *.msg that contains general messages e.g. to ask for the name of a patient.

•	Prepare a dedicated "configuration file" *.ini which may be derived from the standard file anyquin.ini, or from another configuration file supplied in a downloadable package, or from any ocnfiguration file that you already use at your site. A configuration file specifies which message file to use, which questionnaire definition file(s) to use, which patient ID data and other information to collect before the questionnaire administration, which external programs to reference for several standard tasks, where to store data (and optionally which network drives to map for that purpose or similar tasks), which display and printing options to use, etc. etc.

•	Put all the components that belong to your newly made configuration into a suitable subdirectory tree, following some standard conventions. This may be located on the computer used to aminister the electronic questionnaire, or on a network drive.

•	Create a shortcut to start AnyQuest for Windows with the newly made configuration file.

•	Perform any additionally desired preparation that may be desired to simplify the usage of an electronic questionnaire (auto-login, auto-start), improve security, or integrate it into an existing IT environment.

When a configuration has been completely prepared, the Quality-of-Life Recorder can either simply be switched on and then automatically start that configuraion with a given (set of) questionnaire(s), with all applicable configurable options set as desired, without any other user intervention, or a menu will be available from which one of the available configurations can be started.

Please note that one configuration can include multiple questionnaire definition files for various electronic questionnaires, plus one questionnaire definition file that serves as a menu from where any of the other loaded questionnaires may be selected for usage in a given questionnaire administration session.

•	More comprehensive infomation on all of these topics is avaliable elsewhere in this on-line-help and on www.ql-recorder.com in the "Docs+Support" section.

Other topics:

A more systematic presentation of the following topics is included elsewhere in this on-line-help:

•	You can load more than one questionnaire definition file at the same time and they will be presented to patients one after another automatically.

•	Configuration files can be used to maintain multiple configurations for various questionnaires, languages, studies, projects or patient groups available and readily usable on the same hardware system.

•	Networking is supported for program provision, data storage, communication with external applications, and various possibilities.

•	There are other possibilities to search, display and print your data, including, but not limited to built in Analysis tools.

•	When the AnyQuest for Windows executable file anyquin.exe is directly started, without provision of a configuration file as parameter, it will most probably use (or create) a default configuration file anyquin.ini, and also use the message file anyquin.msg located in the same directory. This may be useful for editing purposes, but the controlled and knowledgeable usage of configuration- and message files is recommended for normal system operation. German users, however, could just rename or remove the file c:\anyquin\anyquin.msg to make built in general messages appear in the German language for the directly started executable. Message files in various languages (English, German, Swedish, French, Chinese, Greek etc. etc.), as well as configuration file examples, are however available and usually located in the config subdirectory, and specified by a given *.ini file. You can review, configure, and extend or translate these files using a simple text editor (e.g. notepad) instead.

More advanced topics that might simplify your work or enhance your possibilities include:

•	c:\anyquin\questns\demo\prototyp.qdw, using prototype and anchor questions.

•	save a lot of typing and clicking with Jörg's Magic Questionnaire-o-Matic,

•	produce simple, cleanly arranged layouts using the editing grid,

•	keyboard commands for faster editing,

•	advanced editing support, translation utilities,

•	general editing tools, including versatile text-search-and-replace functionality,

•	undo-functionality and crash-recovery,

•	exporting and importing sets of questions among questionnaires,

•	precautions for support of different display resolutions

•	preparing a system for convenient use of multiple sets of questionnaires, or multiple configurations,

•	interrupting and resuming a single session with a patient,

•	complex interactive, and morphing questionnaires,

•	advanced result formulas, complex transformations of data

•	coding of text through answer fields,

•	can-not-answer, don't-want-to-answer data,

•	free text input fields,

•	processing of questionnaire raw data,

•	multimedia questionnaires including graphics and sound,

•	modular questionnaires and questionnaire libraries,

•	questionnaire library in the world wide web,

•	storage and (online-) exchange of data.

Here is the table of contents of the on-line-help file.

Topics that are listed but not hyperlinked from above, can also be explored using the comprehensive index and full-text search of this on-line help.

Additionall documentation and tutorials are available in the "Docs+Support" section of my WWW site at http://www.ql-recorder.com - especially, there are three PDFs from the eSIRO project (German language, with many images) which detail installation, customization, practical use and data analysis with the QL-Recorder. Additionally, the CD-ROM copy of the site provides several videos.


Jörg's Magic Questionnaire-o-Matic

You can use the functions from the menu "Jörg's Magic Questionnaire-o-Matic" to import plain text files and spread their contents onto elements of individual questions using one line for each question or answer field.

This feature can save you much typing and mouse-clicking work. It is extremely useful if you already have the text of a paper questionnaire in a word-processor file or if you can use a scanner with optical-character-recognition software to produce such a file.

The page you are currently reading first provides an overview explaining how you can use this feature practically. Afterwards it explains the individual functionality of the available menu options in detail.

General directions

To make the best use of Jörg's Magic Questionnaire-o-Matic, proceed like this:

•	First, get an overview of the whole questionnaire, identifying sections which have different layouts.

•	Switch on the display of questionnaire and question numbers in AnyQuest.

•	Load the supplied file prototype.qdw and look whether you can find prototype questions with suitable layouts in it.

•	For the first section with an individual layout, set the suitable prototype question from prototype.qdw, then add a new questionnaire, thereby adding the first question of your new questionnaire. If required, modify its layout exactly to your needs. It is, by the way, much easier, to remove excessive answer fields from a question than to add and position new ones, because in this case, the usually existing special answer fields will cause additional work.

•	Now prepare a plain text file which contains only those questions of your questionnaire, one question per line, which shall appear as the first section with similar layout. Save this text file with a name and location that you can find again, e.g. c:\anyquin\myqns.txt

•	Make sure that the first question of your new questionnaire is displayed in anyquest.

•	From the menu, chose "Jörg's Magic Questionnaire-o-Matic" - "Spread text file to questions". In the file dialog, select your text file, e.g. c:\anyquin\myqns.txt

•	You will notice that your text file has been turned (quite magically) into questions inside your new questionnaire. You may browse these questions and modify the individual question texts by inserting forced linebreaks ([Ctrl]-[Enter]) as required, to generate a homogeneously looking result.

•	Now follow the same procedure for the remaining sections with individual layout of your questionnaire, if required. You may use new text file names, of course.

•	Now follow the same procedure for explanations and second explanations if required.

•	Now follow the same procedure for answer field labels. Please note that Jörg's Magic Questionnaire-o-Matic will not create additional answer fields, and that it will only process "regular" answer fields.

•	Now follow the same procedure for answer field values. Make sure that you use the correct numeric format for your local environment. Avoid decimal separators if you don't need them.

•	Now ensure that all answer fields have their correct labels.

•	Add result formulas and conditional branching formulas as required.

•	Modify the questionnaire descriptors (version and language) as required.

•	Add questionnaire history and copyright information as required.

•	Save the resulting *.qdw file.

•	Move the text files you produced during this process to a folder with a self-explaning name of their own (you don't need them any more now, but you might need them in the future).

How can you prepare the required plain text files?

If you have a paper copy of the questionnaire: Type the required lines into notepad.exe, or use a scanner and optical character recognition software. Even in this case, be sure to review the product thoroughly, because such software usually requires high quality paper copies to obtain satisfactory results.

If you have an Adobe Acrobat PDF file, display it using the Adobe Acrobat Reader. If the file is not protected against that, you may be able to select text by using the respective tool or by pressing [Ctrl]-[A]. You can copy the selected text to the MS Windows clipboard and paste it into notepad.exe.

If you have an MS Word document, you may remove excessive text inside Word and save the remainder as a plain text file. The function "convert table to text" may be very helpful, and MS Word offers some advanced search/replace functionality which may help you in the removal of multiple spaces, multiple line breaks, excess new paragraphs and so on.

Instead of notepad, a software like TextPad (available as shareware) may be very useful, because it can automatically perform quite complex search/replace operations using so called "regular expressions", and even apply these to multiple files at the same time, and thus save you a lot of time when you e.g. want to remove line numbers from a set of questions.

In any case: The resulting file should be a plain text file, it should not contain any binary or formatting information which word processors typically include in their proprietary file formats, and it should usually use the Windows ANSI character set.

The text file should usually not have any trailing empty lines, (which means, that in your text editor, your cursor should not move below the last line containing any text, but only to the right end of that last line instead), because they would be translated to elements with empty text.

Spreading a text file to questions

The import process will start at the question which is currently displayed:

The first line from the text fill will be copied to the question text of the current question; following lines will be spread to the question texts of succeeding questions. If there are not enough questions in the current questionnaire, they will be added as required.

Before you invoke this feature, please give at least one starting question the layout which you would like to have for all of the automatically generated questions or prepare enough questions with individual layouts as required.

Spreading a text file to explanations and second explanations

These functions work exactly like the above one, except for that they spread text file contents to the explanation or second explanation element instead of to the question text.

Spreading a text file to answer field labels

In contrast to the above functions, this function will spread text file contents to answer field labels. Only "regular" answer fields are affected (this means, that "cannot answer"/"don't want to answer"/"direct text" answer fields and so on are skipped and not affected at all).

The function starts to search for the first eligible answer field beginning with the currently displayed question. If this question has no answer field, or when the last answer field of a question has been processed, the function will continue with the next available question of the same questionnaire. If a question has multiple eligible answer fields, they will be processed in the order in which they have been originally generated (which may be different from the order in which they are arranged on the screen).

If a question has regular answer fields which have been moved outside the screen, they will sill be found and processed by this function.

If there are more lines in the text file than eligible answer fields in the questionnaire, excessive lines of text will be ignored. This function will not create any new answer fields.

Spreading a text file to answer field values

This function works similar to the above one, but instead of processing answer field labels, it processes answer field numeric or coded values.

When the function transfers a line of text to an answer field value, it does not modify this text in any way. This means that the operator should make sure that the text is supplied in the correct format (e.g., using the correct decimal separator for the current environment, if any one is required).

Spreading a collection of audio files to texts

This one covers a completely different issue: Suppose you have a questionnaire definition file which you want to change into a talking questionnaire.

For this purpose, you should record one wave-file corresponding to each text item (question, answer field etc.) in the questionnaire, speaking its text into the wave-file. Give each wave-file a filename which contains the complete corresponding text (if that is very short), or the initial characters of each word in the corresponding text (not exceeding 8 characters for the filename).

Afterwards, you would theoretically have to right-click onto every piece of text which shall receive a wave-file, then select the corresponding wave-file in the dialog that appears, and click on ok to connect them.

Instead, you may prefer to use a special subsection of Jörg's Magic Questionnaire-o-Matic: It will try to distribute all available wave-files across all available texts, sorting them by the strength of the correlation between text content and wave-file-name. If in doubt, it will ask.

Thus the task may take seconds, or minutes, instead of hours, to complete. Enjoy... :-)

(You can experience an exemplary talking questionnaire after downloading the self installing archive with eSF-36 wave files from my WWW site. They are referenced by the available eSF-36 questionnaire definition files, and after their installation, when a new question appears, or when you hold the mouse over a text item, it will be read aloud.)


Context menus

Most programs for Windows offer a menu bar from which the user can select several options or commands to perform different tasks. Commands in this menu bar may be related to anything else in the program, and usually related commands or options are grouped together. Common examples are the "File"-menu to save, load or print a file or the "Edit"-menu to cut, copy or paste text or graphics.

A "context menu", however, is a menu which is associated with an object. Context menus bear their name, because the menu that actually appears when you press the secondary button, depends on the context in which your pointer is at that moment - mainly on the object you're pointing at.

Generally, every context menu will provide options to modify the object to which it belongs. For example, the context menu of the background will allow you to change the background colour, or to add or delete objects. The context menu of a question will allow you to change the colour and font of the question or its wording.

In AnyQuest for Windows, context menus are available in the edit layout mode only.

To activate the context menu of an object, point at that object and then press the secondary button of your pointing device.

Note: To access the context menu of an individual object (or the background), you do not have to select this object first. Context menus of selections may not include all options of the context menus of the individual objects which are included in a selection.

If your pointing device does not have a secondary button, you can go an alternative way to the context menus.

If you are an experienced user, you can use keyboard command sequences instead of using context menus to issue many commands more quickly, without taking your hands away from the keyboard.


Alternative way to context menus

An alternative way to context menus

If your pointing device does not have a secondary button, you usually would not be able to bring up any context menu. However, there is an alternative way to do it:

Check the option "Alternative way to context menus" in the "Edit"-menu. Then, point at the desired object and press the primary button: the desired context menu will appear.

As long as this option is checked, pressing the primary button within AnyQuest's main window will have the effect that you would expect from pressing the secondary button. Hence, its context menu will appear every time you click at an object while in the edit layout mode.

The option will remain checked until you reset it or until you exit AnyQuest for Windows. It will not reset itself automatically, because it is probable that you require a couple of context menus sequentially, and it would be annoying if you had to set that flag for every single one.


Primary button

Different pointing devices may have different numbers of buttons in different locations. Even in a given pointing device, the assignment of the hardware buttons to their logical function may often be configurable through software.

In a standard configuration, however, the button to which this documentation refers as "primary button" might be...

...the primary button of any pointing device.

...the left button of a mouse set up for a right-handed person.

...your finger tip using a touch screen.

...the button in the tip of a digitizer's or pen-computer's pen.


Secondary button

Different pointing devices may have different numbers of buttons in different locations. Even in a given pointing device, the assignment of the hardware buttons to their logical function may often be configurable through software.

In a standard configuration, however, the button to which this documentation refers as "secondary button" might be...

...the secondary button of any pointing device.

...the right button of a mouse set up for a right-handed person.

...the button at the side of a digitizer's or pen-computer'spen.


The author - a bigger picture


The author's address

Dr. med. Jörg M. Sigle

Im Vogelsang 2

D-75438 Freudenstein, Germany

Tulpenweg 9

CH-3004 Bern, Switzerland

Mobile:	+49-176-9643-5413

+41-76-276-8694

joerg.sigle@jsigle.com

joerg.sigle@gmx.net

joerg.sigle@web.de

http://www.ql-recorder.com

http://www.jsigle.com

http://www.anyquest.de

http://jsigle.cjb.net (outdated)

If you write me by mail or by e-mail, I usually do respond. However, it may take several days or up to a few weeks, depending on my workload.

You may look up my current addresses on my WWW site, and try to use an alternative one, or try to reach me on the phone.


Touch Window

TouchWindow turns any available monitor into a touch-screen. Works with your finger or with an included stylus. If you don't want to buy an expensive touch screen, this is probably one of the most economic and simplest methods to get one.


QL-Recorder

The original Quality-of-Life-Recorder

This picture shows the original Quality-of-Life-Recorder using GraTaSim and AnyQuest for MS-DOS Version 2.21. The tablet template reproduced here has been replaced by a colourful one with a more intuitive design.

The graphically designed questionnaire template is put onto an electromagnetic digitizer (or "graphic tablet"), which is essentially the same device which is built into a pen-computer.

The original Quality-of-Life-Recorder runs on any at least 80286 based PC under MS-DOS 3.31 or above. It already had many of AnyQuest for Windows' advantages: E.g., it is freely programmable and thus can support most quality of life questionnaires, and it uses the same standardized data storage format.

In clinical studies, it was demonstrated that routine quality of life measurement with compliance of >98% and a questionnaire completeness of >99.9% is feasible using this instrument.

AnyQuest for Windows and GraTaSim for Windows have limited downward compatibility to the Quality-of-Life-Recorder for MS-DOS®.


Pen-computers

There are a variety of pen-computers available. The following ones are shown here, because they have a colour display:

Fujitsu Stylistic 1000

EPSON EHT 400 C

Palmax PD-1000

Nowadays (in the year 2003), the Fujitsu Stylistic 1000, or its sucessor Fujitsu Stylistic 1200, can be acquired e.g. on www.ebay.com or www.ebay.de for a few hundred Euros or Dollars, just as the other devices mentioned above.

The Stylistic series has been improved a lot (faster processors, better displays), and is still available from Fujitsu-Siemens e.g. via www.fujitsups.com. Other suitable devices are some models from the Lifebook series from Fujitsu-Siemens or the Panasonic Toughbook, a variety of new TabletPCs including models from HP, Toshiba and many others have been released last year. Some devices still offer high quality electromagnetic digitizers, nowadays with improved handwriting recognition through Microsoft Windows XP Tablet PC Edition.

Please review the appropriate WWW sites for further information - just ask www.google.com or www.google.de to provide further information; some links to partners and providers of suitable hardware are also available on my own site.


Fujitsu Stylistic 1000

486DX4/100MHz, 8MB RAM, Dual scan colour display, Electromagnetic digitizer, PCMCIA, Windows 95.

The 1998 successor Stylistic 1200 has a Pentium CPU, TFT-display and integrated soundcard. Further models are available from Fujitsu with prices between DM 5.000,- and 8.000,-.


Epson EHT 400 C

486DX2/50MHz, 4MB RAM, Dual scan colour display, Pressure sensitive digitizer, PCMCIA.


Palmax PD-1000

Cyrix Pentium Class CPU, 120/133 MHz, 16MB RAM, 6.1" TFT display with 640x480 Pixels and 256K colours, Touch-Screen digitizer, 1.6 GB HDU, PCMCIA, Windows 95/98/NT 4.0.

Currently, this system costs about DM 2.000,- .. DM 3.000,- in Germany. A faster successor is on its way. I have already run Linux 2.0.35 on this machine, but I haven't had the time to install and configure it for permanent use.

As an arrangement with the German importer of this system, we can offer it at a special price together with an AnyQuest for Windows registration and pre-installed AnyQuest for Windows software.


On-line help document history

AnyQuest for Windows on-line help

Some tables in this helpfile might look best in a maximized window.

© 1996..2011 by Jörg M. Sigle

Registered trademarks might be used in this document without special indication.

The source file for this on-line help document is:

j:\anyquin\anyquin.rtf

wapu5l:/home/jsigle/lifeqal/anyquin/anypak/anyquin/anyquin.rtf

The on-line help source file was written by Jörg M. Sigle.

The source file is converted to an MS Windows on-line help file anyquin.hlp using Microsoft's help compiler hc31.exe. Several batch files hc*.bat (adopted for parts of the build environment accessible via different drive letters) in the AnyQuest build directory can call the help compiler automatically after calling the pre-processor \sctools\asci4rtf.exe by Jörg M. Sigle which replaces special characters by suitable escape codes. Without such pre-processing, the help compiler returns an error if the source file contains e.g. any unescaped German "Umlaut". Should the help compiler report an error and its offset in the source file, the program \sctools\find_err.exe by Jörg M. Sigle can help to locate the corresponding place in the source file. Should the help compiler report an error located at the end of the source file, there is a high probability that a closing parenthesis "}" for a block is missing somewhere in the source file.

On-line help document history

This is the history of the on-line help only. For the product history of the QL-Recorder software AnyQuest for Windows, please look here.

Version 3.39 01.10.2012 - Added: Information about AnyQuest Version 3.77 improvements in the product history.

Version 3.39 01.10.2012 - Added: Information about AnyQuest Version 3.76 improvements, plus information about the newly available HL7 interface, in the product history.

Version 3.38 30.09.2012 - Added: Information about AnyQuest Version 3.75 improvements in the product history, plus one note on the newly available HL7 interface.

Version 3.37 26.04.2012 - Added: Information about AnyQuest Version 3.72 to 3.74 improvements in the product history and in the sections on the "AnyQuest Navigation" window.

Version 3.36 14.12.2011 - Added: Information about AnyQuest Version 3.67 to 3.71 improvements in the product history and in the sections on Analysis tools, selection, review and printout generation for previous results etc., and printer setup.

Version 3.35 27.08.2011 - Added: Information about AnyQuest Version 3.61 to 3.66 improvements in the product history and in the sections on configuration files, "Remove Menu & START ASKING QUESTIONS", printer setup, detailed description of the *.anq result file format, and communication with external software.

Improved: Spelling changes and minor other changes throughout the file.

Version 3.34 28.05.2011 - Added: Information about AnyQuest Version 3.58 to 3.60 improvements in the product history and in the section Calling external applications.

Added: Hyperlinks from the most recent entries in the AnyQuest product history and the AnyQuest on-line help history to affected sections in the on-line help.

Corrected: The paragraph regarding the calling of external applications had too many index entries for the Microsoft Help compiler; so it wouldn't be correctly indexed or accessible from the index at all.

Version 3.33 11.03.2011 - Added: Information about AnyQuest Version 3.55 to 3.57 improvements in the product history.

Version 3.32 24.11.2010 - Added: Information about AnyQuest Version 3.53 and 3.54 improvements in the product history and in sections Printer Setup... and Navigation window.

Version 3.31 23.10.2010 - Added: Information about AnyQuest Version 3.52 improvements in the product history and in sections Questionnaire descriptors and Options in the *.ini file to harden a configuration, and in certain references to the graphical progress indicator bar.

Version 3.30 23.10.2010 - Added: Information about AnyQuest Version 3.51 improvements in the product history.

Version 3.29 02.07.2010 - Added: Information about AnyQuest Version 3.50 improvements in the product history.

Version 3.28 13.03.2010 - Added: Information about AnyQuest Version 3.49 improvements in the product history.

Version 3.27 09.03.2010 - Added: Information about AnyQuest Version 3.48 improvements in the product history and in section "Fast-Input-Form".

Version 3.26 03.03.2010 - Added: Information about AnyQuest Version 3.47 improvements in the product history and in section "Printer Setup".

Version 3.25 03.03.2010 - Added: Information about AnyQuest Version 3.46 improvements in the product history.

Version 3.24 15.02.2010 - Added: Information about AnyQuest Version 3.45 improvements in the product history. Improvements in section "Collecting patient identification data", regarding fast index based PID recognition and its preliminary unavailability on Windows XP, Windows 2000 or newer systems.

Version 3.23 13.02.2010 - Added: Information about AnyQuest Version 3.44 improvements in the product history. Improvements in section "Multiple configurations", regarding the recommended organization of configuration files in subdirectory trees below c:\anyquin. Correction of some single backslashes in the help file source code, which caused filenames and directory paths to be only partially displayed, into double backslashes.

Version 3.22 12.02.2010 - Added: Information about AnyQuest Version 3.43 improvements in the product history and in section "Printer Setup".

Version 3.21 11.02.2010 - Added: Information about AnyQuest Version 3.41 and 3.42 improvements in the product history; added postal address in Switzerland.

Version 3.20 05.01.2010 - Added: Information about AnyQuest Version 3.40 improvements in the product history. Additions to the printer setup and printout configuration related documentation.

Version 3.19 06.12.2009 - Added: Information about AnyQuest Version 3.39 improvements in the product history. Corrected: A few minute glitches in the layout of the product history.

Version 3.18 27.11.2009 - Added: Information about AnyQuest Version 3.38 improvements in the product history.

Version 3.17 08.10.2009 - Improved: "Quick guide to making your own questionnaire go electronic" revised, adopted to current version 3.37 of AnyQuest for Windows, and extended by several more detailed explanations of certain steps.

Version 3.16 25.09.2009 - Added: Support for buttons to flip forwards >> and backwards << throught most topics listed in the main table of contents (technically, the sequence is determined by MainToc:xxx footnotes).

Added: Information about corrections in AnyQuest version 3.37, specifically support for "Threshold" in addition to "treshold" in the UPN formula language and corrected processing of negative relative jump destinations in CBFs.

Added: Information about "size" related keyboard shortcut commands.

Updated: Explanation of formula consistency check vs. FN UPN reference with regard to warning message upon deletion of result formulas.

Improved: Table of contents and various topics received extended reviews, improvements, clarifications, additions.

Version 3.15 24.09.2009 - Improved: Table of contents and various topics received extended reviews, improvements, clarifications, additions.

Version 3.14 23.09.2009 - Added: Information about AnyQuest Version 3.35 and 3.36 improvements in the product history.

Added: information about the newly added functionality, especially with regard to PC speaker keyboard shortcut feedback control, enhanced automatic answer field position aids, versatile text search and replace functionality, and enhanced functionality to adding/insert and re-sorting result formulas from the respective dialogs.

Added: information in sections on conditional branching and #UPN inline formulas.

Improved: Table of contents and various topics received reviews, improvements, clarifications, additions.

Version 3.13 12.07.2009 - Added: Information about AnyQuest Version 3.34 improvements in the product history.

Version 3.12 11.06.2009 - Added: Information about AnyQuest Version 3.32 and 3.33 improvements in the product history.

Version 3.11 13.05.2009 - Added: Information about AnyQuest Version 3.31 improvements in the product history.

Version 3.10 06.05.2009 - Added: Information about AnyQuest Version 3.28, 3.29 and 3.30 improvements in the product history. Documentation of new enabled short questionnaire name group in Fast-Input-Form documentation. Cosmetical changes (regarding Fast-Input-Form dashes and capitalization, as well as usage of bot words key and Legende instead of legend) throughout the help file.

Version 3.09 07.10.2008 - Added: Updated contact information: outdated fax removed, mobile phone numbers added.

Version 3.08 01.09.2008 - Added: Information about AnyQuest Version 3.27 improvements in the product history. Some cosmetical changes in the on-line help file history.

Version 3.07 23.08.2008 - Added: Information about *.pdq, *.pds, *.pdc, *.rvs, *.rvc, *.rrs, *.rrc printout definition and reference definition files.

Version 3.06 07.08.2008 - Several layout improvements, corrections of typos, and minor text revisions. Especially, changed a lot of italics into plain formatting, because that's just better looking and easier to read on a typical 1024x768 LCD. Italics at this resolution are probably ok on CRT, which smooths out the lines, but look really jagged on the LCD. ... Ahem. Plain font looks boring, but ok, at least clear.

Version 3.05 07.08.2008 - Added: Information about AnyQuest Version 3.24, 3.25, 3.26 improvements in the product history, the Fast-Input-Form- and collection of patient-ID related documentation.

Version 3.04 14.07.2008 - Added: Information about AnyQuest Version 3.23 improvements in the product history and in the configurable title screen section. Some additional formatting.

Version 3.03 29.06.2008 - Added: Comments on development status of index based patient recognition. Information about AnyQuest Version 3.21 and 3.22 improvements in the product history.

Version 3.02 29.06.2008 - Added: Comments on the on-line help source and processing tools added to the header of the on-line help file history.

Version 3.01 29.06.2008 - Improved: On-line help file history and product history both resorted so that newest entries appear at the top of the list now. Reformatting of both histories using consistent schemes.

Version 3.00 08.04.2008 - Added: Information about AnyQuest Version 3.18 and 3.19 improvements in the product history section. Information about changed and added UPN processing functions in the UPN related sections.

Version 2.99 02.04.2008 - Added: Information about AnyQuest Version 3.17 improvements in the product history section. Information about added DoT/DoB field format functionality in the Fast-Input-Form.

Version 2.98 31.03.2008 - Reviewed/Updated: license information, registration form, addresses of the author. Added: Information about known limitations of the newly added Fast-Input-Form mode and about a possible colour problem in the PID frame printout in version 3.16.

Version 2.97 28.03.2008 - Added: Information about AnyQuest Version 3.16 improvements in the product history section. Information about Fast-Input-Form mode.

Version 2.96 15.01.2008 - Added: Information about AnyQuest Version 3.15 improvements in the product history section.

Version 2.95 04.12.2007 - Added: Information about AnyQuest Version 3.15 improvements. Additions to printer selection, redirection etc.

Version 2.94 03.12.2007 - Corrected: Leftover extra reference to AnyQuest version removed from "n m SETC" UPN implementation documentation.

Version 2.93 29.11.2007 - Added: Information about AnyQuest Version 3.13 improvements. Updated info on securing or hardening a configuration.

Version 2.92 20.11.2007 - Added: Information about AnyQuest Version 3.12 improvements. Updated course-over-time plot documentation, added a reference to GhostScript/FreePDF setup instructions in eSIRO documentation available on WWW site. Removed outdated references to http://jsigle.cjb.net. Removal of erroneous html code in external applications listing in "The Quality-of-Life-Recorder team".

Version 2.91 14.11.2007 - Added: Information about AnyQuest Version 3.11 improvements. Separated product and document history.

Version 2.90 27.09.2007 - Updated pricing and VAT infos.

Version 2.89 22.03.2007 - Added: Information about AnyQuest Version 3.10 improvements.

Version 2.88 10.03.2007 - Added: Information about AnyQuest Version 3.09 improvements. Corrected: Information about UPN commands GETCURQN, GETCURQNR, GETLDQN, GETLDQNR (two parameters were erroneously specified before although not further explained, while naturally, neither of these functions parameter requires any parameter), and RECALCNUMRES (erroneously listed as RECALCQN before).

Version 2.87 14.02.2007 - Added: Information about AnyQuest Version 3.08.2 improvements.

Version 2.86 29.01.2007 - Added: Information about AnyQuest Version 3.08 improvements.

Version 2.85 26.10.2006 - Added: Information about AnyQuest Version 3.07 improvements.

Version 2.84 29.08.2006 - Added: Information about AnyQuest Version 3.06 improvements.

Version 2.83 27.08.2006 - Added: Information about AnyQuest Version 3.05 improvements.

Version 2.82 27.08.2006 - Added: Information about AnyQuest Version 3.04 improvements.

Version 2.81 20.08.2006 - Added: Information about AnyQuest Versions 3.01, 3.02, 3.03 improvements.

Version 2.80 06.08.2006 - Added: Information about dme2a.pas, a result file processor prototype available upon request in open source code to transfer DMP Diabetes related information from *.anq files into very simple ANSI/ASCII plain text files. Information about reference applications for card reader interfaces and other GDT / LDT / xDT interfaces. Information about producing archives of *.PS and *.PDF printout files using GhostScript and FreePDF or PDFCreator, and linking to these virtual printout from electronic patient files.

Version 2.79 06.08.2006 - Added: Information about AnyQuest Version 3.00 improvements, information about data export possibilities enhanced.

Version 2.78 30.07.2006 - Added: Information about AnyQuest Version 2.98, 2.99 improvements.

Version 2.77 03.03.2006 - Added: Information about AnyQuest Version 2.89, 2.90, 2.91, 2.92, 2.93, 2.94, 2.95, 2.96, 2.97 improvements.

Version 2.76 04.12.2005 - Added: Information about AnyQuest Version 2.88 improvements.

Version 2.75 10.11.2005 - Added: Information about AnyQuest Version 2.82, 2.83, 2.84, 2.85, 2.86, 2.87 improvements. Outdated contact details at the University in Göttingen and mobile phone removed.

Version 2.74 18.02.2005 - Added: Information about AnyQuest Version 2.81 improvements.

Version 2.73 31.08.2004 - Added: Information about AnyQuest Version 2.80 improvements.

Version 2.72 10.08.2004 - Added: Information about AnyQuest Version 2.79 improvements.

Version 2.71 10.08.2004 - Added: Information about AnyQuest Version 2.78 improvements.

Version 2.70 09.08.2004 - Added: Information about AnyQuest Version 2.77 improvements.

Version 2.69 04.08.2004 - Added: Information about AnyQuest Version 2.74, 2.75 and 2.76 improvements.

Version 2.68 24.04.2004 - Added: Information about AnyQuest Version 2.72 and 2.73 improvements; sections about the new editing grid functionality.

Version 2.67 14.02.2004 - Added: Information about AnyQuest Version 2.70 and 2.71 improvements.

Version 2.66 16.12.2003 - Added: Information about AnyQuest Version 2.69 improvements.

Version 2.65 04.12.2003 - Improved: Information about multiple configurations and *.ini files. Corrected minor formatting problem (indent of all but the first lines in a paragraph) after the "What kind of objects are there? / Is there anything else?" section.

Version 2.64 04.12.2003 - Added: Information about AnyQuest Version 2.68 improvements.

Version 2.63 28.10.2003 - Added: Information about AnyQuest Version 2.67 improvements. Inclusion of "<>" in logical functions list, which was available but not missing in the documentation. Additional information regarding "not". Added information about new features in patient identification data collection. In the UPN implementation documentation, supported the Windows Help tabulating functionality, which apparently tabulated to an early tab stop after the shortest UPN commands, by supplying a few more hard coded spaces after these. Some additional slight formatting improvements in the TOPIDxxx and FRPIDxxx explanations.

Version 2.62 06.10.2003 - Added: Information about AnyQuest Version 2.65 and 2.66 improvements. Printer setup information enhanced.

Version 2.61 16.07.2003 - Added: Information about AnyQuest Version 2.63 and 2.64 improvements, including enhanced printer setup documentation.

Version 2.60 17.04.2003 - Improved/Added: Acessibility of info about how to change semi-static object fonts from *.ini file and *.msg file, namely the continue-button, and about the continue-button itself. Slightly enhanced documentation of available objects and Questio-Morph-o-Matic. Improved index.

Version 2.59 16.06.2003 - Added: Information about AnyQuest Version 2.62 improvements, typo corrected in UPN command Yn explanation.

Version 2.58 14.04.2003 - Added: Information about AnyQuest Version 2.61 improvements, update of result formula definition info.

Version 2.57 25.03.2003 - Added: Information about AnyQuest Version 2.60 improvements, update of PID collection info, update of suitable hardware info.

Version 2.56 20.03.2003 - Added: Information about AnyQuest Version 2.59 improvements, update of addresses and little improvement of the index.

Version 2.55 14.12.2002 - Added: Information about AnyQuest Version 2.57 and 2.58 improvements.

Version 2.54 07.07.2002 - Added: Information about AnyQuest Version 2.57 improvements. Enhancements in UPN documentation. Correction: The UPN command EXCHG was erroneously documented as EXCH.

Version 2.53 25.06.2002 - Added: Information about AnyQuest Version 2.55 - 2.56 improvements.

Version 2.52 27.04.2002 - Added: Information about AnyQuest Version 2.52 - 2.54 improvements. Updates of documentation for Patient ID collection and for keyboard commands. Some other minor updates.

Version 2.51 17.03.2002 - Added: Information about AnyQuest Version 2.51 improvements.

Version 2.50 03.01.2002 - Added: Information about AnyQuest Version 2.50 improvements.

Version 2.49 16.09.2001 - Added: Information about AnyQuest Version 2.49 improvements. Updates of documentation of UPN implementation, info about morphing questionnaires.

Version 2.48 08.09.2001 - Added: Information about AnyQuest Version 2.48 improvements. Updates of several affected sections. Several minor improvements throughout the help file.

Version 2.47 25.06.2001 - Added: Information about AnyQuest Version 2.46 and 2.47 improvements. Large enhancement of the page about Jörg's Magic Questionnaire-o-Matic. Several minor improvements throughout the help file.

Version 2.46 25.06.2001 - Corrected: Documentation of initialization file parameter for communication with external software with regard to external collection, checking or postprocessing of patient ID: Wrongfully, external_check_after_PID_collected=demoapp.exe and external_check_after_PID_collected_wait=True were given, but correctly, these parameters are check_after_PID_collected=demoapp.exe and check_after_PID_collected_wait=True (without the leading "external_"). Improved: More documentation for the UPNDebugMode. Added and improved: Information about AnyQuest Version 2.45 improvements, including new features to disable buttons in the "AnyQuest Navigation" window and to prepare secure configurations.

Version 2.45 26.03.2001 - Added: Information about AnyQuest Version 2.44 improvements.

Version 2.44 08.03.2001 - Added: Information about AnyQuest Version 2.43 improvements. Added new command to documentation of implemented UPN command set. Updated and extended pricing information in license agreement and registration form.

Version 2.43 18.02.2001 - Added: Information about AnyQuest Version 2.42 improvements. Added new commands to documentation of implemented UPN command set.

Version 2.42 24.01.2001 - Added: Information about the file prototyp.qdw.

Version 2.41 12.01.2001 - Added: Information about AnyQuest Version 2.40 in the product history. Copyrights updated to 2001.

Version 2.40 15.12.2000 - Added: Information about AnyQuest Version 2.40 in the product history.

Version 2.39 17.10.2000 - Added: Information about AnyQuest Version 2.39 in the product history (extended again). Updated: Section regarding Linux/Wine use; documentation of "T" and "F" UPN commands.

Version 2.38 15.10.2000 - Added: Information about AnyQuest Version 2.39 in the product history (extended again).

Version 2.37 beta 09.10.2000 - Completed: AnyQuest Version 2.39 product history.

Version 2.36 beta 16.08.2000 - Corrected: Explanation of some of the new keyboard commands. Improved: Re-ordering and extension of list of advanced features in the table of contents. Miscellaneous other small improvements and corrections.

Version 2.35 beta 30.07.2000 - Added: Explanation of new keyboard commands.

Version 2.34 beta 20.07.2000 - Added: Explanation of *.qdt file related commands in the file menu, explanation of how to use prototype and anchor questions.

Version 2.34 beta 30.06.2000 - Added: Explanation of "Clear all other fields on check" in answer field options. Explanation of UPN commands X, Y, T, F, MIN, MAX. Explanation of advanced result formula options to control printout. Some additional revision and extension of the description of the UPN implementation.

Version 2.33 beta 18.05.2000 - Updated: My phone and fax numbers.

Version 2.32 beta, 30.03.2000 - Recent changes and improvements added, "Data folder selection" extended, "PC speaker sound extended", new WWW- and e-mail adresses added.

Version 2.31a beta, 03.01.2000 - A version of the on-line-help-file generated specifically for the general anypak as provided on the WWW.

Version 2.31 beta, 03.01.2000 - A version of the on-line-help-file generated specifically for the preliminary study of an electronic EORTC QLQ application.

Version 2.30 beta, 02.11.1999 - Added: Quick guide for questionnaire users. Added, changed, enhanced: License agreement, data protection, printing, statistics, sections about general use and a variety of other topics as required by the eIBSQOL application.

Version 2.29 beta, 11.10.1999 - Changed: Table of contents. Added: Documentation and history for AnyQuest for Windows version 2.32. Language and version documentation. Keyboard support. Info on export table size limit. Info on preparing international environments and anyquin.msg file.

Version 2.28 beta, 31.08.1999 - Improved: Quick and dirty guide to making your questionnaires electronic: occasional missing small instructions inserted, spelling errors corrected, demo questionnaire bargraph max setting instructions corrected.

Version 2.27 beta, 20.08.1999 - Added: History for AnyQuest for Windows version 2.31. Information about margins in printout options dialog. Known errors: limited support for printers with different x/y-resolutions.

Version 2.26 beta, 11.08.1999 - Added: History for AnyQuest for Windows version 2.29, 2.30. Improved: Quick and dirty guide to making your questionnaires electronic: occasional missing "click OK"s inserted. Detailed output file format description: Additional index entries added. Missing space after colon in description of additional text input section added. Minor layout improvements.

Version 2.25 beta, 18.06.1999 - Added: History for AnyQuest for Windows version 2.28. Added: Detailed *.anq file format information. Suggestions to write import routines for third party software. Direct text input fields. Updated and added various topics throughout the help file. Improved formatting.

Version 2.24 beta, 01.06.1999 - Added: History for AnyQuest for Windows version 2.26, 2.27. Added UPN formulas. Information about limitations of sizes of processed items appended to UPN implementation info. Some updates and enhancements in various other sections.

Version 2.23 beta, 22.05.1999 - Added: History for AnyQuest for Windows version 2.26. Removed: Note concerning missing cumulative printout function in "Known errors and limitations" · .

Version 2.22 beta, 15.04.1999 - Added: Undo and crash recovery. Quick and dirty tutorial: how to make your questionnaires go electronic. Updated: History.

Version 2.21 beta, 16.03.1999 - Updated: Translation utilities. History.

Version 2.20 beta, 15.03.1999 - Added: Measurement of the duration to complete a questionnaire. AnyQuery for Windows. Updated: History.

Version 2.19 beta, 02.05.1998 - Added: Images. Improved: Command line parameters.

Version 2.18 beta, 06.04.1998 - Added: Command line parameters.

Version 2.17 beta, 31.03.1998 - Updated: Question Options, Addresses of author.

Version 2.16 beta, 03.10.1997 - Added: Translation utilities.

Version 2.15 beta, 06.08.1997 - Addresses of author updated.

Version 2.14 beta, 16.12.1996 - Added: Conditional branch support. Questionnaire definition file copyright and history documentation.

Version 2.12 beta, 29.11.1996 - Corrected: Adding objects/New answer field positions, spelling errors. Added: Formula consistency check, Help window size definition. Changed: Table of contents, Registration form, License agreement, Important information, Formula definition, Single printout printer setup, Literature reference, Original QOL-Recorder. Pre-Release => Evaluation package.

Version 2.11 beta, 29.11.1996 - Until now: about 420 visits to both my WWW homepage and from there to the QL-Recorder page.

Version 2.1 beta, 10.10.1996 - How to update/re-distribute included. How to install updated. (Self extracting package now provided on FTP/WWW for the first time.)

Version 2.0 beta, 02.10.1996 - More hierarchic table of contents in help-file.

Version 1.9 beta, 25.09.1996 - Inclusion of pictures in help-file. (First version available in WWW)

Version 1.8 beta, 17.09.1996

Version 1.7 beta, 13.09.1996

Version 1.6 beta, 09.09.1996

Version 1.5 beta, 27.07.1996

Version 1.3 beta, 22.07.1996

Version 1.2 alpha, 21.07.1996

Version 1.2 alpha, 17.07.1996

Version 1.1 alpha, 15.07.1996

Version 1.0 alpha, 12.07.1996


AnyQuest for Windows product history

This is the history of the AnyQuest for Windows software product. For the history of the on-line help file itself, please look here.

Please note: 	Beta versions do not necessarily have the capability to read questionnaire definition file formats of earlier alpha or beta versions (but read history note for version 2.20!). If you have questionnaire definition files generated with an earlier alpha or beta version, which you need to use in the future, please contact me.

Many revisions documented below have been available only internally during ongoing development; some only within project specific software packages. A list of actually published versions is available at http://www.ql-recorder.com

anq2hl7.pl Version 0.01 19.09.2012 - 25.09.2012

Added: 	A new perl script provides the ability to convert *.anq result files from questionnaire administrations into HL7 version 2.x files that can be imported by third party software which can handle examination results or laboratory test results. The HL7 message file can be automatically generated after each questionnaire administration, or the converter can be called to process multiple existing *.anq result files later on. It works for files generated by AnyQuest for DOS, AnyQuest for Windows, and AnyQuest for Java - running locally or providing an on-line-questionnaire in the context of a WWW site. In either case, the results can be imported by HL7 capable practice management software or hospital information systems. In addition to multiple SQL interfaces available since about 1999, and the bidirectional GDT/LDT interface available since 2001, this provides one more pathway along a major standard in Healthcare IT, for data collected with the Quality-of-Life-Recorder to travel into software applications used by clinical end users, quality management, or outcomes research.

Version 3.77 01.10.2012

Corrected: 	Disabled remaining active debug output in aqdialo2.pas during checking of direct text input field content.

Version 3.76 18.06.2012 - 21.06.2012

Added: 	Ability to remember the cascaded multilevel configuration file *.ini for each configured parameter and to write back any changes only to the last file that effectively defined the respective parameter. Thereby, interactively made changes to configurations can be written back into cascaded multilevel configuration structures just as easily as they could be written back to simple configuration files before. Specifically, this allows for the provision of configurations to conveniently change printer (or other) settings interactively, while still storing these configurations in one printout.ini file, and only in that file for a complete setup of configurations. All this without any requirement to manually prepare or maintain any meta-information about the location of these settings.

Please note: 	The ability mentioned above is limited to parameters with a value that does not exceed 255 characters. Paremeters with longer values are currently not handled by aqwrap and therefore not kept in the respective buffer.

Corrected: 	Detailed handling of backup variables for unscaled printout font sizes in the processing of *.ini files, as another prerequisite for the intelligent cascaded multilevel configuration file write back functionality.

Improved: 	Several recently added hi-color icons were removed from anyquin.res because they were automatically selected, but not correctly displayed, under WinNT on palmax and Windows 2000 on blackbox.

Improved: 	Update of the InnoSetup script for the AnyPak 2 package version 0.02 and preliminary distribution of the new setup including: AnyQuest for Windows 3.76, the new anypak subdirectory tree, the jssplash menu with newly prepared configurations based upon cascaded multilevel *.ini files, and the new InnoSetup installer.

Version 3.75 04.05.2012 - 14.05.2012

Added: 	The local flag  f_pdx_suppress_psf in *.pd? can be used to suppress the printing of the patient sticker frame for a individual printout types and individual questionnaires. This would typicall be used for a patient satisfaction questionnaire to be collected anonymously, whereas other quality-of-life related questionnaires at the same site would carry a clear or pseundonymized patient ID.

Improved: 	The message that appears on printouts generated without a license key has been changed from "Unlicensed evaluation version. Not for regular use." to "Unlicensed evaluation version. Please register to receive a personalised license. Free licenses available upon request." The settings of control variables in aqlicfil.pas have been corrected to actually use all of this new wording - the second part had been prepared before but not yet displayed.

Improved: 	Changed the default internal program name from "SC-JMS Lebensqualitäts-Recorder" to aqglobal.prognamedefault="SC-JMS AnyQuest for Windows". The result would appear on printouts. The original content is however still present in *.msg files (at least for en and de translations).

Added: 	Moving the PID data into the patient sticker frame was previously possible only via *.pd? configuration files. Now, a new flag [Printout] global_f_move_pid_into_psf=false is available in the *.ini configuration files. By using cascaded multilevel *.ini files, one flag can centrally control the option for multiple questionnaires and configurations. The flag is only honoured if a patient sticker frame is produced at all.

Added: 	The follwoing options have previously only been available via *.pd? configuration files. Now, the new flags [Printout] dypidshift=0 and [Printout] dydoashift=0 are available in the *.ini configuration files. By using cascaded multilevel *.ini files, one flag can centrally control the option for multiple questionnaires and configurations. These settings get into effect if the corresponding settings from the *.pd? file are 0.

Added: 	The parameters global_f_simple_date_of_assessment=false from and global_f_suppress_duration_of_assessment from *.ini configuration files do complement their previously available counterparts from *.pd? files. If the first one is true, it will use pdsxsimpledate and pdqxsimpledate (for single and questionnaire-filled-in-printouts, respectively) whose default values are both Datum, if not specified otherwise in a *.pd? file. The second one will continue to use the normal label for the point in time of questionnaire administration, but only the date will be shown, whereas the output detailing from HH:MM:SS to HH:MM:SS etc. will be suppressed. This allows for a very comfortable switch to a simplified output format, that will especially not overlap the patient sticker frame.

Cleanup: 	Resorted several parameters in the code reading or writing *.ini configuration files. Removed one double line from the writing code.

Added: 	The *.ini configuration file parameter global_f_autogen_custom_header_backup=False|True controls the automatic generation of fallback semi-custom hearders: If the normal header bars are disabled, and no custom header is effectively defined (i.e. *.pd? pd?numofheaderentries=0), the program can create a custom header with three lines: One empty line, one automatically underlined line stating "Measurement using (questionnaire name)", and another empty line. While the content is similar to the normal automatically generated header, the presentation is like the custom header, maintaining an clear and more open layout of the printout, without surrounding boxes, much more suitable for header logos etc.

Added: 	An overline/underline functionality for definition of custom header lines in *.pd? printout definition files: Any line containing - or = is automatically expanded to a single or double underline for the preceding or succeding one. Text length and left/center/right positioning are automatically taken into account.

Added: 	I just wanted the printed output to look good, even if the user wouldn't have acquired any license (not even a free one). So the new *.ini configuration file parameter PrintSuppressLicenseInfoEvenForEvalVersion=False|True can suppress the license information even for unlicensed evaluation versions of the software (it would have been shown in the title area of the printout before). Any suppressed license information is now always shown in a small grey letters along the right border of the printout. This has been used throughout the new AnyPak 2 package.

Corrected: 	On a multi-monitor setup, if the AnyQuest main window would be displayed on the right or lower monitor, and the mouse pointer would be moved to the left or upwards of that window, a RTE 201 at 0001:9167 (or similar) was thrown because one function involved would not handle the resulting negative mouse pointer coordinates. This was fixed, and an identical problem causing RTE 201 at 0001:9483 (or similar) as well.

Improved: 	Error output from aqwrap is removed (this had been used to  support the recent development of aqwrap), when debugging output is disabled, because otherwise a WinCRT window would appear under completely normal circumstances, e.g. when a *.pd? file would not be found.

Please note: 	The aqwrap buffering which significantly speeds up the processing of configuration files applies to *.ini files and *.pd? files alike. This means that changes in either type of configuration file made while an instance of AnyQuest for Windows is running are not immediately honoured. This had been different for *.pd? files before the introduction of the aqwrap buffering.

Improved: 	Update of the fast input form: Removed the generation of the two lines "to" and "answer" below "can not" and "don't want". They were ok for the HELPS questionnaires which caused two extra lines at the beginning of the automatically generated content, but they would overlap the first answer fields for other questionnaire definition files.

Improved: 	Removed the icon in the lincensebox as the new icon would not look good in this place. The dialog is already too crammed to sport the large new sketch of a tablet PC.

Improved: 	Variables controlling the display of the license-box and the about-box dialog windows during the start of the program were controlled by the presence of a license file before. Now they can be controlled from the *.ini configuration file, and the dialogs are disabled by default: [Special purpose] ini_suppress_show_license_dialog=False and [Special purpose] ini_suppress_about_dialog=False. Currently, the introductory notice on the shareware policy cannot be displayed through the menus either, but the startup is faster, uninterrupted, and the should probably be more appealing to users of the evaluation version.

Improved: 	Computation of line width for answer field frames, linear analog scales, and checkmarks.

Added: 	The *.ini configuration file parameter [Special purpose] draw_soft=False|True causes answer field frames, linear analog scales and checkmarks to be drawn with soft borders (using a 50:50 mixture with background color). The implementation of this feature has been individually tuned to pen widths of 2, 3 or 4 pixels for various screen resolutions.

Added: 	Short questionnaire names starting with gcs are now also allowed for the fast input form operation mode.

Corrected: 	Processing of an empty value for the *.ini configuration file parameter [Printout] JobName_Header. Before, it would use the default string AQ- in this case. Now, an empty string works and this allows for virtual printout (PDF, XPS) filenames including a full timestamp, corresponding *.anq filename, printout type, initials, and a 10-digit RFID code for the patient ID.

Corrected: 	The previously planned removal of all special characters from *.anq result file names had left the ! exclamation mark in use. This would however be ignored in MS Windows print job names, and therefore break the link between *.anq result file names and *.pdf, *.ps, *.xps etc. virtual printout filenames. If an exclamation mark occurred for a measurement result file, users could not open the corresponding virtual printout files with graphical results through AnyQuests built in dialogs. Now, the exclamation mark has been removed from *.anq result file names and only digits 0..9 and characters A..Z will be used.

Corrected: 	Usage of the applicable result file name as one portion of a virtual result printout file to be opened through the built in dialogs for selection and review of questionnaire administration results.

Improved: 	The automatically generated print job name, determining the filename of virtual result printout files *.pdf, *.ps, *.xps etc., has been set by default to follow the pattern: yyyymmddTYPanqfilenVNrfidnumber. (date, printout type, *.anq result filename, initials, patient ID number - allowing for up to 10 digits typically found on preprogrammed RFID tokens). All dashes between the elements are now disabled. This allows for automatic bidirectional linkage between result file and virtual printout filenames, suitable for AnyQuest's built in dialogs to review previous test administration results, and for manual searching in folders containing virtual printout files alike. All elements are configurable, and the case ID field could be used instead of the patient ID field. The current pattern completely uses the MS Windows limit for the size of printjob names of 31 characters. Two more characters can be freed by an option reducing the TYP element to one character (from QFI, SNG, CUM, LAY, STA to Q, S, C, L, S). If other information is additionally required, the timestamp could also be disabled as this information is also contained (even to greater detail) in the referenced *.anq result file.

Corrected: 	When preprogrammed RFID cards were used to enter the patient ID, which contained the characters 0123456789abcdef, a PID entered in the PID dialog and recognized was converted to uppercase letters during PID recognition. So the first written *.anq result file for a patient would contain lowercase letters, and result files for follow up measurements would contain uppercase letters. All other methods of PID acquisition would return the entered PID without conversion to uppercase. The undesired conversion was identified as a side effect from PID recognition and removed.

Improved: 	On a WeTab using Windows 7, the Open QFI, Open SNG and Open CUM buttons to display *.pdf virtual printouts with graphical results would occasionally work, but most often they would fail. On nova using Windows XP, and on arogaus-PC using Vista, they would invariably work. The problem occured because a batch file temporarily generated to call the external document was removed after use, and this occured too early for the lower processing speed of the WeTab. The respective waiting time was increased from 100ms to 500ms, whereafter the buttons reliably worked on the WeTab as well.

Corrected: 	AnyQuest for Windows would not let certain printer definition details from multilevel printout.ini files supersede those read from other ones read before that would not actually contain that information - and thereafter use a resolution of 3600 dpi. This could cause incomplete usage of the available A4 page area in certain situations, as well as GPFs during the debugging of the problem.

Version 3.74 13.04.2012 - 21.04.2012

Improved: 	Quality assurance found printouts after the first one created by a given instance of AnyQuest to be missing in PDFCreator under Windows 7 (32-Bit) for configurations prepared for the HELPS project. Handling of printing device contexts was slightly refined to work with this version of Windows as well.

Cleanup: 	Removal of unwanted WinCRT output after the completion of the current major development phase.

Corrected: 	The relatively new handler that could show questionnaire 1, question 1 behind the minimal navigation window as required for the HELPS project, could cause an error when no questionnaire was loaded due to a prematurely ending Boolean evaluation.

Added: 	Support for definition of detailed font settings from secondary multilevel *.ini configuration files instead of the primary configuration file only.

Corrected: 	The num variant of the newly added custom PID collection dialogs could produce what appeared as small display artifacts, but actually was unwanted creation of buttons close to the frame of the dialog.

Corrected: 	The newly added buffered reading of *.ini configuration files would leave an excessive number of files open and thereby affect other file related functionality of the system.

Added: 	The character set related information is also written to the *.anq result file for the new custom font definition, and a priority scheme ensuring that the written setting matches the font actually used for the dialogs is obeyed.

Corrected: 	The character set related information written to the *.anq result file could have excess characters.

Improved: 	The descriptive statistics output lines will automatically be spaced further apart for dimensions with long labels. Therefore, a simple (non-exact!) estimator function has been implemented to foretell the number of lines required for a given label.

Improved: 	The descriptive statistics table available from built in analysis tools will produce some minimum number of decimal digits for certain parameters independently of the cumulative printout precision set by the user for a given questionnaire. This ensures that decimals will be produced for means (and other parameters) even when the user wanted 0 decimals on the normal single or cumulative printouts (which may be perfectly reasonable).

Corrected: 	Repainting the CustomThankYouBox after using the fast input form could throw a run time error. [N.B.: Future versions may default to the standard thank you box (including a dialog box) no matter what is specified in the configuration file, whose appearance suits the fast input form mode much better.]

Improved: 	Minor changes in aqprcum course over time printout printed information.

Improved: 	Internal handling of date format validation and automatic correction.

Added: 	Support for additional date formats. The ordering (DDMMYYYY or YYYYMMDD) is now independent of the separation character. The separation character has been "." or "-" before, and is (relatively) now freely configurable. Date formats can still be independently defined for dialogs and generated printouts. The internally used date format is dd.mm.yyyy and this is also written to *.anq result files (can be changed on the fly when extract is used to generate data export tables). The new corresponding *.ini configuration file parameters are DateFormatSepCharDialog=46 and DateFormatSepCharPrint=46 (specifying a character in the range 32..255; in addition to the previously available: DateFormatDialog=0|1 and DateFormatPrint=0|1).

Improved: 	Changed aqdraw: draw_antworten to use less stack space.

Improved: 	Positioning of the optional "-" and "-" transport buttons and the status lines above the graphical progress indicator will now be adopted to screen resolution and font size. Warning: The positioning will use a constant vertical size of the transport button window; so currently it will NOT support font scaling as built into Windows 7 and activated for some screen sizes (N.B.: The window decorations will not look as good as normal either when larger font sizes are activated.) Also changed the ordering of the items in the status display, so that question number and questionnaire number are located most closely to the graphical progress indicator or transport buttons.

Improved: 	Added some reasonable automatic layout generation for the "Start", "..." and "Exit" buttons of the minimal navigation dialog that will produce nicely looking results for screen resolutions between 640x480 and 1440x900 based upon the user configured font sizes. The new algorithm will use the golden section for some elements.

Improved: 	Added some reasonable automatic layout generation for the CustomThankYouBox - the previous functionality would end up with the OK button on the text lines for displays with 640x480 resolution. The new algorithm will use the golden section for some elements.

Tested: 	Improved rendering of bitmaps within the questionnaire definition file (applying 2D floating point interpolation). Found however that using the default mechanism supplied by the Windows API with higher resolution source bitmaps (even with reduced color depth and run length encoding) would improve rendering quality more efficiently.

Improved: 	Scaling of user configured fonts is done by the square root of vertical screen size rather than linearly. (Also tested ^1/4; but wouldn't keep that.) Fonts for the PID collection screens will not be scaled because the dialog elements themselves also keep a constant size. The dialog window will however be scaled to extend to the right and to the bottom of the available space after centering, so that the introductory text line will not necessarily be cut off any more, even if the screen size would suffice.

Added: 	Scaling of user configured fonts; the new corresponding *.ini configuration file parameter is [Scaling] fonts_lfHeight_reference_aqwinheight; other applicable parameters from the same section do also work.

Added: 	Support of the "Enter" key for the newly added custom PID collection dialogs and other dialogs with manually drawn default push buttons.

Added: 	Manually implemented default push button functionality for certain buttons with wm_drawitem/bs_OwnerDraw in various dialogs.

Corrected: 	The fast input form "OK" button would lose its new custom font setting after any message box would have been displayed (when the program would try to set its default push button property again, thereby removing the bs_OwnerDraw style).

Improved: 	Greyed rendering of disabled buttons with wm_drawitem/bs_OwnerDraw.

Added: 	Functionality for the new navigation dialog buttons to heed configuration file settings disabling certain functionality.

Added: 	Functionality for the new navigation dialog buttons to directly go into questionnaire definition file layout editing mode, or into one of the analysis tools dialogs.

Changed: 	Changed the default values for the *.ini configuration file parameters TitleSuppressRainbow=False and TitleSuppressBitmap=False. This only affects the appearance of the program when it is started without any configuration file specified that contains the respective settings.

Version 3.73 13.04.2012

Improved: 	Reviewed the rendering of answer fields, text elements, and gray space showing text element size in aqdraw, and fine tuned it so that the lower right corner will also lie on the editing grid. Also fine tuned the positioning of crosses and pencils signaling additional text input stored with an answer field, so that they appear exactly centered (they had been off by 1 Pixel in x-direction). Generation of the questionnaire definition file testv373.qdw with test cases for layout rendering on nova with 1440x900 pixels, Windows XP Pro, "Classic" appearance.

Version 3.72 17.03.2012 - 12.04.2012

Improved: 	Revised the appearance and functionality of the navigation dialog (now with longer button labels and additional buttons leading directly to certain functions), the appearance of other dialogs (removal of window title and improved layout, including message boxes, PID confirmation dialogs, about dialog, password dialog), program icons, and other graphic elements.

Improved: 	Brought wm_drawitem/bs_OwnerDraw handlers from various dialogs together into aqdraw: ownerdraw().

Improved: 	Slightly enlarged the input fields for date, PID etc., as well as the buttons in the fast input form dialog. Repositioning of the buttons. Greyed label supported for the bs_OwnerDraw Help button font in the fast input form.

Added: 	Support for configurable fonts and character sets in the fast input form dialog.

Added: 	Debug output from various locations moved to a separate aqdebug unit and enhanced so that configurable, timed monitoring of events with screen or file output becomes available. Debugging (which starts earlier in the program startup course) can also be turned on with a command line parameter: anyquin -d outfile.txt. (Alternatively recognized switch formats: /DEBUG, --DEBUG, -DEBUG, /debug, --debug, /Debug, --Debug, -d)

Added: 	Buffered reading of *.ini configuration file settings in the aqwrap unit changes start times on the same multilevel configuration file sets on the WePad to: 0:00.4 / 0:00.8 min:sec; and on the PD-1000 to 0:04 / 0:08 sec. The buffered variant returns config file entries of up to 254 characters; as the Win 9x (and Win XP, but not Win NT) variant of the function, it replaces the first of any trailing spaces in a passed default string (as in a read value) by #0. In contrast to the original Windows function, my buffered version will remove embracing single or double quotation marks around a passed default string, however, which the Windows function would only do for a read value - leaving no way to pass defaults with trailing spaces...

Reviewed: 	Startup time with multilevel configuration file sets including 10 files per set: WeTab: after 0:05 min:sec, the program window appears, after 0:10, the questionnaire definition file has been loaded and the "Start" and "Exit" buttons are available. Palmax PD-1000 (30/100 MHz 486..586 level CPU) with doze mode: 1:26 and 3:17; without doze mode: 0:42, 1:23.

Reviewed: 	Date format checking vs. requirements in several countries.

Added: 	Support for custom fonts and character sets in the printouts.

Added: 	Support for configurable dialog button text, via the following *.msg message file parameters: confirmok=Ja, confirmreject=Nein, confirmabort=Abbrechen, labelauto=Auto, labelstart=Start, labelexit=Exit, labelok=OK, labelcancel=Cancel, labelsave=Save, labelabort=Abort, labelhelp=Help. So all dialogs that patients (or probands) may encounter during a questionnaire administration session can be fully configured (and translated) by now.

Added: 	The configurable font (and character set) of the "Continue" button is now also used for the "Start" and "Exit" buttons of the minimal navigation dialog.

Improved: 	Layout for the num variant of the PID collection screens in the Greek, Custom and Standard versions: The text input field now starts at y=17, the same position as in the alpha and alphanum variants; and the text input field has become broader so it can contain the text 99-99-9999 in a slightly broader font without scrolling.

Improved: 	Automatic change of the content of the button "." to "-" if the configured date format is YYMMDDDD or if the instruction text contains "." at an earlier position (which includes: 0 for not at all) than "-".

Corrected: 	Greek font handling detail in aqservic.pas.

Corrected: 	In the ressource definition files for some customized versions of AnyQuest for Windows, the dialog template NUMINPUTGREEK was missing. In some of these files, the headline for the Greek alpha and alphanum variants was still constant text rather than a placeholder that would have been empty by default, and completely configurable. Even though these files have not been used for Greek configurations so far, they were updated for the sake of code quality and -consistency.

Added: 	The buttons of the newly added custom PID collection screens in the alpha and alphanum variants can be completely user defined (rows, columns, available characters, font and character set, spacing). Special functions are concatenation of neighbouring buttons with identical characters (e.g. to generate a space bar or double width buttons), empty fields in the defined grid, and positioning of the previously added "Auto" button which generates a random PID that has not been used on the same system before. The corresponding new *.ini configuration file entries are: [Fonts] Custom_PID_collection_and_Printouts=False|True (overrides ...Greek...), PID_screens_Custom_alpha_rows=5, PID_screens_Custom_alpha_cols=16, PID_screens_Custom_alpha_spacingx=12, PID_screens_Custom_alpha_spacingy=12, PID_screens_Custom_alpha_buttonschars=stringCodePointsSequenceMayInclude#nnnEscapes, the same set for ...alphanum..., font_for_PID_screens_Custom.lfCharSet=0 (e.g.: Western=0, Greek=161, Turkish=162, Baltic=186, Cyrillic=204, CentralEuropean=238 etc.), font_for_PID_screens_Custom.lfHeight=0, font_for_PID_screens_Custom....=... (other variables to constitute a complete font description).

Added: 	Revised layout for the PID confirmation dialogs, the message window, and the custom thank you box (including both text and buttons).

Added: 	New *.ini configuration file entries: font_for_PID_Screens_Custom..., font_for_message_window_message, font_for_message_window_button, font_for_texteingabe_window_message, font_for_texteingabe_window_editarea, font_for_PID_Screens_CustomThankYouBox_Text, font_for_PID_Screens_CustomThankYouBox_Button to configure the fonts used for various dialogs presenting messages or asking for confirmations, the CustomThankYouBox (without dialog window), and for newly added custom PID collection dialogs.

Corrected: 	In the *.ini configuration files, the parameter Greek_PID_collection_and_Printouts was read from section [Fonts], but written back to section [Options]. As the parameter could not be changed interactively, that would primarily mislead configuration file designers. It might also have affected sessions that were interrupted and saved for later resumption when they used a special character set (assumed, but not tested). Now, the parameter is written to the section [Fonts].

Version 3.71 14.12.2011

Corrected: 	Version 3.70 would internally still use the 3.69 version label, and also write that onto result printouts and into result files etc.

Improved:  	The Properties - Version - File version field of the executable program file was changed from "1.0 - PrnJobTitle w/o CFG w PID" back to "1.0" as the printjob names have finally become configurable. The tag had been added after version 3.08 (back in 2007); details are given on the printer setup page.

Version 3.70 27.10.2011 - 28.10.2011

Added: 	While other tasks within AnyQuest for Windows use interrupt and callback based system timers, a homemade delay loop was also in use. Its main use was from PC speaker sound effects, e.g. the audible feedback signal when an answer has been selected, or when the thank you box is shown. This homemade delay loop had been an improvement over the original Turbo Pascal function years ago. That had become unusable at some time in the age of 386, 486 and Pentium processors with ever increasing speeds (or due to early TSR programming requirements). But when multitasking became more common, and processors started to vary their clock frequencies for power saving purpose, the homemade delay was also affected: The initial calibration during program startup became time consuming, as available processing speed would vary even during calibration. Even worse, calibration results would not hold throughout the runtime of the program, and the sound effects could appear faster or slower than expected.

Now, alternative system timer tick (i.e. hardware counter) based delay functions have been added. They have removed any slowdown from calibration during program startup as well as the gross variation in PC speaker sound signals on modern systems. They can also call the yield function to reduce system load while waiting.

Configuration options have also been added to control which implementation of delay loops is used, shown here with their default settings:

[Delay]

usetickcount=True

yieldfromwaitloop=True

Version 3.69 10.10.2011 - 12.10.2011

Added: 	Internal documentation of new features.

Improved: 	Further details regarded newly added printjob name configurability and functionality to open previously generated result printout PDF documents.

Version 3.68 08.10.2011 - 09.10.2011

Added: 	Configuration options to determine the elements that are included in the printjob name for automatically generated result printouts. The newly supported parameters and their default settings are (changes from immediately following updates included in this list):

[Printout]

JobName_Header=AQ-

JobName_DoT=True 	(date of test)

JobName_DoTPostDash=True 	(a dash after the date of test)

JobName_StartTime=True

JobName_PrnType=True 	(printout type: QFI, SNG, CUM)

JobName_PrnTypeShort=False 	(switches printout type identifier to Q,S,C)

JobName_ANQfilename=False

JobName_MainINIfilename=False

JobName_Initials=True

JobName_PID=True

JobName_PIDaddZerosUpToNChars=4

JobName_CaseID=False

JobName_CaseIDaddZerosUpToNChars=0

JobName_DoB=False

JobName_City=False

JobName_RemoveAllDashes=False

JobName_UseOriginalTimestampOnRecreate=True 	(Placeholder, not yet implemented.)

Version 3.67 01.10.2011 - 06.10.2011

Added: 	Two additional, simplified, versions of the Analysis tools dialog. The "Analysis tools" menu has been extended and the nomenclature of options improved to offer the following entries: "Select and review results, generate printouts and file lists...", "By predefined filters on certain joined fields...", "By predefined filters on certain individual fields...", "By freely defineable filters on any fields...". Specifically, this makes it more easy to select measurement results for a patient given their patient ID, name or date of birth etc.

Added: 	Additional buttons in the Analysis tools dialog, to conveniently open previously automatically generated result printouts for selected measurements. The mechanism should use the default PDF viewer available on the current system through the start command (thereby it may not work for Windows 3.x based systems).

Corrected: 	A GPF at 0006:3BC1 in aqsevipr.pas could be triggered when trying to produce a deferred single printout for a result file created with a certain questionnaire definition file. The problem resulted from an inconsistency between these two files inferred during development and should not occur in normal use of the software, but I added code to catch it anyway. A corresponding GPF at 0006:3BFC was triggered thereafter by the same mechanism; and it was handled the same way.

Improved: 	Dialogs derive a useful default value for the printout directory from the printoutdir configuration file setting.

Improved: 	Added a background shade in the "Course over time plot - options" dialog to match all other dialogs.

Improved: 	Review of the "Select result files..." dialogs: Improvement of the layout, additional columns, new buttons for printout directory and to open previously generated result printouts as PDF documents.

Added: 	An initial framework to locate PDF documents belonging to a given *.anq result file for opening, even after varying printjob name schemas have been used to generate them.

Improved: 	Hardened the PDF document opening mechanism against side effects of competing file accesses between AnyQuest and the operating system; and protecting the routine against multiple concurrent calls. Requests to open multiple files are now processed reliably one after another.

Improved: 	Empty strings are not added any more to the SeViPr/-Simple1/-Simple2 drop down lists. Technically, this is a cosmetic improvement at the cost of some minor reduction in available functionality. But practically it should prevent confusion of less knowledgeable users, especially as multiple empty entries could be added to any list and this might have looked like a malfunction.

Improved: 	"Pr qfi" buttons disabled on all the SeViPr/-Simple1/-Simple2 dialogs, because loading back raw data individual quesiton results has not been implemented yet. Revision of the button IDs used in these dialogs and in the Statistics dialog.

Version 3.66 01.08.2011 - 02.08.2011

Added: 	Support for basic ANSI single byte to UTF8 multibyte character, and UTF8 multibyte to ANSI single byte transcoding for writing and reading of the temporary *.pid data exchange file. This file is employed to provide an internally collected (or empty) patient ID data set to external software, and to read back a checked, or completed, or completely externally provided version of that data set. Transcoding between UTF8 and ANSI characters was added specifically for communication with the Microsoft .net based meQ/TSS software prototypes developed in co-operation with Stefan Heckel Medizintechnik, Esslingen. Newly supported configuration file parameters are [External applications] check_after_PID_collected_out_tx_ANSI_to_UTF8=False|True and check_after_PID_collected_in_tx_UTF8_to_ANSI=False|True. More detailed information is available in section communication with external software of this on-line help file.

Version 3.65 29.07.2011 - 01.08.2011

Improved: 	Revision of a label for a (currently obsolete) menu entry, without any actual effects, just for improved legibility of code.

Corrected: 	Cumulative printout would appear empty since version 3.64 (unpublished development version). This was one (of a few) side effects from the fact that three lines of code that would write the timestamp into the *.anq result file had been removed when the code for improved timestamps in printjob names had been added. These lines were restored.

Version 3.64 22.07.2011

Improved: 	Previously, all printjob names carried a timestamp showing when each printjob was issued. Now, names of printjobs which are generated automatically at the end of a questionnaire administration session, will carry a timestamp showing when the questionnaire administration session started instead. The same time is recorded in the *.anq result file. In effect, the timestamps of all three printjob names of automatically created QFI, SNG and CUM printouts (if enabled) become identical, deterministic, and completely predictable from the content of the *.anq result file. Currently, the scheme for printjob names is: AQ-YYYYMMDDhhmmss-TYP-FL-NNNNN, with YYYYMMDD derived from the field date of test and hhmmss from the field start time,   TYP either QFI or SNG or CUM, and FL=initials from the fields first name and last name, and NNNNN=first five digits from the field group/PID. PDFs, for example, produced by PDFCreator with the AutoSave option and <title> as template for the filename will have this filename plus the extension .PDF. (Please note: In the future, the scheme may become configurable, e.g. to remove the leading AQ- in favour of two additional digits for NNNNNNN, or to suppress or use other variables.) Additional details are provided in the sections on configuration files and printer setup of this on-line help file.

Corrected: 	Directly specifying a printer in *.ini would cause a GPF at 0014:3C94 in an internal development stage between 3.63 and 3.64. Review of the additional globalunlock() statement temporarily added in version 3.62 in the printer device context initialization in aqini.pas. Identification and correction of a missing test for driver<>nil in aqini.pas responsible for the GPF.

Version 3.63 20.07.2011 - 21.07.2011

Added: 	Ability to remove the window title bar (i.e. use a fullscreen window) during questionnaire administration. Available by setting the newly supported parameter [Options] MainWindowStylePopupInsteadOfOverlapped=True. Details are provided in the sections on configuration files and "Remove Menu & START ASKING QUESTIONS" of this on-line help file.

Improved: 	Added ws_thickframe to ws_popup in the AnyQuest main Window options, which will remove the black line between the menu and the client area when AnyQuest appears with enabled navigation screen, but disabled title bar, and also during the questionnaire administration mode when [Options] f_DisableMainWindowSysmenu or f_DisableMainWindowMinimizeBox are used.

Version 3.62 08.07.2011 - 19.07.2011

Added: 	Completed multilevel *.ini configuration file support. A given configuration file can now reference other configuration files which will be processed before or after itself. Thereby, it is now possible to deploy a scheme of cascaded configuration files, that provide certain aspects of machine-local, user-specific or site-global settings, also across various questionnaire setups, language-versions, or projects, in separate, named files, which can be distributed across networked or local media. For example, a single file config\common\printout.ini may include all settings that control the printout features, including which types of printouts are produced (and copied) on virtual PDF or real printers etc., and this file can be referenced by all other configuration files on the systems. So changing printer settings, can be accomplished centrally by editing just one file. Or if one printout.ini file is placed onto each local machine in a network, each machine can automatically be instructed to use the network printer located most conveniently to it - etc. As before, both referenced and referencing configuration files only need to contain the settings which they want to change from their default (or from previously determined) settings. To this end, AnyQuest automatically uses adequate discretion in filling in - or not filling in - default values for parameters not explicitly specified in a given configuration file. This behaviour can, however, also be overridden so that a configuration file processed later in the cascade would re-install default values anywhere if desired. [...] Newly supported parameters are [MultilevelConfig], OnlyReadParametersAlreadyInTheFile=True|False, ConfigFileBeforeCurrent1=..., .. ConfigFileBeforeCurrent9=..., ConfigFileAfterCurrent1=..., .. ConfigFileAfterCurrent9=.... Details are provided in the section on configuration files of this on-line help file.

Added: 	New *.ini configuration file parameters can activate the production of some debug output at runtime. Newly supported parameters are [Debug], inifile_rw_filename=True, qdw_rw_filename=True, ini_fontinfo=True, ini_prndevnames=True, ini_thisprn_try=True. All debug output initially available through this function is related to configuration file processing. By default, the debug output currently appears in a window which is positioned on a second monitor located in the upper left of the primary monitor. Details are provided in the section on configuration files of this on-line help file.

Temporarily added: 	One additional globalunlock() statement in the printer device context initialization in aqini.pas. Further review and testing scheduled (carried out towards version 3.64).

Version 3.61 26.06.2011

Enhanced: 	In the built in patient ID collection dialogs: extension of the available field size for "please enter the patient ID code", especially required by the Spanish translation used in the HELPS project.

Enhanced: 	In the patient ID confirmation dialogs (small, small Greek, and large versions): addition of a second line of text for the question asking for confirmation, as required for English, Spanish and Dutch versions of the question in the HELPS project.

Version 3.60 08.05.2011

Improved: 	The General Editing Tools - Text search and replace functionality can now operate across multiple concurrently loaded questionnaire definitions; this can be controlled via an additional option in the dialog box.

Corrected: 	The General Editing Tools - Text search and replace is now properly supported by the undo functionality.

Corrected: 	The General Editing Tools - Text search and replace will now properly set the "modified" flag - and thus, the colour of any affected questionnaire(s) in the graphic progress indicator.

Version 3.59 22.04.2011 - 24.04.2011

Added: 	All HELPS questionnaires were approved for Fast-Input-Form mode. All configurations prepared for the HELPS project are available in two variants; one for patients filling in the questionnaires directly at the computer; and one for trained staff collecting data from paper forms.

Improved: 	The checks whether a given questionnaire definition file has been approved for Fast-Input-Form mode were consolidated and moved into a single new function aqdlgfrm.check_whether_fif_allowed_for_qnr_shortname().

Improved: 	Leading linebreaks were removed from being displayed as leading spaces in Fast-Input-Form mode for the generic transformation function, but not for the eSIRO specific one.

Improved: 	The Fast-Input-Form mode form does now automatically adjust its size to the available screen size.

Improved: 	As a consequence of the new policy of defining special answer fields first ("Can't answer/Don't want to answer"), the automatic allocation of number and character key bindings and navigation using the cursor keys in the Fast-Input-Form would not work as intuitively expected. The algorithms were changed so that an intuitively expected operation is achieved, no matter whether special answer fields are defined first or last (or wherever) within a question.

Added: 	Support of automatic recognition of the system decimal separator character. Addition of an option "auto" to the data export dialogs, which is now the default option.

Version 3.58 11.04.2011

Improved: 	When printouts were generated while multiple questionnaires were loaded, and custom reference values, reference ranges, or reference labels were specified via reference definition files *.rvs, *.rrs, *.rvc, *.rrc, the a formula number specified the CND:RFN statement would be handled as an absolute number (i.e. counting from the first formula of the first loaded questionnaire through to the last formula of the last loaded questionnaire). This was (of course) counterintuitive, and it would also require a change in reference file content depending upon whether a questionnaire was used on its own, or in a configuration loaded together with (and behind) others. The behaviour of the program was changed; so that the local formula number within any given questionnaire can now be used in CND:RFN references.

Improved: 	Since version 3.52, with [Options] DirectExit=True, AnyQuest exits after a questionnaire administration session has been completed. In combination with DirectStart=True, this can be used to integrate AnyQuest seamlessly into a menu system or into another external software environment. Before version 3.58, the Navigation Window screen would appear for a moment between the last question and the closing of the AnyQuest main window.

Added: 	New parameters for the calling of external applications:
[external applications]
notify_after_anq_completely_written_showcmd=0..9
check_after_PID_collected_showcmd=0..9
provide_access_to_data_directory_showcmd=0..9
These can be used to control whether the window of an external application appears e.g. visible or hidden, normal or maximized. The meanings of the individual numeric values are:
sw_Hide=0
sw_ShowNormal=1
sw_ShowMinimized=2
sw_ShowMaximized=3
sw_ShowNoActivate=4
sw_Show=5
sw_Minimize=6
sw_ShowMinNoActive=7
sw_ShowNA=8
sw_Restore=9
The default value is 1. Some values may affect the functionality of the corresponding parameter external_..._wait=True because the respective function monitors the existence of the window opened for the called application.

Version 3.57 29.01.2011 - 31.01.2011

Corrected: 	When printouts were generated while multiple questionnaires were loaded, and custom reference values, reference ranges, or reference labels were specified via reference definition files *.rvs, *.rrs, *.rvc, *.rrc, the a formula number specified the CND:RFN statement would be handled as an absolute number (i.e. counting from the first formula of the first loaded questionnaire through to the last formula of the last loaded questionnaire). This was (of course) counterintuitive, and it would also require a change in reference file content depending upon whether a questionnaire was used on its own, or in a configuration loaded together with (and behind) others. The behaviour of the program was changed; so that the local formula number within any given questionnaire can now be used in CND:RFN references.

Added: 	A parameter [Scaling] suppress_unscaled_area_indicator_frame=True|False. If this is True, the option suppress_scaling_during_load=True can be used, and still no indicator frame will be drawn to identify the unscaled extent of the original questionnaire definition file (please refer to entries regarding versions 3.49 ff. for a discussion of previously added scaling related parameters). This is especially useful, if display sizes for questionnaire definition file editing and questionnaire administration are just slightly different (e.g. Windows XP system and -appearance with slightly taller Window Title decoration vs. Windows 2000 system or -appearance). Normally, AnyQuest for Windows would use minor scaling to accomodate for the different client area size on the playback system - but this might affect e.g. the appearance of bitmap graphics (especially logos with diagonal lines), or the aspect ration of square answer fields in the questionnaire screens. If you want to completely suppress any scaling in such a situation, you can now set both parameters to True and use the questionnaire content in a completely unscaled way, and without any visible indicator rectangle. Thus, the original answer field geometry and bitmap graphics should be maintained pixel by pixel.

Version 3.56 18.01.2011 - 20.01.2011

Corrected: 	In some German message file(s) (e.g. de.msg), the string "Diese Fragen wird nun nochmals gezeigt." was corrected to read "Diese Frage wird nun nochmals gezeigt." - The default version of this string compiled into the program, reading "Diese Frage wird gleich wiederholt." had been correct before, so the program itself needed neither change nor recompilation here.

Corrected: 	a GPF at 000A:0B8C could occur due to an unexpected value of aktuelle_frage when the program was started without *.ini file, and "Setup" was then selected from the Navigation Dialog, as another side effect of the newly added ShowQnr1Qn1AsTitleScreen=True option. A check was added as well to handle the condition correctly.

Updated: 	The year 2011 was added to the "About" dialog etc.

Version 3.55 11.01.2011

Corrected: 	A GPF at 0004:1aae could occur when the program was started with the new option ShowQnr1Qn1AsTitleScreen=True and NumberOfLoadedQNs=0 in the *.ini configuration file, which could result in an unexpected value of aktuelle_frage. Checks were added in three positions in the repaint code to handle the condition correctly.

Updated: 	The copyright notice written to *.anq result files was updated to include 2011.

Version 3.54 24.10.2010

Improved: 	If the newly introduced option to use questionnaire 1 question 1 as title screen was used, with a skip CBF as described below, and with the regular navigation window, and with the option DisablePlayInSetupMode active, then the "Setup" button would be rendered ineffective: Technically correct, the automatic skipping from (title screen replacing) question 1 to question 2 would cause DisablePlayInSetupMode to engage and bring the user directly back to the navigation window. This would leave the user unable to make any changes to the setup interactively, without prior editing of the configuration file - therefore, DisablePlayInSetupMode was changed to be automatically supressed when the program changes from showing the navigation window to showing the first question (and processing its CBFs, and skipping forward if thereby required, as long as required, until the first pass through govorwaerts has been completed).

Corrected: 	Version 3.53 showed some debug messages related to the govorwaerts process (it was only released to a small number of users during project specific development).

Version 3.53 08.11.2010

Improved: 	If a configuration with directstart=true was loaded with no loadable qdws (e.g. because those listed in the *.ini file could not be found), then the program would still not return to the navigation dialog, but stall with a clean white window content.

Corrected: 	The code to branch for processing of idm_cokaestchen was there twice (causing no malfunction but affecting clarity of code at least).

Corrected: 	The context menu entry for explanation 2 colour would affect explanation 1, leaving only the colour option in the font dialog and thus a limited selection of colours for this object.

Corrected: 	The colour of special answer field labels was not re-read from *.qdw files but copied from the regular answer field label colour in the portion of code that would ensure backward compatibility with old *.qdw file formats.

Added: 	Ability to copy the colours of explanation and explanation 2 to all loaded questionnaires similar to what was added for answer fields and check marks in version 3.52.

Improved: 	Refined the changes to the menu made in version 3.52 regarding colour changing and copying entries; including the internally used codes for various related menu options.

Added: 	Ability to produce a label for "dates and times of assessments" in the cumulative printout, through a *.pdc parameter like: pdcxdatestimesofassessments=Messzeitpunkte: (default: empty/no label, same behaviour as before).

Added: 	Ability to suppress the times of measurement (the time of day when the questionnaire administration began) in the cumulative printout, through the *.pdc parameter: f_simple_date_of_assessment=True.

Added: 	Support for CustomThankYouBox (can be controlled from the respective parameter added to the *.ini file) internally driven similarly to the AboutBox dialog window, but with white background, no frame, two lines of 18pt Arial text corresponding to caption and message of previously available ThankYouBo, and an OK button in the same font size.

Added: 	Support for *.pds file parameters section#bargraphwidth=i and section3minspacesbetweenlabelandxbargraphleft=i  which can be used to change the bargraphwidth per section, and successively the position where printed results are left aligned to. See section "Printer setup..." in the on-line help or exemplary *.pds configuration files for details.

Added: 	Support for a button "Auto" on the PID collection dialog. If this is clicked, AnyQuest for Windows automatically generates a PID that has not been used before in the data files it can currently see. The button is controlled by the option ShowAutogenPatientIDButton in the *.ini file. Currently, a 6 digit numerical PID is generated. Internally, options have been provided to specify the number of digits, charset and prefixes to be used, but these have not been linked with any *.ini file or menu options so far.  The button may not be available in all custom versions of the AnyQuest for Windows program, because it must be provided in the respective ressource file definitions.

Added: 	Ability to use questionnaire 1 question 1 as title screen behind the navigation window. This is controlled by the option ShowQnr1Qn1AsTitleScreen in the *.ini file.

Added: 	Ability to display a custom navigation dialog, including only a "Start" button, or "Start" and "Exit" buttons, plus a "..." button for "Resume" only displayed when required, on a white background without a frame at the bottom of the screen. These variant behaviours are controlled by the options NaviMinimal=True, NaviMinimalAtBottomOfScreen=True, NaviMinimalShowExit=True|False in the *.ini file.

Improved: 	Conditional branching formulas for skipping were not evaluated on the first loaded question before version 3.53. They are now. Typically, a first question of a questionnaire to be used as a title screen, would be generated as an infoscreen with a conditional branching formula with "condition = 1" and "action = skip". Consequently, as soon as the user presses "Start" or "Go", the title screen would disappear, the PID collection dialogs (or a link to external software for the same purpose) would appear, if configured, and afterwards, AnyQuest would skip directly to question 2 of that questionnaire defintion. That might typically be another infoscreen, providing the actual questionnaire introduction.

Version 3.52 23.10.2010

Improved: 	The color entry of the answer field context menu was replaced by a submenu with multiple entries, to change the colour of the answer field outline, the mark, or to perform the new operations mentioned below.

Added: 	Ability to copy the colour of answer field outlines (or LASA/VAS scale lines, respectively) and marks from the current questionnaire to all preceding or succeding currently loaded ones.

Added: 	A set of buttons in the questionnaire descriptors dialog with the ability to apply changes without closing the dialog, and to copy the language and version entries from the preceding or the succeding, or to all, to all preceding or to all succeding currently loaded questionnaires.

Changed: 	Separation of internally used button id 4012 and into 4011, 4012 and 6101 - to keep separate variable names with separate values.

Added: 	A new option in the File menu: Save all modified questionnaires to *.qdw files. This menu option is only available in the editing-enabled menu. It is itself enabled only when modified questionnaires are in memory, otherwise, it appears in gray. It can be used to simplify the handling of multiple questionnaire definitions in projects where these are required.

Changed: 	The new menu option File - Save all modified questionnaires to *.qdw files receives the m as accelerator key for "modified". To allow for swift operation, the accelerator key for Memory report is changed to r for "report".

Added: 	The graphical progress indicator bar can display the representation of each loaded questionnaire either in black (as before) or in red, when a questionnaire has the modified flag (i.e. veraendert; i.e. edited but not yet saved) set. To achieve an up to date display, the contents of the main window are invalidated and a repaint operation is scheduled when the flag is changed for any questionnaire, as long as the graphical progress indicator bar display is activated.

Improved: 	Save-for-undo and handling of the modified flag was insufficient or did not exist for copy-text-to-all... or copy-position-to-all... operations. Now both should work fine. Using these functions, and chosing undo with 55 questionnaires in undo storage may now be a nice little spectacle with the graphical progress indicator now being update after each questionnaire is loaded.

Corrected: 	After an undo operation that restores a whole set of loaded questionnaires, the name of the current questionnaire is now put back to the AnyQuest main window caption. In previous versions, the name of the last of the restored questionnaire definition files would have persisted (at least briefly) in the caption, which could be confusing, disturbing or misleading for the user.

Added: 	The colours to be used for the graphical progress indicator bar can be configured from the *.ini file by changing the following parameters in the [Options] section: GraphicalProgressIndR=0, GraphicalProgressIndG=0, GraphicalProgressIndB=0, GraphicalProgressIndModifiedR=255, GraphicalProgressIndModifiedG=0, GraphicalProgressIndModifiedB=0.

Added: 	An Exit button was added to the minimal navigation dialog in order to make AnyQuest for Windows exit-able even when this dialog is used. By default, however, it is invisible and inactive. This can be changed via the *.ini file by setting the following parameters in the [Options] section: NaviMinimal=True, NaviMinimalShowExit=True.

Added: 	An option to directly start a questionnaire administration after the program startup, without any display of a navigation dialog, can be activated via the *.ini file by setting the following parameter in the [Options] section: DirectStart=True. This option is useful if you want to call one or multiple AnyQuest for Windows configurations from an external environment, e.g. from a menu offering questionnaires in various languages or addressing various topics. Such an environment can e.g. be implemented using the jsflash program, or the SC-JMS menu program (or many others, of course).

Added: 	An option to skip the Thank-You-Box at the end of a questionnaire administration session. With this option, the respective dialog, which would require the user to press the OK button, is simply not displayed. The associated sounds (wave file and pc speaker signal) are nevertheless produced. The option can be activated via the *.ini file by setting the following parameter in the [Options] section: SkipThankYouBox=True. This option is useful if you want to supply a Thank-You-Screen designed by yourself, as an InfoScreen within of your questionnaire definition file.

Added: 	An option to automatically exit AnyQuest for Windows after a questionnaire administration session. The option can be activated via the *.ini file by setting the following parameter in the [Options] section: DirectExit=True. This option is useful if you want to seamlessly embed AnyQuest for Windows into an external environment, from where one or multiple configurations are called, and to where the system shall immediately return after each questionnaire administration session.

Version 3.51 14.10.2010

Improved: 	Positioning of the elements of a questionnaire-filled-in-printout (qfi printout) now uses the available space more precisely and systematically. Especially, the graphs of succeeding questions don't overlap nor leave space between them (except for the intended spacer) any more. If dyspacerscaling=0, the graphs of succeeding questions (answer fields and or labels) are now placed exactly and seamlessly next to each other, for any of the possible label- and answer-field-arrangement options. Effects of changes in the *.pdq file are now more easily predictable, the positioning of the elements is simplified and the available space on each page can be used much better.

Added: 	Support for dygraphscaling and section#numofdytoaddbefore in the *.pdq file controlling the layout of the qfi printout; addition of new reference lines and other information regarding qfi printout element positioning to what is produced when "Printing" - "Show xy coordinates for printout development" is activated.

Version 3.50 02.07.2010

Corrected: 	Setting the option NaviMinimal=True would cause slightly higher scaling of questionnaire content in y-direction, and consequently, of all fonts (affecting both height and width) used to display text items of questionnaire content. This could distort answer field geometry and cause final words to be missing in text item display. The option does not only replace the original four button navigation window by a reduced version with only one large "Start" button, but also removes the menu bar from the navigation screen. The program measures the available clientrect size on that screen already, and before version 3.50, the missing menu bar resulted in a larger clientrect measurement in y-direction. In version 3.50, the measured clientrect size is reduced by the height of a menu bar plus a non-sizable window frame when NaviMinimal=True is set, so both options cause identical (correct) scaling of questionnaire content.

Added: 	In the configuration file, in section [Options], the new parameter PrintSuppressPatientDOB=True causes a collected date of birth not to appear on printouts (similarly to the previously existing parameter PrintSuppressPatientAge which prevented the computed age of the patient from being printed). The parameter can be set via the configuration file or via the General printout options menu.

Added: 	In the configuration file, in section [*.anq Output File Options], the new parameter anqfile_SuppressDOBWriteOut=True causes a collected date of birth not to appear in the *.anq result file. The new parameter anqfile_AgeOfPatientPrecision=3 controls the resolution with which the age of the patient at the date of the test is written into the *.anq result file. The default resolution is 3 decimal places, the allowable values are 0 to 3. Both parameters can be set via the configuration file or via the *.anq output file options menu.

Known limitation: 	The option anqfile_SuppressDOBWriteOut=True is currently not compatible with a configuration that collects a date of birth and recognizes a previously used patient ID when the PID is collected by the interactive PID collection screens before the date of birth and the *.anq result file causing the PID recognition, because an empty date of birth will be read from the external file and as of 3.50, this will cause an error message, but no dialog to manually enter the DOB will be shown.

Added (preliminary, under development): 	In the configuration file, in the new section [MultiLevelConfig], the new parameters ConfigFileAfterCurrent1=c:\anyquin\mystudy\config\cfgaft1.ini etc. and ConfigFileAfterBefore1=c:\anyquin\mystudy\config\cfgbef1.ini etc. cause secondary, tertiary etc. configuration files to be evaluated before or after the original configuration file. This option is a preliminary implementation - the intention is to use e.g. a single global configuration file providing some common options, for multiple configurations, that can be included from multiple specific configuration files. The intended usage is, however, currently not possible, because all possible configuration options are evaluated and default values used for each option that is not specified in a given configuration file.

Added: 	In the configuration file, the new section [Scaling] can have the following new parameters: suppress_scaling_during_loading=True - causes the loaded content of the questionnaire definition file not to be scaled to any currently seen clientarea size; show_info_scaling_during_loading=True - causes debug information to be displayed on the currently seen clientarea size, the size stored in the questionnaire definition file currently being loaded, and the applied scaling factors derived from this information. The parameters assume_aqwinwidth and assume_aqwinheight can be used to override the measured clientarea size, if either value is set to a value above 0.

Known limitation: 	The values used (and stored in questionnaire definition files) for aqwinwidth and aqwinheight are one unit above the expected clientrect size values. The measures stored in a questionnaire definition file created on a 1024x768 pixel display would be reached using assume_aqwinwidth=1025 and assume_aqwinheight=723. The actual values may vary depending upon the system metrics, which may vary with different versions of MS Windows and user adjustable settings.

Version 3.49 13.03.2010

Corrected: 	The variable numofdytoaddbefore added in version 3.43 was sometimes not initialized if not specified in a *.pds file. This could cause the program to throw a RTE 207 at FFFF:FFFF upon single printout; which was especially observed with an internally prepared questionnaire definition file when a test single printout was issued directly after program startup.

Improved: 	The code for interpretation of *.pds,  *.pdc and *.pdq printout definition files contained an early exit for the case of the filename stored in the current questionnaire definition unexpectedly not having the extension *.QDW. Whereas this would not be a user achievable condition, the code was improved to ensure initialization of related variables from their default values even then.

Corrected: 	The (recently added) dialog displaying the warning for formula position changes not being covered by formula consistency check was displayed e.g. when the user klicked on the "delete" button in the formula editing dialog and appeared before the actual deletion of the formula would be carried out. If the would issue the next formula deletion while this warning dialog was still displayed, the first formula deletion request would not be completed before the second one and this could ultimately lead to a GPF at 000D:5015 as soon as the warning dialog would finally be closed. This issue has been corrected by placing the code generating the warning dialog after the completion of the formula delete request, and in order to have the formula editing dialog update immediately after the action, the same modification was made for all other button handlers which would change the sequence of formulas and therefore be able to trigger the same dialog.

Improved: 	If a single printout or a cumulative printout was re-produced from the built in analysis-tools dialog, only basic patient id data (group/pid, name or initials, date of birth, age only for the single printout) were re-loaded from the previously made questionnaire administration result file. Now, all patient id variables should be reloaded and included in the printout if they are available in the old result file. This is especially important when reference values included in the printout are selected based upon patient age or patient sex, because they cannot be correctly selected without this information.

Version 3.48 05.03.2010

Added: 	Support for Fast-Input-Form dialog added for various additional short questionnaire names, including (e)SF-12, (e)SF12, (e)SF-36, (e)SF36, (e)HN35, e(PAN26), (e)BR23, (e)EQ5D, (e)EQ, (e)EQ2, (e)MFI20, EPW, HADS, MLHFQ, TTM, BBPatSat, OCT, eC30V3 and (e)LC13. The LC13 is not fully supported yet because of a question which has only one DirectText answer field, so its inclusion is preliminary for internal development purposes only.

Improved: 	Previously only the keys 0..9 worked in the Fast-Input-Form dialog, and would only select an answer field with exactly the corresponding integer number and no decimals. Now, the keys 0..9, A..Z, ÄÖÜß are recognized and can be used to select answer fields according to the following staged matching algorithm: (1) match with the first character of the value of an answer field; (2) match with the first character of the label of an answer field; (3) match with any character of the label of an answer field. This should be sufficient to select most answers quickly and relatively specifically by keyboard input, and therefore enter all data for scoring a paper questionnaire very fast. Where this does not suffice, the TAB and cursor keys or the mouse can still be used.

Corrected: 	The PhysicianID field in the Fast-Input-Form dialog would not accept input and could not be enabled or disabled via the "Navigation" - "Patient-ID-Options to ask for" menu, because its ID values had not been updated after the CaseID field had been inserted and positioned in its original place in the Fast-Input-Form dialog in version 3.41.

Version 3.47 03.03.2010

Added: 	Support for differently configured graphs (e.g. circle graphs for section 1 and bargraphs for section 2, or a graphs with displayed x-axis for section 3 and without) on the same result printout or in the same configuration. The parameters section#AutoSinglePrintoutCross, section#AutoSinglePrintoutCircle, section#AutoSinglePrintoutConnectingLines, section#AutoSinglePrintoutStrongHL, section#AutoSinglePrintoutDottedHL, section#AutoSinglePrintoutHL, section#AutoSinglePrintoutCoordsXAxis, section#AutoSinglePrintoutCoordsYAxis, section#AutoSinglePrintoutBar, section#AutoSinglePrintoutBarFilled, section#AutoSinglePrintoutDottedMax, section#AutoSinglePrintoutDottedTop, section#AutoSinglePrintoutValues, section#AutoSinglePrintoutYDottedValue2, section#AutoSinglePrintoutYDottedValue4, section#AutoSinglePrintoutYaxisLabel2, section#AutoSinglePrintoutYaxisLabel4, section#AutoSinglePrintoutJoinGraphsWithSameStructure, section#AutoCumulativePrintoutFixBarWidth, section#AutoCumulativePrintoutBarFilled, section#AutoCumulativePrintoutDottedMax, section#AutoCumulativePrintoutDottedRight, section#AutoCumulativePrintoutBar, section#AutoCumulativePrintoutCircle, section#AutoCumulativePrintoutConnectingLines, section#AutoCumulativePrintoutValues, section#AutoCumulativePrintoutYAxisLabel2, section#AutoCumulativePrintoutYAxisLabel4, section#AutoCumulativePrintoutYdottedvalue2, section#AutoCumulativePrintoutYDottedValue4 in the extended printout definition files *.pds and *.pdc, respectively. These parameters can be used to override the corresponding parameters of the current configuration (be they loaded from an *.ini file or be they default settings) on a per section basis.

Version 3.46 02.03.2010 - 03.03.2010

Improved: 	In AnyQuest for Windows versions 3.40 and 3.45, a GPF was observed, once per version during preparation of a project related configuration, during tests with fast navigation through questionnaires containing directtext input fields, and semi-random directtext input, at 0004:356D and 0004:3560 respectively. This is the same position in source code, inside aqstring.pcharLeerweg. A code review did not recognize erroneous code, but found that the current implementation (made for easy legibility and similarity between different functions) included repeated allocation and disallocation of minuscle memory blocks from the heap, through calls to pcharAppendfromCharacter for each character of a processed string, which might (not highly plausibly, but possibly) exhaust system ressources (due to heap fragmentation?) at least temporarily and thereby cause the problem. So all pchar and string operation functions in this unit were reviewed. All ineffectively implemented ones received an optimized implementation. Moreover, index pointers were converted from integer to word (and occasionally: longint) in order to handle pchar strings beyond 32k characters as well. Two exemplary functions were benchmarked to compare the performance of old and new implementations, and the new implementations generated speedups of 79 and 196 times (for pchar strings of substantially greater length than in typical operation, so this is probably an overestimate, but it illustrates the inefficiency of the old code). Stress tests with isolated calls to these functions using semi random data btw. failed to reproduce the exact error for both the old and the new implementation but identified the insufficiency of integer pointers and some arithmetic overflows that could occur for long pchar strings (beyond what would be expected to occur inside AnyQuest). This improvement should at the same time reduce the probability of a GPF resulting from heap overfragmentation as well as speed up all pchar text string processing, occuring in UPN formula processing, directtext field processing, patient ID recognition etc.

Improved: 	In an interim development version of AnyQuest towards 3.46, a GPF could be caused, when in aqdialog.jmsmessagedialog, the calculation of the dialog layout split supplied text into multiple lines to find out the size of the longest line: If some line would happen to have 0 characters during this process, the updated implementation of aqstring.PcharNewCopyFromPchar() would return an empty pchar string as nil instead of a pchar string containing only a terminating zero. The returned nil would then cause Borland Pascal's StrLen() to throw a GPF. The code in jmsmessagedialog was hardened as to not call StrLen() for a returned nil, and the code in PcharNewCopyFromPchar was reviewed in order to behave as the previous implementation did. (This should sometimes be checked against the requirements of strdisposejs, and possibly, StrLen() should be overloaded by StrLenjs() with protection against incoming nil pchars throughout the program, but that can be postponed).

Corrected: 	When AnyQuest receives a "close" command during a running questionnaire administration session, the session management dialog appears - and shall be centered on the screen. The computation of the window placement coordinates would fail when the "close" command was sent from the task bar representation of a minimized AnyQuest for Windows, under Windows XP (at least on a dual monitor system used to test this), because in this scenario, MS Windows returned coordinates in the -32000 range for all corners of the AnyQuest window. The computation of new window coordinates was modified to use longint math for this computation, and (although probably not strictly necessary) this approach was copied to all occurences of similar window placement computations.

Version 3.45 15.02.2010

Added: 	Support for additional parameter ObserveLeadingCharsForStatsOldResProc in section [*.anq Output File Options] of the *.ini configuration file. If set to true, AnyQuest for Windows will only evaluate result files *.anq with a filename whose leading characters match the current anqfilename_leadingchars setting. Effectively, this can be used to store data from multiple configurations that produce *.anq result files with different filenames in the same directory, so that PID recognition works across all of these configurations, while at the same time limit processessing for on-the-fly statistics and cumulative printouts to *.anq result files generated by the current configuration. The new feature works for both standard and fast index based PID recognition.

Improved: 	Tested fast index based PID recognition on Windows XP and Windows 2000, and found that the necessity to index new files is not recognized after the index has once been built on these systems, due to an incompatibility of their findfirst/findnext implementation with the original implementations. As a consequence, I added more detailed information to the warning message regarding the alpha status of fast index based PID recognition shown when the index is first built, and added code that checks the currently used version of MS Windows and inhibits fast index based PID recognition for major version numbers greater than 4 (Windows NT 3.51 and Windows NT 4 have not been tested today).

Corrected: 	In the "Analysis tools" dialog for interactive selection of previous result files, checked checkboxes and actually processed result file sections were off by -1 for "Meta info", "Raw data", "Addn text", "Num results", "Str results" and "Other", and by +7 for "Session log" (after the checkbox for "Session log" had been inserted last, and received the highest id instead of the one matching its position in the sequence of sections).

Improved: 	In the "General editing tools" - "Search and replace text" dialog, a remark was added to the label of the "Answer fields" checkbox, to remind the user that at least one of the "Text..." or "Value..." checkboxes must also be checked in order to process the respective image bitmap or wave filenames.

Corrected: 	Colours used to draw the image bitmap and wave filename in edit layout mode could be the ones left over from the previously drawn text element. Now, the colour used to draw the current text element is used; i.e. the colour of the displayed filenames matches the colour set to be used for the text element.

Version 3.44 13.02.2010

Added: 	Support for additional parameters buttons_selection_PID, buttons_selection_CaseID, buttons_selection_physiciannumber, buttons_selection_sex, buttons_selection_ethnicity, buttons_selection_nationality, buttons_selection_group, buttons_selection_subgroup, buttons_selection_cycle, buttons_selection_subcycle, buttons_selection_rater, buttons_selection_infosource, buttons_selection_assessment in the *.msg file to control which buttons are actually enabled in certain PID collection related dialogs.

Version 3.43 12.02.2010

Added: 	Support for the parameter section#numofdytoaddbefore in *.pds files which can be used to control the y-positions where sections start in single result printouts.

Improved: 	Review, enhancement of robustness and cosmetic refinement of code in aqprsng, aqprcum, aqprqfi and aqwrap.

Version 3.42 10.02.2010

Corrected: 	Code in aqdialog.govorwaerts was subject to causing a "Run-Time-Error RTE 201 at 000C:7D85" in (not publicly available) AnyQuest Version 3.41. A central part of govorwaerts was rewritten to prevent the error from occuring again. It was observed with a configuration for the (not publicly available) SDQP4DE.QDW questionnaire definition, after a single printout (plus optionally other printouts) and the result file had been completely written. The error could be reproduced several times when questions were left unanswered first, using the page down button, so that the system would present them again and ask for their completion. The error could not be reproduced with the latest published versions 3.36 thru 3.40 so far, and the update includes a range check before the critical section of code. A complete review is currently outstanding.

Added: 	Postal address in Switzerland added to the "About" dialog - height of this dialog extended accordingly.

Version 3.41 26.01.2010

Added: 	Support for the field "CaseID" (Fall-ID, Fallnummer) in the Patient-Identification (PID) section, available via PID dialogs as well as for the Fast-Input-Form. The CaseID is handled similarly to the fields "cycle" and "PID", with regard to the PID recognition feature and related menu entries and configuration options.

Updated: 	Copyright notice in aqglobal updated from 2009 to 2010.

Version 3.40 19.12.2009

Added: 	Support for new parameters in the *.pds and *.pdc enhanced printout definition files, to control per defined section of graphs for single and cumulative printouts: the display or suppression of automatically generated numerical graph labels at the minimum, 1/4, 1/2, 3/4 and maximum positions on the y-axis, as well as the display or suppression of numerical results next to (or inside) the graph bars, and the colour of the x-axis and y-axis lines, and the lines depicting the extremes of each graph in either direction. The respective parameters are: section#noq1q3labels=True|False, section#noq2label=True|False, section#nomnmaxlabels=True|False, section#nonumvalue=True|False, section#colorstrongpenr=byte, section#colorstrongpeng=byte, section#colorstrongpenb=byte, section#colordottedpenr=byte, section#colordottedpeng=byte and section#colordottedpenb=byte (with # to be replaced by the respective section number).

Version 3.39 06.12.2009

Improved: 	Enhancement of Questionnaire-Filled-In (QFI) printout capabilities: Added ability to display directtext answer fields and their content. The reproduction of questions and answers now uses the fonts specified in the questionnaire definition file for regular answer field labels, directtext answer field labels, and directtext answer field content, instead of simply using the small printout font. The respective fonts are auto-scaled for the printout according to printer resolution. Text items are reproduced using the same code that is employed for screen display, including clipping to the available textitem area, as well as processing for #UPN inline formulas. #UPN processing for printout generation is limited to statements that do not alter collected data nor questionnaire elements nor computed results. All statements referring to external file-i/o or calling of external applications are also suppressed for printout generation. Restriction of #UPN processing is performed in a way that maintains as much functionality of the contained #UPN code with an unrestricted execution environment as possible. For directtext field content (i.e. free text patient input), any #UPN inline code recognition or processing is completely prohibited. To this end, support for control of UPN processing functionality on individual command level or on command group level was added to the UPN processing machine and to drawtext_taking_care_for_options(), and the latter also received the capability to completely ignore #UPN processing upon request. Answer fields, labels, checkmarks, and directtext content are now reproduced in colour. Directtext answer fields are displayed in the same way as on the screen, i.e. with dotted left/top/right lines. Field frame thickness is specified in pixels for now and not adjusted for printer resolution, i.e. they will appear thicker on lower resolution printers, but checkmarks are drawn so that they are located reliably inside the answer field frame (just touching the frame from inside).

Improved: 	The default printout header frames, trailer (footer) frames, and patient sticker frame can now be produced with round corners. This has also been chosen as default mode, but the old mode using standard rectangles can alternatively be selected in the "Printing" - "General printout options" menu or via a configuration file parameter. Two separate configuration parameters are available for the header/trailer frames and for the patient sticker frame.

Corrected: 	Single printout used the file output settings (from the result formula definition dialog) for digits and precision of displayed numerical result values, instead of using it's own settings.

Corrected: 	On multipage printouts (observed in a single printout), with suppressed default headers and trailers, and without any colour control by *.PD? files, the patient sticker frame could appear in the default bargraph bar gray fill colour.

Corrected: 	In edit layout mode, the number, numeric or text value, and several options were displayed for directtext answer fields only while special answer field display was activated; i.e. this information was not displayed while special answer fields were hidden.

Improved: 	In edit layout mode, the selection status of additional (all currently available) answer field options (i.e.: require non-empty/numeric/positive/time/date input) is now displayed for both directtext answer fields as well as for regular answer fields with activated "open text input dialog upon check" option.

Improved: 	For questions combining both directtext and regular answer fields with discrete answers, from which a single one should be checked, (i.e. some question saying: "Please specify what you rate in the directtext answer field, and then rate it by checking one of the regular answer fields!"), a truly meaningful test whether a displayed question had been answered at the end of questionnaire administration required the directtext field to have an empty "numeric or text value" in order to require the checking of one of the regular answer fields for the question to pass as completed. This would cause the automatically computed numeric and string results of this question to become undefined when any text was entered in such a directtext answer field, and thus, more code would be required in the result formula to compute and receive these results. --- Now, this has been enhanced to allow for simple and intuitive use. - In detail: The completeness checking algorithm has been diversified and handles questions of this type specially, requiring the checking of one regular answer field if regular answer fields are there at all for the question to pass as completed, independently from the numeric or text value that may be specified for any directtext input fields of such a question. This effectively allows you to design a question that has a directtext answer field with a numeric value of 0 or with any non-empty text value, neither of which will change the automatically computed numeric result of that question when the user writes text into this directtext answer field (especially that will not make the numeric result of the question invalid as an empty numeric or text value field for the directtext answer field would do), and still the completeness checking cannot be passed by only writing text into that directtext answer field, but if any regular answer field(s) is(are) available, then one of these must additionally be checked.

Improved: 	A number of string variables still allocated on the stack for aqdialog.govorwaerts were moved to the local heap, thereby siginificantly reducing stack space requirement of that procedure and making the use of writeln to produce monitoring output in this procedure possible again.

Improved: 	Printout generation code has been enhanced by adding basic protection against overflows resulting from the usage of large paper sizes and/or very high printer resolutions, like 4.000 dpi on A3 paper. The Borland Pascal - Microsoft Windows API uses integer variables and thus imposes a coordinate range of -32.767 .. 32.768 in either direction. When the available printout area is measured at the beginning of any printout, basic overflow detection is attempted, and accepted printout area dimensions are limited to a range of 0 .. maxint - 1000 at various stages. This provides a security margin e.g. for labels that may exceed the expected printing area. As a consequence, when you use A3 paper in a 4.000 dpi PDF virtual printer, you may notice that AnyQuest for Windows only uses part of that space for its printout. Similar basic protection was added against negative or unreasonably large printout margins. - Please note however, that neither protection has been designed to be perfect nor to cover all situations. Especially, addition of coordinates of two objects might still overflow an integer variable, possibly leading to side effects like premature page breaks etc.. A resolution of 1.200 dpi on A4 paper (with a maximum pixel coordinate of { 9.921 ; 14.031 } i.e. below maxint div 2) however has been tested for several printout types and worked without problems.

Version 3.38 27.11.2009

Corrected: 	Removed one left over debug messge from the recent revision of the UPN formula handling. The unwanted debug message would appear in a new window as "element[top]: 1   using undefined: 1.10000...E+4932" whenever the result of a SUM command would be undefined.

Version 3.37 07.09.2009

Corrected: 	Processing of jump destinations in CBFs specified as a negative relative offset did subtract the current question number from the offset instead of vice versa and thus usually produced a wrong, usually negative question number as jump target, that would result in an error message.

Improved: 	Support for "Threshold" as UPN formula definition statement in addition to "treshold" (this was a spelling error, now both spellings are supported to maintain compatibility with previously made formulas).

Improved: 	When a result formula is deleted for the first time after the result formula editing dialog has been opened, the same warning message with regard to references by FN UPN statements appears as when a result formula is inserted or is moved.

Version 3.36 07.09.2009

Added: 	Ability to move the position of an individual result formula up and down in the sequence of result formulas of a given questionnaire definition file in the result formula definition dialog.

Improved: 	The warning message advising the user to check formulas for side effects of insertion or changing the sequence of formulas is triggered only once upon any such action after each opening of the formula editing dialog.

Improved: 	The result formula addition/insertion functionality was made much more intelligent and useful with regard to re-use of existing formula definitions before or after the newly added/inserted one. Now, both the UPN formula and the labels of any formula before the newly added/inserted one are independently assessed and: If the item is a label and begins with "Result No. ", the new routine behaves as the old one did. Otherwise, if an item (either label or UPN formula) ends in a number (composed from digits 0..9), this number is incremented, and an additional digit is added, if necessary and possible. Otherwise, the item is copied without any change. This improved algorithm turns out very helpful, for either of the following tasks: (1) Definitions of a series of result formulas that transfer answers of individual question into results with labels consisting of a prefix and an incrementing number, like: v2->AW1, v3->AW2, v4->AW3... (2) Definition of a series of result formulas according to any other schemes with incrementing numbers in the end of labels or formulas, and (3) Definition of a series of result formulas that use a labels which maintain a common part across multiple result formlas. Previously, all these tasks would have required changes (or even complete copy and paste) for much of the UPN formula and all of the labels; now, these tasks can be completed either without any manual interaction, or only require manual interaction for portions that change unsystematically, or in a more complex way than feasible to foresee while producing a generically usable algorithm. The algorithm to protect from accidental generation of a whole series of new formulas by pressing the "up" button for the result formula number for a prolonged time was adopted to accomodate for the new behaviour.

Improved: 	The result formula dialog, when opened, now shows the number of the last result formula defined for the currently active questionnaire definition file, or 0, if none is defined.

Improved: 	Transfer of another mouse related routine into the respective separate unit.

Version 3.35 17.07.2009; 10.08.2009 - 12.08.2009; 29.08.2009 - 02.09.2009; 05.09.2009 - 07.09.2009

Added: 	PC-Speaker feedback for keyboard controlled editing is now switchable via the menu option "Sound" - "PC speaker keyboard edit control".

Added: 	A new menu option "Edit" - "Editing tools dialogs" provides access to a newly added dialog with "General editing tools" (beginning with a versatile multiline text search and replace facility) and an alternative way to the "Question" - "Options" dialog. (An additional entry for alternative access to "Answer field" - "Options" was included in the menu as well, but not completely supported yet and consequently disabled in Version 3.36 prior to any release.)

Added: 	The entry code for the "Question" - "Options" dialog is guarded against being called with no question loaded, and the new menu entries are turned into controlled ones which are active only when at least one questionnaire and one question are actually loaded.

Added: 	Checkmarks are placed in front of the respective new menu entries when corresponding dialogs are selected for being shown (please note that even in this conditions, the dialogs may remain hidden while no questionnaires or questions are loaded).

Added: 	Settings of the newly added text search and replace tools are maintained in *.ini file variables.

Improved: 	Dialog captions and menu entries were reviewed to ensure the consistent use of three trailing dots "..." whereever a menu entry will open a dialog that offers further options.

Quality assurance: 	Checked printing functionality under Linux kernel 2.6.30, wine 1.0.1, CUPS 1.3.11 in a debian testing environment. PDF printout generation as such worked flawlessly - detailed printer configuration was not tested.

Added: 	Display of filenames in edit layout mode for bitmap or wave files linked to question elements.

Added: 	Display of a frame and an error message in edit layout mode instead of bitmap files which cannot be correctly displayed. The respective error message is controllable via the *.msg file, and German and English variants have been included in the default supplied *.msg files.

Added: 	New routines to measure distribution of all/regular/selected answer fields in the current question, and to distribute all/regular/selected answer fields over their currently occupied x/y range either with equal distance of midpoints or with equal distance between the space occupied by individual answer fields.

Added: 	New buttons in the "Question" - "Options" dialog make the latter algorithm available to users to make questionnaire layout editing more comfortable.

Improved: 	Transfer of mouse related routines into a separate unit.

Added: 	Display of mouse pointer coordinates or selected items was enhanced. All information is now permanently available (instead of alternatively depending upon whether objects are selected), and new items like width/height of a selection and letters providing a key to the various numbers have been added.

Added: 	The new context menu entry "Size" offers new functionality: "Paste from position on private clipboard (with fixed center)", "Adjust to text size (...)", and "Adjust to bitmap size (...)" and making questionnaire layout editing more comfortable. Respective keyboard shortcut commands have also been added:

Corrected: 	Answer fields where not selectable for size and position change while having the "direct-text input" option checked (because that option had not existed when the selection code was originally written). The functionality was added, and separate handling for type=directtext was added in other sections of the code, including recomputing and repainting of the selection frame and its handles, to ensure consistent program behaviour throughout these regions.

Added: 	A new "Ins"ert button in the result formula definition dialog can insert a new formula at the current position (previously, new formulas could only be added after all previously existing ones, because there was no user interface to insert a formula - even though the internal code had "insert" capability).

Improved: 	The result formula addition/insertion functionality, for the new formula, examined any preceeding formula (if available) and maintained the UPN formula, while re-setting all new labels to "Result No. n", with n chosen equal to the sequence number of the new formula in the questionnaire definition to which it belonged. The behaviour was changed so that the labels of the preceeding (or succeeding, if no preceeding one was available) formula were maintained unchanged, because in real life, this would cause less necessity for typing or copying and pasting of label portions, than the usage of default label content. The algorithm to protect from accidental generation of a whole series of new formulas by pressing the "up" button for the result formula number for a prolonged time was adopted to accomodate for the new behaviour.

Version 3.34 12.07.2009

Corrected: 	When Jörg's Magic Questionnaire-o-Matic came across the first special answer field in a given question, while spreading values or labels from a text file to answer fields, it would stop processing this question and continue with the next one. This behaviour was sufficient with questions designed in the traditional style, where special answer fields would typically be added after all required regular ones. But it made the Questionnaire-o-Matic effectively skip all answer fields of each question generated with the new default question layout introduced in version 3.33: That defines two special answer fields before any other, regular, answer fields, in order to keep the special answer fields, which are usually located at special positions as well, from interfering with the simple and smooth addition of more regular answer fields to any given question. The Questionnaire-o-Matic was now changed, so that special answer fields are skipped, but any next answer field that might still be available in the same question, would be correctly processed.

Corrected: 	The UPN function strs checked only for 2 items being on the stack before it acted. As this function processes 3 parameters, a wrongful formula invoking it with only two items on the stack could result in a stack underflow with the stack pointer going below 0 to -1. That would not be captured and later cause an RTE 201. The strs UPN function was changed to require 3 values on the stack, and otherwise throw a stack underflow error message. The code later evaluating the stack content was changed to check for stack.top <=0 instead of =0, as it was before, and returning "undefined" instead of making an access to unallocated memory for either condition.

Improved: 	The flag signaling a modification having occured in an edited questionnaire-definition is not set any more immediately when the Questionnaire-o-Matic is initiated, but only when actual changes to the questionnaire definition occur.

Version 3.33 14.05.2009 - 21.05.2009

Overview: 	Improvements in questionnaire editing / undo functionality in special situations; improvements in editing related dialog handling; a highly improved default question layout for generation of new electronic questionnaires from scratch; addition of all editing grid related commands to an "Edit" - "Grid..." menu; improved support for Chinese, other Asiatic, and other non-European character sets; improvements of appearance and code cleanups.

Corrected: 	Systematic testing revealed some errors in the undo function, when some previous editing action in the first loaded questionnaire definition in memory was undone, while a question from the second questionnaire in memory was currently being displayed.

Improved: 	After an editing action in the first loaded questionnaire definition in memory was undone, while a second questionnaire was currently loaded, the graphical progress indicator would display representations of questions from the two questionnaire definition files in reversed order (this would actually truly reflect the new arrangement of questions in memory after the undo operation, but would neither match user expectations nor the order of the questionnaire definition files). Now, the graphical progress indicator obeys questionnaire definition ordering at a higher priority than question ordering in memory, thereby remaining consistent with user expectations.

Corrected: 	The delete_questionnaire() function checks whether the "Questionnaire Descriptors" dialog is open before it deletes a questionnaire. If yes, it destroys the dialog window before questionnaire deletion, to avoid a later possible reference to a questionnaire that does not exist any more.

Corrected: 	If the editing dialogs for result formulas, conditional branching formulas and questionnaire descriptors are open before a question or a questionnaire is deleted, inserted, including as a side effect of undo operations, and in several other circumstances where there no special handling towards consistency of content of these dialog windows had been there.

Corrected: 	Very few minor errors in the dialog related code which had been introduced throuch code re-use among the various dialog function variants were also corrected.

Improved: 	Saving for undo was added before sound file distribution Questionnaire-o-Matic-runs, and closing of open dialogs before any Questionnaire-o-Matic runs.

Improved: 	The result formula definition dialog, when opened, now shows the last defined result formula of the current questionnaire, similar to the conditional branching formula definition dialog, instead of the first one, as it did before.

Corrected: 	When the last question of the first loaded questionnaire definition in memory was deleted, (only!) when questions from another questionnaire were available in memory behind that question, the currently displayed question was not decremented. The first following question would then become the currently displayed one, but the displayed number of the current questionnaire and the graphical progress indicator would not be updated (and thus be flawed) until the user displayed another question. Now, when the last question of a questionnaire is deleted, the number of current question is also decremented (in line with user expectations), if questions of another questionnaire are available after the deleted question.

Improved: 	Improved formula editing dialog with regard to allowance/refusal of new formula definitions, with regard to code clarity and modularity, handling of save for undo and unsaved changes flag, resorted actions counting up and down in formula number control. Simple changes in the scroll buttons of the numeric input fields will not cause direct changes in memory any more, but comparison to previous memory contents and transfer will only occur when formula-numbers are counted up or down, or when the dialog is closed, or when the current question or questionnaire are changed.

Improved: 	Adoption of the new improvements from the result formula definition dialog to the conditional branching formula definition dialog, and further small code cleanup.

Improved: 	Further improvement of the result formula and conditional branching formula editing related triggering of undo functionality, resulting in different (but more reasonable and more intelligent) behaviour with regard to what AnyQuest considers a result formula worth saving before changes, and with regard to what it maintains in memory.

Improved: 	Removal of code controlling the display of editing dialogs from the aqrpnt.repaint into aqdialog.check_all_windows_state, so that dialogs are not displayed any more during the title screen when activated from the *.ini file.

Improved: 	Addition of similar code for the conditional branching formula editing dialog.

Improved: 	Initial cleaning of the questionnaire descriptors dialog; final cleaning of the result formula and conditional branching formula definition dialogs.

Improved: 	Improved control of questionnaire descriptor dialog; save for undo upon receiving of data from the result formula, conditional branching formula, and questionnaire descriptor dialogs only when actual changes are about to be received from the dialog into memory. Remaining limitation:  Questionnaire descriptor dialog saves information from the dialog into memory only, when the "OK" button is pressed, and not when the dialog is closed, or when the current question or questionnaire are being changed (this is a issue and may require conceptual re-consideration before programming; it has however been included in the "Known errors/known limitation" section of this document).

Improved: 	Optimization of startup sequence, so that no editing dialogs nor any questionnaire content become visible (not even shortly) during the startup phase before the navigation dialog is displayed. This renders a very clean, unflashy, startup sequence. Remaining limitation:  I did not get the same result for the exit sequence of the program, related to conceptual considerations, because I want the actual state of the dialogs to be saved into the configuration file (if not prohibited) and did not want to add additional code now (low priority issue).

Improved: 	Removed a conditional debug output line in aqundo, and an obsolete condition handling in aqdialog.

Improved: 	Developed and added a new default design for newly added questions. Instead of simply adding two regular answer fields, and other elements in a very basic arrangement, now, a completely and usably layouted question with both special and 7 regular answer fields, horizontally arranged, and much more usably arranged other elements, everything aligned to a grid, is generated. New built in default texts, and default texts in *.msg files were added or extended to provide more usable editing related information.

Improved: 	Added all editing grid related commands, which had previously been available only via keyboard shortcuts (gs, gl, g0..g9, qcg, rcg), to the menu "Edit" - "Grid". Changed default grid settings from gs=0, gl=0, 50 pixels, to gs=1, gl=1, 20 pixels. This resolution is quite suitable for 1024 x 768 pixels displays, and the newly added default question layout was made with it.

Improved: 	Added support for #nnn in *.msg file processing. So messages loaded from the *.msg message definition file can now contain special characters, or control characters like #013#010 for a line break.

Improved: 	Some improvements in the Chinese SF-36 configuration in the default package anypak.exe, after some research on Chinese character display, so that it will display a Chinese "Directory of loaded questionnaires:" and Chinese characters on the "Continue..." button, "Thank you" box, and "Answers are missing..." dialogs, even on a standard European Windows 2000 system with installed Chinese language support. Before, behaviour depended much more on the actual environment, and it might work on a Chinese Windows 2003, but not on the European Windows 2000 system, after transition to other character sets than originally used on a European Windows 98 system.

Improved: 	Printing will now use the character set specified in font_for_PID_screens_Greek.lfCharSet (e.g. 134), when Greek_PID_collection_and_printouts=True; instead of always using the Greek lfCharSet 161 in this case (setting Greek_PID_collection_and_printouts=True is used to change the way the buttons are labelled in the PID dialog).

Improved: 	Added Chinese lfCharSet support for the large and small PatientID confirmation dialogs. For this purpose, an alternative, redesigned version of each dialogs using BorStatic Text and BorPushbuttons was added; the old versions were however maintained for normal use (in configurations where the lfCharSet is not switched), because only the standard button style provided enough space for the standard German "Abbrechen" button label.

Improved: 	Adjustment of font size + width + weight for the Chinese SF-36 configuration; added spaces around the Chinese "Continue..." on the respective button.

Version 3.32 14.05.2009

Corrected: 	The correction made towards version 3.31 was annihilated by a missing dollar sign in the finally published version - with the result that the built in stack size security check would prevent this version from running at all. The affected version 3.31 was publicly available only very briefly, but a new version number was nevertheless issued.

Version 3.31 13.05.2009

Added: 	An updated and extended SOP for conformance tests was begun, not merely for internal use, but also to be published on the WWW site.

Corrected: 	Systematic testing revealed that entering a text with a wrong format, i.e. not interpretable as a valid HH:MM:SS, into the direct text input field with checking for time format in the "Compute and comment on duration of sleep" demo configuration, would not produce an informative message dialog, but a RTE 202 at 0017:CA81 (Stack overflow). The allocated stack was 6 bytes too small for this function. As I had freed available data segment space in the previous update, the allocated stack could be increased without other ressources competing for that space any more; this was done for both stack and global heap. An update is recommended.

Version 3.30 03.04.2009 - 01.05.2009

Corrected: 	The two error messages denying the creation of additional result formulas, and conditional branch formulas, while the youngest formula is still empty, both included "...for this question."; but the one for result formulas should have read: "...for this questionnaire." This has been corrected in the program and in all message files, where this message appears in either English, French or German.

Improved: 	Internal memory handling for global and temporary string variables was largely revised: a few global variables were moved from the global data segment to the global heap. Usage of message, msg and cptn (was: caption) was homogenized throughout the program. To a much greater effect, certain strings of text, mainly identifying configuration and message file parameters and defaults, were transferred from being typed pchar constants into being simple string constants, and thereby also moving them out of the global data segment. At the same time, the robustness of AnyQuest against unexpeced configuration file parameters was improved. The necessary effort to achieve this is a consequence of peculiarities of the Borland Pascal adoption of the MS Windows API, and my finally solving this problem frees some ressources and is a prerequisite for ongoing extensions of the AnyQuest's functionality.

Improved: 	Internal memory handling of the statistics, cumulative and course-over-time printout functions was largely revised. AnyQuest's statistics functions had originally been designed to be capable to process up to 16382 old *.anq result files, evaluating up to 6553 result formulas at the same time. Windows' memory handling, however, turned out to impose lower limits - at about 2500 or 7500 files depending upon the Windows version, or even much lower on a highly loaded system, and with AnyQuest immediately and completely aborting when Windows would not provide some requested memory. Now, AnyQuest is more tolerant, and when a lot of result files are available, but memory does not suffice to perform a configured request, it automatically (and temporarily) adopts its internal parameters to match the abilities of the system, and provides informative messages. Improved memory management now allows for true processing of up to 16382 old result files for statistics and 16382 old result files for cumulative/course-over-time-graphics at the same time (i.e. reference values computed by the internal statistics modules from that number of old results can be imprinted on a graph computed from that number of [theoretically: other] old results); and all that for up to 405 formulas a the same time. The latter number has been reduced to ensure the number-of-files-capabilities also on smaller or more loaded systems, and to improve processing speed at the same time; it can be re-adjusted in a customized versin upon individual request back to 6553. Worst case memory requirements were reduced from 512 MB (before, with guaranteed inability to reach the theoretical file processing limitations due to Windows memory handle limitations), to 128 MB (after, with guaranteed achievability of theoretical file processing limitations even on older versions of the OS or on smaller systems, and with tolerance against shortages and dynamical adoption). All these changes, including tuning variables controlling the Borland Pascal Heap Manager, and performance measurements for a large variation of settings for the number of old files to be processable, should not merely improve AnyQuest's performance, but its robustness as well. (Compile time configurable) Debug output, HeapError handling, and error- and information messages were added. Performance of these modules was tested and optimized with 18000+ old files available and configurable options turned to processing of the maximum number of files possible.

Improved: 	For the built in statistics functionality, the selection of the last n files had been based upon the order of files returned by the operatint system from its underlying directory structure. This was changed to the more precise usage of the date/time of measurement maintained inside each result file. To keep the performance penalty low, the implied sort algorithm was tuned to highly improved efficiency; this also benefits the cumulative/course-over-time printout graph creation, which has used dot-based sorting before.

Improved: 	Internal variable handling vor the strpasjs() function was adjusted to use the stack instead of a global heap variable (this is actually a return to a previous version), because this function may be called when the global heap is already full and shall still work in this situation. Few other variables were (at least temporarily) returned into global, or unit global, pre-allocated variables in order to be reliably available for storage even when a global heap shortage situation should occur.

Improved: 	The statement "yield" was added to the old result file reading loops in the statistics and analysis modules, in order to give other programs a chance to run in co-operative multitasking environments. (However, the expected beneficiary effect was not really perceived at least under W2K).

Improved: 	The unit aqinimsg was split into aqglobal, aqini, aqmsg, and license information management was moved from an external file to unit aqlicfil to simplify the current program structure and future improvements.

Added: 	In the Analysis tools - Statistics dialog, the progress indicator now shows the name of the currently processed old result file as well as the number of files already processed (in addition to the name of the currently processed [selection] list file and number which have been shown before).

Added: 	The key (Legende) for internally reference lines or reference areas computed by the built in statistics module does now not simply show the configured maximum number of old results, but the actually processed number of old results (or the range, if these differ for different result dimensions), and optionally, the configured value in square brackets, if that differs from the actually processed number(s) of files. The configured value may typically be higher in the beginning of a data collection, when only one or a few old results are available, or if at least one of the processed old result file contains missing results.

Reviewed: 	Some comparative code reviews were performed especially among the statistics and cumulative/course-over-time printout modules; small updates that had been applied only in one of these were adopted to the other if applicable.

Version 3.29 23.01.2009

Added: 	Extension of the expiry date for the unregistered evaluation version.

Version 3.28 01.10.2008

Added: 	Creation of two new custom versions of the executable file: galidgaq.exe and galileon.exe to power a www.qm08.com giveaway provided in cooperation with Dr. Gregor Viethen, Galileon GmbH. Opened Fast-Input-Form mode for questionnaires with short names like kdpzsv. A compile time option DEFINE idm_loadqn_clears_qdw_history was added to simplify the clearance of *.qdw histories for questionnaire definition files, which were accidentally adopted from other *.qdws that had been used as layout templates.

Version 3.27 01.09.2008

Improved: 	When a patient clicks at an answer with a mouse, a pen or a his finger on a touch-screen, the pc-speaker sound signal now comes after the redrawing of the answered question. This reduces the delay before visual feedback, when pc speaker sound signals are activated.

Version 3.26 07.07.2008

Improved: 	When a patient PID was recognized and the name of the patient read from a previous *.anq file, only the name: line was evaluated and split into the internal first name and last name variables at the first space if any occured, or transferred completely into the internal last name variable, if no space was found. Now, if the *.anq file contains non empty fields first name: or last name:, they are given priority over the field name:. If the more specific fields are not available or empty, name: is evaluated as it was before. If all these fields are empty, the field simplename: is additionally evaluated. The effect becomes visible if a patient has multiple first names separated by a space. The detailed internal processing had been unimportant as long as AnyQuest's standard mode was used, and when data was written only back out to the name: field of the *.anq file again. But when data was going to the advanced fields, or to external software, or to the input fields in the Fast-Input-Form dialog, the new behaviour became important.

Input into the PID data fields in Fast-Input-Form mode used to have all special characters below #33, including spaces, replaced by underscores "_"; now spaces are not replaced any more so that multiple first names can remain separate unaffected words in a single input dialog window.

Instead, capitalization has been extended from the first character in each input field to the first character in each input field and each first character after a space.

Corrected: 	Review of the AutoMagic Index (Re-)Builder for index-based patient ID recognition: it failed to process the first file in a given directory. It also received some cosmetic corrections, a more informative ALPHA-status message, and a more informative note in the control file.

Removal of a useless leftover line of code from aqdlgfrm.pas.

Version 3.25 30.07.2008

Added: 	A go-forward [>>>] button for Fast-Input-Form mode and appropriately extended checking for missing answers and cursor/highlight control after pressing the [OK] button.

Improved: 	Robustness of the Fast-Input-Form against questions with zero answer fields which were not Infoscreens. Robustness of the Fast-Input-Form against questions with exactly one regular answer field. Both setups are probably not useful and do not currently occur in questionnaire definition files for which the Fast-Input-Mode is opened, but if constructed they could cause RTE 201 and RTE 207, respectively.

Quality assurance: Checking of behaviour with questionnaire defintion files without any result formulas and without any questions.

Version 3.24 30.07.2008

Added: 	Fast-Input-Form mode enabled for questionnaires whose short questionnaire name begins with eOSCE in addition to the previously supported SIRO, SF-36, C30V3, FLZMseq, SCL90R (upper- and lowercase spelling does matter).

Honouring of the Ctrl-F5/Show special answer fields can't answer/don't want to answer setting in the Fast-Input-Form mode, so that the special answer fields can be hidden or displayed in this mode as well.

Infoscreens after the first question/screen of a questionnaire are automatically transformed and suitably layouted in section headings in the Fast-Input-Form mode. If such a section heading would remain alone at the bottom of the dialog window, the whole section including this heading will be moved to the next dialog window for the next section.

Version 3.23 14.07.2008

Added: 	New configuration file parameters TitleSuppressRainbow and TitleSuppressBitmap control the display of the JMS-Rainbow and of any graphic logo on the title screen. Setting both parameters to True gives the title screen a plain empty white background.

Version 3.22 24.05.2008

Added: 	Support for *.RVS, *.RVC, *.RRS, *.RRC files by which multiple, dynamic, color coded reference values, ranges and labels can automatically be included in printouts (e.g. a combined display of one global reference range in grey, and an additional age and gender specific reference range in rose/light-blue, dynamically selected according to sex and age collected in the patient ID data dialogs). A detailed description of the new features and file format definitions will be added to the on-line help later on.

Improved: 	Some code reviews, testing, and improvements throughout the way of the last additions.

Version 3.21 03.05.2008

Added: 	Support for direct entering of answers via number keys on the keyboard in Fast-Input-Form mode. This mode is active after the cursor has moved from the PID collection fields to the answer fields for the first question. When an answer is recorded, the cursor moves to the next question. Cursor key support has been changed from standard windows dialog behavior to a more intuitive one: arrow up or down move to the previous or next question, respectively, and special suitable behaviour is also implemented for the beginning and the end of the currently displayed range of questions.

Version 3.20 02.05.2008

Corrected: 	Since multiple page Fast-Input-Forms were implemented, the date of test was always kept at the date of recording. Patient ID data were printed too far left, depending upon which data items were checked for being suppressed in the printout. This occured due to the computation of field positions using a too small font.

Added: 	Patient-ID-Recognition capability for the Fast-Input-Form as well. If PID recognition is activated, and an alphanumeric PID entered in the Fast-Input-Form, and the ENTER (RETURN) key pressed, the program will check whether the same PID has been used before, and if yes, fill in the remaining fields from previously used values.

Please note: 	You still have to check the current validity of these values and must probably update some of them. Especially, the "cycle" and "subcycle" fields are filled in from the first found previous values, which should typically be outdated in a follow up questionnaire administration. In contrast to standard questionnaire administration mode with its built in dialogs, there is currently no separate confirmation dialog displayed in Fast-Input-Form mode: we are in a dialog anyway, and can escape/start over immediately anyway.

Version 3.20 24.04.2008

Added: 	New standard entries for some of the new variable fields in de.msg and def.msg; support of xphonework..xnationality now being read from the message file.

Please note: 	Should you be using the fast index based patient recognition feature (which is formally still in alpha development stage and has known limitations), you will see a notice saying that the index files are in an old format after an update to version 3.20. You should remove your index files ...\DATA\INDEX\PIDINDXD.INI and PID12.INX in order to make AnyQuest rebuild them. The rebuild occurs automatically when the first PID recognition is attempted after the removal of the old files. It may take up to several minutes, depending upon the number of result files that must be scanned. After testing, I am actually confident that a change in the file format marker would not have been necessary to ensure compatibility of the index based PID recognition function with the new data fields. However, a full review of the affected code is still pending, so I changed the index file format marker based upon a feeble-minded (you may say) decision. Please also note that I found in the course of the reviews that the PID recognition index file rebuild process will systematically ignore the first result file 00000000.anq, and that it still displays its alpha-status message. These issues will be addressed in a future update.

Version 3.20 21.04.2008

Corrected: 	With activated PID recognition, some extended variables (like the fields of the German health insurance card, sex, ethnicity, etc.) were not refilled even if they were available in the file that caused the PID recognition.

Added: 	New selectable (additional or more specific) PID fields for phone number at work, mobile phone number, phone number of a relative, e-mail address (including specific PID collection dialog with several added special characters), place of birth, and nationality; including the respective UPN commands to transfer values between these variables and questionnaires, and variables for file-output and printout labels. Extension of the larger PID confirmation dialog by the new phone number and e-mail related variables.

Version 3.19 08.04.2008

Corrected: 	When in a UPN formula, a simple mathematical function was applied onto an empty stack, this would cause the program to exit ungracefully - in versions 3.17 and 3.18 you would see a "Run Time Error 201 at 0017:2A45" message. This resulted from a check whether any operand was undefined, occuring before a check for suffcient operands being available on the stack. Now, strict checking for sufficient operands is in place, and it occurs before these operands are checked for anything else, and the stack underflow error message will appear on the screen and in the result of an UPN formula that uses mathematical functions with too few operands. - Moreover, the statement PI would not put Pi on the stack in addition to what was already there, but instead, change the top element into Pi. - Moreover, trying to generate a QFI printout for a newly designed questionnaire with long Inline UPN commands failed as the strpas() function was used instead of strpasjs() to copy strings longer than 255 characters. All code reviewed and all occurences of strpas() replaced by strpasjs().

Improved: 	Whereas respective behaviour was relaxed in version 2.57 in a (misguided, I think) attempt to simplify the use of the CSTOP formula, I have re-instituted (and actually, made more strict) the same checking for the availability of the required number of operators also for simple functions that require only one parameter. Since version 2.57, the usage of things like CSTOP, SIN, NOT etc. on a completely empty stack would neither change anything nor cause an error message. Now, it will cause an error message to be displayed, both on the screen and in the result of the formula containing such the erroneous statement. Addition of separating lines and additional warning hints to the UPN debug functionality output.

Added: 	The two new functions ABS and SGN return the absolute value or the sign of a supplied value. The Tabc function also added abc to the result string, if T was undefined - not only if it was true. As such, it was perfectly complementary to the Fabc function, but not specific. Since version 3.19, Tabc is specific for the "true" case, Fabc remains specific for the "false" case, and a new "Uabc" was added specifically for the "undefined" case.

Cave:  	Due to the UPN implementation changes described before, upgrading to this version may require some UPN formulas to be corrected, if they did either use Pi, or relied on the unspecific action of Tabc in the "undefined" case, or (incorrectly) contained functions operating on no supplied arguments, which was hitherto gracefully ignored. Thus you should not upgrade any productive system whithout need, and if you perform the upgrade you should also perform a UPN code review and testing, especially if you wrote your own UPN formulas, and relied on the unspecific Tabc behaviour for the "undefined" case, or you used Pi, or you might have practiced relaxed coding habits and want to exclude any unexpected messages now possibly proclaiming illegal UPN code.

Please note: 	Such testing and reviewing should also cover any inline UPN code possibly used in conditionally displayed question text. Most users (with questionnaire defintion files using only basic UPN functions) should not experience any different behaviour with this upgrade. Together with UPN code review/testing, I would still recommend it to users who write their own UPN code, because benefits from the strict UPN code checking should be worth the small upgrading efforts.

Version 3.18 05.04.2008

Added: 	Opened the new ShowQnrFastInputForm mode for the SCL90R and FLZMseq questionnaires.

Version 3.17 02.04.2008

Improved: 	Update of some *.ini files supplied with default packages on the WWW to contain more modern options, including default activation of white filler screen between questions, default activation of single question back button, default activation of response to multiple clicks in lower screen area for keyboardless control of special options, default inactivation of response to minimize and change size attempts for the main window during questionnaire administration, default language specific preconfiguration of DateFormatDialog and DateFormatPrint. Change of the Fast-Input-Form mode can't/don't want to answer labels into English (still preliminary). Addition of first *.msg file configurable messages for Fast-Input-Form to application and most provided *.msg files. Extension of the date of test and date of birth input fields in the Fast-Input-Form to honour the DateFormatDialog configuration variable and to provide more useful pre-/re-formatting of the supplied date in language specific environments.

Version 3.16 28.03.2008

Improved:	The course over time printout uses its own indicator COT-listfilename for print job names now instead of using CUM (for cumulative printout).

Added: 	Extension of Fast-Input-Form mode (originally added specifically for the eSIRO questionnaire) to a more generic implementation.

Version 3.15 04.12.2007

Corrected: 	The default file extension shown in the selection dialog for bitmaps associated to question screen objects was changed from *.wav to *.bmp.

Improved: 	Some reworking of internally used idm_... variable definitions.

Added: 	Support of individual printout targets for each of the following printout types: Single-, Cumulative-, Questionnaire-filled-in-, Statistics-, Layout-, Reference-Page-Testdata-Printout. Support of primary and secondary printout target for each of these printout types, so two copies of each printout can automatically be sent to two independent printers or e.g. to one real printer and one PostScript-File or PDF-generator. SinglePrn is used as fallback target for auto generated single, cumulative and qfi printouts if no specific target is defined; all other types do always try to use their own target or another default printer derived from the system or a printer dialog. All printouts issued from the analysis tools dialogs do always go to the StatsPrn and Stats2Prn targets, even if they are delayed copies containing single or cumulative results. If an Xxxx2Prn target is empty, the second printout is not generated at all. If "printer setup" is invoked from the main menu, this opens the SinglePrn setup; if it is invoked from an Analysis tools dialog, it opens the StatsPrn setup. All new targets are read from the *.ini file alike SinglePrn has been read before. They are only written back to the *.ini file, however, if the referenced XxxxPrn or Xxxx2Prn could really be accessed. New advanced printer setup dialog, so that all new printer options can be set up very comfortably; including individual text input fields to specify a redirection target (printer port, other device, or path/filename) for printer output. All new functionality and behaviour are compatible with traditional system setups, but still get the optimal user experience out of these.

Version 3.14 03.12.2007

Improved: 	Before UPN references like Vn, Cn, An are evaluated, if question n has been displayed in the current questionnaire administration session, its numeric and string results are recalculated. This causes some redundant result computation, but ensures that the numeric result of a question is delivered correctly even if the user did not change the answer fields of that question himself, but e.g. they were (pre-)filled (or not even that) automatically by other UPN commands from the content of other questions.

Corrected: 	Default filename extension in the bitmap selection dialog used to link bitmaps to question elements changed from *.wav to *.bmp.

Added: 	Large extension of printing capabilities: namely comfortable support for different printout targets for different printout types, and support for automatic generation of second copies of certain printout types onto different printout target. This e.g. simplifies the overall system configuration for users who want to automatically generate PDFs of all printout types for archiving and electronic processing, and at the same time want to generate a paper copies for all, fewer, or only one printout type(s).

Version 3.13 29.11.2007

Added: 	Additional configuration file parameters to remove the system menu and the minimize button from AnyQuest's main window. Additional parameters to make AnyQuest ignore several signals causing changed window size - see content of this help file regarding "hardening a configuration".

Improved: 	Corrected an internally used function to compute the number of days since 1800 up to a given date. Hardened several dialogs and configuration file reads against input of numbers exceeding the expected range. Some internal changes in variable space allocation.

Corrected: 	Same date-of-birth-processing debugging output was still active. Course-over-time-printout headers couls appear left aligned with second column of graphs instead of further to the left e.g. for the eworde.qdw and eworde.pdc combination.

Version 3.12 20.11.2007

Added: 	Course-over-time plot (originally begun in 2000? or 2002?) reviewed, enhanced, finished a basic version, and made this available.

Improved: 	Corrected an internally used function to compute the number of days since 1800 up to a given date. Hardened several dialogs and configuration file reads against input of numbers exceeding the expected range. Some internal changes in variable space allocation.

Corrected: 	List filename printing position for both course-over-time-plot and cumulative-printout-based-upon-list-filename was too far to the right.

Version 3.11 14.11.2007

Corrected: 	Statistics printouts with a result number exceeding a single page would not reset the y printing position.for the new page to the top of the page. Thus producing succeding results one line per page further and further down.

Version 3.10 22.03.2007

Improved: 	Cumulative printout generation now also supports the parameters in the *.pdc file which control moving the PID info into the PID sticker frame, and suppressing the "Results:" line. The dklmutum.exe custom version for the eSIRO received new logos of the Deutsche Krebshilfe e.v., now generated from a high resolution master.

Corrected: 	In cumulative printouts, the list of points in time of displayed assessment results could exceed the available page width, if the number of displayed results exceeded available space by exactly one. The computation of the exact positioning of the PID info now takes the "name:" label into account even if the offline paper questionnaire evaluation mode is used. Two typos (missing c) in the "printdcusexext" and "printdcuseyext" labels on the printout metrics reference page were corrected.

Version 3.09 10.03.2007

Improved: 	The UPN commands FRSOUAQMODE and TOSOUAQMODE complement the previously available command COPYC in order to resolve a logical problem that could send the SAQLI based questionnaire definition files into an endless loop during checking for questionnaire completeness, when questions were skipped during questionnaire administration. Upgrade recommended for users of the SAQLI based questionnaire defintion files. Please read the UPN documentation in this on-line-help for further details. The SAQLI based questionnaire definition files (English and Netherlands language versions) were also improved by adding the sequence FRSOUAQMODE CSTOP before the Conditional Branching Formulas of questions 39, and 69, respectively. Their version numbers were updated from 0.2 to 0.3.

Version 3.08 (custom) 31.01.2007

Changed: 	When AnyQuest constructs printer job names, it used to construct something like: AQ-YYYYMMDD-HHMMSS-TYP-CONFIGNM. In this version, the CONFIGNM (name of the currently loaded configuration) has been switched off, and instead, the initials and the group/pid (expanded by leading zeroes to 4 digits, as this is what an xDT/GDT/LDT interface can transport) of the patient which were used for the current questionnaire administration are being used: AQ-YYYYMMDD-HHMMSS-TYP-VN-0000. So if printouts are automatically converted to files, e.g. PDF documents, and stored in an archive directory, which is conveniently possible using GhostScript and FreePDF or PDFCreator, it can be more easily recognized which printout belongs to which patient. This change was meant to be used in a local installation only, but until I make AnyQuest's behaviour completely configurable with this respect, I'll leave the originally thought custom behaviour in the distributed version instead, as this version also received very small improvements in processing of (unexpectedly) empty strings.

Please note: 	This behaviour was adopted as standard for future versions until full control via the *.ini-file will be implemented.

Version 3.08 29.01.2007

Improved: 	Absolute conditional branching destinations previously could only be targeted to the short questionnaire name. Now, they can also be targeted to the (exact, including extension) filename, or to short_questionnaire_name.language, in order to allow the interactive selection and presentation of various language versions of a questionnaire that have the same short questionnaire name. A configuration of this kind will not be perfect by itself as long as it's only simply designed, as external commands should also copy different message files into place... but it may be advantageous ad hoc solution when auto-login shall start such a configuration instead of a selection of links to multiple configurations.

Version 3.07 27.10.2006

Improved: 	Before printing a question text in QFI printout, leading and trailing characters below #32 are removed. This means that question texts with leading empty lines are also printed left aligned.

Version 3.06 29.08.2006

Added: 	The questionnaire-filled-in-printout now honours entries section#numofquestions and dyspacerscaling in a *.pdq file correctly.

Improved: 	The placement of elements within the questionnaire-filled-in-printout was once again reworked.

Version 3.05 27.08.2006

Changed: 	The algorithm deciding over the generation of printouts now also requires that at least one question was shown in a session for a loaded questionnaire. Thus, questionnaires that include statically coded printout results (i.e. used as informative reminders or reference values) do not print if not used in the session.

Version 3.04 27.08.2006

Changed: 	While a questionnaire-filled-in-printout would be generated for every loaded questionnaire definition file if the respective option was activated before, it will now only be generated for those questionnaires, for which either a single printout or a cumulative printout would be generated; i.e. for questionnaires that have printable results from the current session, unless the respective override option in the printing menu is checked.

Version 3.03 20.08.2006

Added: 	Support for LASA/VAS scales in questionnaire-filled-in-printouts.

Version 3.02 20.08.2006

Added: 	Several new options have been included in the "Printing" menu, which were previously only accessible from the configuration file *.ini, or for the programmer during development: Automatic generation of a questionnaire-filled-in-printout after each questionnaire administration; generation of a respective test printout; and inclusion of some XY-coordinate markers in printouts for AnyQuest- and Questionnaire definition file development and programming. Alternative ways of arranging answer fields and labels in printouts were added, and a new *.pdq parameter f_label_printing_rearrange was added to control this functionality. This extends usability of this functionality to questionnaires where answer fields and labels are not arranged in a simple horizontal design, and reduces required configuration tweaking for previously supported question types.

Improved: 	Layout of answer fields and labels on questionnaire-filled-in-printouts was improved (both on each page and during recognition of necessary page breaks).

Version 3.01 18.08.2006

Improved: 	Under Windows XP, AnyQuest could be started from auto-start, via start menu entry, as a shell replacement, by double clicking on the program file, or by double clicking on a link - but it could not be started from batch files or from the command interpreter - when you tried, a run time error 215 would occur only for this specific situation. This error would not occur in previous versions of Windows. Now, AnyQuest shows its initial window in ShowCmd mode first, and maximizes it in a second step, and thus, starting it from the command interpreter / from batch files in works in Windows XP again.

Version 3.00 06.08.2006

Added: 	New option in *.anq output file options that can suppress any output to *.anq files for loaded questionnaire definition files of which not a single question has been shown during a session. This can simplify the output file for configurations where you use one questionnaire to chose for each individual session which ones from a pre-loaded set of modules or questionnaires shall be applied.

Version 2.99 29.07.2006

Added: 	When AnyQuest checks whether the configured data directory can be accessed, if the test fails, an external programm can be launched e.g. to set-up or restore a temporarily broken network connection. Afterwards, the directory access will be retried, and only if that fails as well, the user will be notified. More info under "external applications" or [External applications] provide_access_to_data_directory.

Version 2.98 xx.xx.2006-02.03.2006

Improved: 	Additional printout options: Configurability of width used for answer fields in questionnaire-filled-in-printout; configurability of the number of copies per printout type via *.pdc, *.pds, *.pdq configuration files. Improvement of printing functionality for multiple copies. Removal of print_legende from follow up pages in aqprnfi.pas.

Version 2.97 27.02.2006-02.03.2006

Added: 	Prototype of a new printout type (print job named *-QFI-*): Questionnaire-filled-in like printout, showing the text of every question, and the respective answer fields, including labels, checks and resulting numeric or string value of this question.

Quality assurance: Verification/validation of computations for result formulas of two questionnaires, and of a configuration file for extract/extract2 external data extraction tool. Verification/validation of constant memory requirements after repeated program runs with 200 cycles generating each possible printout for a questionnaire definition file with pre-set answers per program run on Microsoft Windows 98 in VMware under Linux, Windows 98 natively, Windows 2000 natively, and verification of program function on Microsoft Windows 95 within SoftWindows95 on Silicon Graphics Irix 6.5. - Leading to next version published on the WWW since 2.89.

Version 2.96 13.02.2006-01.02.2006

Corrected: 	Quality assurance after printout improvements: Check for memory and ressource leaks; closing of three memory leaks.

Version 2.95 22.02.2006

Corrected: 	GPF thrown when started without *.ini or *.lic and thus without loaded questionnaires, probably introduced during changes of initial program calls made on the way to 2.94 or some time before that.

Version 2.94 17.02.2006-19.02.2006

Improved: 	Several internal improvements of code.

Added: 	First implementation of a dialog that can be used to collect results from paper questionnaires into AnyQuest quickly and efficiently, in order to use built in result computation, printing and data storage facilities; this implementation is tailored for a single questionnaire so far, the display of the form is controlled via ShowQnrFastInputForm in *.ini.

Version 2.93 16.02.2006

Improved: 	More accurate new-page-requirement-detection logic for single printout, so available space can be used more completely. - Label printing uses space more closely toward result graph in single printout.

Added: 	Ability to move printed PID into patient ID sticker frame via *.pds entry. Ability to adjust printed date of test vertically to first line of PID via *.pds entry. Ability to disable printing of duration of test via *.pds entry. Ability to print simplified date (only) of test via *.pds entry. Ability to disable printing of y-axis labels for minimal and maximal values, middle value and quarter values for individual sections via *.pds entry. Ability to scale printout fonts via  via *.pds entries (not affecting PID sticker frame height and printed logos height). Distance of sections in printout can be controlled in more detail via *.pds entry.

Version 2.92 13.02.2006-01.02.2006

Added: 	Printer job name is not derived simply from program name any more, but now built from copy(AQ-YYYYMMDD-HHMMSS-SNG|CUM|LAY|STA|METRICS-ConfigurationFileBaseName-copy(initials|first+lastname|name,1,2)copy(dob,9,2)copy(ort,1,2),1,32), with special characters and trailing dash removed. This produces a (quite) unique name for every print job, and if e.g. FreePDF and GhostScript are used to redirect printouts into PDFs in a configured directory, all of these PDFs are uniquely named and can serve as a PDF archive of printouts. - Space between various elements of printout can now be scaled via *.pds/*.pdc file entry dyspacerscaling. PID y offset can be adjusted via *.pds/*.pdc file entry dypidshift. Vertical extensions of graphs in single printout scalable via *.pds/*.pdc file entry dygraphscaling. - Multiple line support for labels in single printout, including forced line break using #013 character sequence, with vertical alignment between center of label and center of graph. - Entries in the printout section of *.ini: bitmapheaderleft, -center, -right, bitmaptrailerleft, -center, -right=pathtoimage.bmp can now specify bitmap files which are produced above or below each generated printout scaled to a height of 4 lines. - The *.ini parameter NaviMinimal=True switches the navigation window from a "Go!"-"Setup"-"Help"-"Exit"+-"Resume" button design into a simpler design with just one large "Start" button and optionally a smaller "..." button to resume interrupted and saved sessions. The entries ConfigTitle=SomeTitleString and DontListQDWs=True can change the text displayed on the initial screen of the program. - Single printout now also supports printing of reference ranges from *.val and *.rng including a key (Legende), just like cumulative printout. - If suppress-license-info set in general printout options, and the string "EVAL" is not found within the three first licensee strings, the program name and copyright notice are not printed on top of each printout any more, but at the right margin, running upwards from the lower left corner, in small grey print. If the string "EVAL" is there however, printing of the license info cannot be suppressed, neither can the program name and copyright notice be moved down and made small. More printout related improvements related to page composition with empty additional footer. Layout printing now honors the print filled frame in general printout options.

Version 2.91 05.02.2006-06.02.2006

Corrected: 	Reading of yaxisdottedvalue2/4 from *.ini file originally added in 2.90 corrected.

Improved: 	Improvement of coloring code for graph printing.

Added: 	Processing of *.pds files in analogy to hitherto processed *.pdc files. Thus, division of single printouts into sections with individual headings and colour schemes, including blending between various colors and color smooth or sharp color transitions at defined positions. Adjustment of new page generation to take into account requirements for graphs or new sections correctly. Support for additional footer lines, freely definable via *.pds and *.pdc files for the respective printout. f_showxyfordebugging (which was added internally in 2.90) now read from and written to *.ini file.

Version 2.90 02.02.2006-04.02.2006

Improved: 	More reworking of the printing code, adjustment of patient ID sticker frame position.

Added: 	f_suppresstickerframe and stickerframetext parameters in *.ini file can control patient ID sticker frame production and text of the remark printed within the sticker. f_showxyfordebugging added internally to control production of simplified printing metrics elements with every generated printout. Multiple graphs from results with similar structure can be joined into a single coordinate system. Enhancement of single printout options and respective dialog towards ability to print bargraphs in addition to hitherto available marks on horizontal lines. Single printout honours all options of this dialog except for those related to reference values or ranges. Call of newly separated aqbigdat.calculate_fast for single printout test, so that bargraphs, and not just missing value indicators, are produced for a single printout test when it is called while a *.qdw with (at least some) answered questions is loaded.

Version 2.89 13.01.2006-01.02.2006

Improved: 	Internal restructuring and improvement of printing code, among other leading to improved alignment of printed results at the right border. Also improved distribution of entries of the times of measurements list on available space in cumulative printout.

Added: 	Printer metric reference printout. Optional printing of a frame where a patient ID sticker can be fixed together with some configurable remark. Internal provision of code to include graphical logos from *.bmp files on printouts.

Version 2.88 04.12.2005

Corrected: 	When a questionnaire used a simple decimal point as missing value code, or when a decimal point would occur in a non-numeric result for other reasons, and data export file generation was configured to use a comma as decimal separator, the decimal point would be replaced by a comma even in non-numeric results.

Added: 	New and improved functionality for the data export file generation: Configurable on-the-fly recoding of "can't answer", "don't want to answer" and "missing result" file output codes, and configurable enforcement of either scientific notation or fixed comma with configurable decimal precision notation. This simplifies data export to various targets, no manual replacement of missing values or re-formatting of numbers in the target application needed any more.

Version 2.87 09.11.2005

Corrected: 	The date of birth automatically re-supplied from result files from previous questionnaire administrations after successful patient recognition, would not pass validation when the DialogDateFormat was set to YYYYMMDD as possible since version 2.82.

Version 2.86 31.08.2005

Improved: 	More detailed configuration of PC speaker signals and PC speaker simple signals; the "OK" sound can now be activated independently for PID collection and questionnaire administration.

Version 2.85 30.08.2005

Improved: 	Further enhancement of the newly added simplified transport bar functionality.

Added: 	New *.ini file parameters allow white filler screens to be displayed between successive screens.

Version 2.84 29.08.2005

Corrected: 	Results of pressing F6..F10 were not always displayed immediately, probably as a consequence of some previous modification of code aiming at reduction of unnecessary window repaints.

Added: 	New simplified navigation buttons, in addition to the hitherto available transport bar. New parameters accessible via the *.ini file control their position and detailed functionality.

Version 2.83 29.08.2005

Improved: 	The configurable parameter "labelof" was added in the *.msg file, in addition to previously available "labelquestionnaire" and "labelfrage", it makes the text for "of" translatable in the display "Question no. x of y". The improvement was included in the files de.msg, fr.msg, en.msg, ne.msg, swe.msg and anyquin.msg distributed with the standard package anypak.exe.

Version 2.82 18./21.03.2005

Added: 	The entries DateFormatDialog and DateFormatPrint in the configuration file *.ini can be used to control the date format for dialogs and printouts. The procedure aqbigdat.validate_date learned to use - (dash) in addition to . (dot) as date separator, and if two dashes are found, to convert them into dots on the fly for further processing within validate_date.

Version 2.81 18.02.2005

Corrected: 	Calculation of space needed to print labels in the PID section did not take into account the two labels "time/duration of questionnaire administration", so if PID labels were chosen very short, these two labels could be printed over in part by their values. Some debug messages that the printing unit could produce if index based PID recognition was turned on in version 2.80 were switched off.

Version 2.80 31.08.2004

Corrected: 	Version 2.79 had too small limits in stack space, thus a Run Time Error 202 could occur when certain string handling procedures inside the program were called. Stack limits were extended, stack use of called procedures was reduced and a dummy procedure allocating some dummy space on the stack at the start of the program for testing purposes was inserted. An update is recommended.

Version 2.79 10./11.08.2004

Improved: 	The newly implemented personalisation functionality was extended.

Version 2.78 10.08.2004

Corrected: 	Trying to produce a test single printout with no result formula loaded at all produced a run time error.

Improved: 	The implementation of the personalisation for registered users has been changed. Personalised data is not stored in the main executable file anymore, but in a separate file anyquin.lic or eortcqlq.lic or similar, corresponding to the name of the executable. This means that in the future, registered users can just download an updated generic executable from the WWW site and thereby update their registered version, whereas previously, a manually prepared personalised executable was needed for each update. Moreover, several configuration settings that were previously only accessible during generation of a personalised executable, can now just be changed in the *.lic file.

Improved: 	The routine reading the configuration file previously understood only "True" for positive boolean settings. Now, it accepts anything with a first letter among "TtJjYy", namely True, true, Ja, ja, Yes, yes.

Version 2.77 09.08.2004

Corrected: 	Names of temporary state (undo-) files could interfere with each other and overwrite each other. Thus, especially partially filled in questionnaires from the second in a list of saved sessions could be lost. The temporary file(s) ~1~1.tmp, ~1~2.tmp and so on, depending upon the number of loaded questionnaires written to save the current state before resuming a session, could overwrite temporary files especially from the second interrupted and saved session that used the same filenames. If another than the second saved session was being resumed when this happened, first questionnaire(s) of the second saved session would be overwritten and deleted at the end of the resumption of the other session. If the second saved session itself was being resumed when this happened, the saved questionnaires were immediately overwritten by the temporary files holding the status from before the resumption was started. Afterwards, the temporary file(s) were read instead of those from the saved session. This should usually have lead to empty questionnaires appearing instead of partially filled in ones. When the pseudo-resumption itself was completed or aborted, the temporarily stored configuration had already been deleted and could not be read back, at least up to the number of questionnaires loaded in the resumed session. This lead to partially or completely missing questionnaires in the configuration from where the resumption was started. This problem should not have lead to accidentally mixed data, but to data from partially completed, interrupted and saved sessions being lost, and possibly even unnoticed before looking at the results, as questions would only be shown during resumption from the point on where interruption and saving originally had occured. - Since version 2.77, each instance of AnyQuest for Windows makes its own private temporary directory for its temporary undo files, so multiple instances of AnyQuest can co-exist with this respect, and resumption of more than one saved sessions should also work correctly. Version 2.77 can still resume sessions interrupted and saved with previous versions.

Version 2.76 04.08.2004

Corrected: 	The generated export file contained an extra character (probably #0) after the filename in each export row. This caused some import routines, e.g. for SPSS, to be unable to recognize columns correctly, and a pre-processing of the export file in Excel or some text editor capable of removing extra characters below #32 was needed.

Version 2.75 30.05.2004

Corrected: 	In sessions that were interrupted and resumed with a time skew that lead to end time before start time (e.g. on the next day or on machines with a time skew), a computed negative test duration caused the program to abort. Now, computation of test duration takes the test into account and delivers specific notes next to the computed time: The old overall note: "(valid only if start and end timed on the same day)" is not produced anymore. Instad, in normal sessions, no note will appear. In special sessions, one of the following notes will appear: "(session was interrupted and resumed)" or "(end time occured before start time - probably computer clock time skew found)". In the latter case, the value of test duration is replaced by the missing value code of the first result formula in the loaded set of questionnaires or by '---' if no result formulas are loaded.

Corrected: 	Interrupting and resuming, but afterwards not aborting a resumed session, resulted in the loss of the saved configuration due to recent modifications.

Version 2.74 24.04.2004

Corrected: 	Single printout starts new page early enough to leave a distance of one empty line towards the footer.

Version 2.73 24.04.2004

Added: 	New keyboard commands controlling new functionality: g1 .. g9, g0: grid resolution 10...100 pixels. go: grid origin: screen center/top left. gl: grid locking. gs: grid show on/off - the grid also shows x/y screen center and x/y 1/4, 3/4 positions. gl: grid lock during editing with specifically comfortable support of moving borders vs. moving complete selections. qcg, rcg: automatic alignment of elements to a regular grid. lal, lar, lab, laa: individual automatic alignment of answer field labels triggered by keyboard commands. lth: individual automatic adjustment of answer field label height triggered by keyboard commands. Selections are not moved any more if the mouse button has not been down for at least 300ms in order to inhibit unintended movement of objects when they only were to be selected. If nothing selected and mouse pointer is moved in edit layout mode, current mouse coordinates are displayed in bottom left corner. Single printout provides the complete patient ID and date/time of test info on each follow-up page, and single and cumulative statistics printout do provide a page count on follow up pages.

Corrected: 	Possible resource leak in getting a printing context closed - this could cause system resources to be reduced with every printout. Position of cumulative printout of extra 1/2 and 1/4 y markers could be wrong for graphs with a barmin different from 0 (printed values and main axis labels were correct, however).

Please note: 	If labels appear to be wrong using small integer numbers as extreme values, they may in fact be positioned correctly but you may have to select more decimals in your result formula to print a more exact label value). Single and cumulative statistics printout do now recognize the printable area lower end correctly and change over to a new page early enough, even if a trailer is printed. Modified flag is set and undo file is written before automatic alignment of answer field labels. Read routine for integers and long integers from ini file did read but not interpret all characters, thus regularly diminishing the printer margin settings. Ini file read used AutoSinglePrintoutStrongHL and AutoSinglePrintoutDottedHL, whereas ini file write used these entries without HL at the end - so effectively these two printout options could not be saved in the ini file. Changed for both sides to use the HL variant (chose this for readability, though the other option will survive unused in existing ini files). Ini file write did not write autocumlimitpdotprint. Ini file write did not write BitmapTrailerLeftPath and BitmapTrailerRightPath (which are definitely unused so far anyway). Ini file write did not write external_app_notify_after_anq_completely_written, -_wait (thereby disabling this function after save/resume cycles), external_check_after_PID_collected, -_wait.

Version 2.72 22.03.2004

Added: 	Index based PID recognition functionality.

Version 2.71 08.02.2004

Corrected: 	The printer test initialization routine has become more robust against invalid configuration data even if running under Windows 2000. The configuration file reading routines can now handle negative numeric data for several parameters, which was e.g. necessary to read all possible dmPrintQuality values without a run-time-error.

Version 2.70 08.02.2004

Corrected: 	The print layout of all loaded questionnaires which caused a run-time error in recent versions during printer initialization was fixed and works again.

Version 2.69 16.12.2003

Corrected: 	The new configurable feature disable_write_ini_file added in 2.68 also affected the writing of current configurations when a session should be saved for later resumption. The flag disable_write_ini_file will now only be honoured at two points: a.) when the current configuration shall be saved to the currently used configuration file when the program is ended, or b.) when the current configuration shall be saved to the currently used configuration file just before a saved session is about to be resumed. The flag disable_write_ini_file will be ignored when a current session shall be saved for later resumption, including the current configuration settings, at this time going into a newly generated extra configuration storage file.

Version 2.68 04.12.2003

Improved: 	Support for extended keyboard-less operation added in 2.63 is now off by default and can be controlled individually for each subfunction by *.ini file parameters kblessctrlspecialclickcheck_1, kblessctrlspecialclickcheck_2, kblessctrlspecialclickcheck_3. Another new entry in the *.ini file, disable_write_ini_file, can make AnyQuest skip the writing out of updated *.ini file parameters when the program is closed.

Version 2.67 28.10.2003

Corrected: 	In the UPN function "power" (UPN symbol ^), using a negative base with an exponent other than 0 would cause a run time error 207 (invalid floaing point operation). The function can now compute the power of a negative base as long as the exponent is an integer with an absolute value up to 2^31. If the base is negative and the exponent is not an integer value in the specified range, it will deliver "undefined" as its result. This improvement was implemented partially by updating my wfns.pas library to version 1.93 and 1.94. - During patient identification data collection, even when date of birth collection was not activated, AnyQuest checked the date of birth and showed an error message asking for a correct date of birth. The check will now only be performed when date of birth collection is activated at all. - Use of the "Ask for PID first" feature added in 2.63 would make AnyQuest accept recognizeable PIDs only, and thus not allow to administer a questionnaire to a patient with new patient identification data.

Version 2.66 06.10.2003

Corrected: 	Another improvement of the new printing functionality: AnyQuest 2.65 showed a printer dialog before each and every printout. - Please review the "printer setup" section in this on-line help file to learn details about the resulting printout control functionality.

Version 2.65 28.08.2003

Corrected: 	Another improvement of the new printing functionality: Printer settings were partially ignored and landscape printing did not work under certain circumstances.

Version 2.64 16.06.2003

Corrected: 	Small improvement of the new *.pdc advance cumulative printout control functionality.

Version 2.63 16.06.2003

Corrected: 	Small correction of interpretation of #013 like escapes in continue button labelling. Improved window handling for continue button and transport bar, they are not shown under the thank-you-box any more, they are not displayed outside of the AnyQuest main window any more, and will not take the focus away from the AnyQuest main window any more. Messages appearining during collection of patient identification data cannot be made disappear anymore by clicking next to them. Directory of loaded *.qdws being displayed during PID confirmation dialog is removed again when another PID collection dialog is displayed afterwards.

Improved: 	Small changes in fixed compiled in German message punctuation. Return to printout handling of *.qdws with only empty results. Modification of some default printout settings to true: PrintFillFrame, AutoCumulativePrintoutBarFilled, AutoCumulativePrintoutDottedMax, AutoCumulativePrintoutDottedRight. Printouts are now generated with transparent instead of opaque background setting, so the background of overlaying texts or dotted lines won't clear out underlying graphics any more. Printing uses system default printer if no other source is defined instead of asking. Printing dialog controls are supported to a greater extent, including landscape/portrait orientation and many other options. These additional settings are also maintained in the *.ini file.

Added: 	Support for extended keyboard-less operation: Clicking into the lower left, middle and right third of the screen 4 times in sequence toggles visibility of can't/don't want to answer fields, of transport bar, and playing of PC speaker standard sound. Navigation PID options can be changed to make AnyQuest ask for alphanumeric group/patient ID before the name, also triggering recognition of the PID entered into this field in this configuration. General printout options included to suppress individual parts of a standard printout. Additional markers at 25%, 50% and 75% levels of cumulative printout can be activated. Printing of values in/over bars / below/above circles can be activated. Additional printer setup configuration options can be controlled from *.qdw specific *.pdc file, including separation of graphs into sections, paper orientation and advanced color control.

Version 2.62 16.06.2003

Corrected: 	Generating a single printout from a *.anq file using the analysis tools, ignored any computed string results. Since 2.61, when "Printout even for QDWs without printable ResultFormulas" was off, cumulative printouts where all results were undefined could not be generated, and neither could cumulative printouts be generated from the Analysis tools.

Added: 	The built in Analysis tools can now numerically compare numeric data followed by a unit (e.g. "Years") which is separated by a space. This makes automatic selections of patient groups according to their computed age possible.

Version 2.61 14.04.2003

Added: 	If a qdw has result formulas but no single printout label defined at all, a single printout will not be generated for this qdw by default. If a qdw has result formulas but no cumulative printout label defined at all, a cumulative printout will not be generated for this qdw by default.

Version 2.60 24.03.2003

Corrected: 	The algorithm for recognition of previously used numeric or alphanumeric PID produced errors since the addition of new ID fields in 2.57.

Added: 	In addition to the "initials" PID field, the fields for "physician number", "group", "subgroup", "cycle", "subcycle", "rater", "information source" and "assessment" can be configured to be asked via Get-PID screens at the beginning of an assessment though the numeric or alphanumeric patient ID was recognized, because this information can change from one assessment to another while all of the other PID information is expected to remain stable.

Version 2.59 20.03.2003

Corrected: 	The algorithm for computation of patient age at date of test contained a small error. Depending on the month in which the patient was born, it computed the number of days the patient had lived in his year of birth inprecisely. The resulting errors in the computed age in years (in days), were depending upon the month of birth: Jan +7/+6; Feb -26/-16, Mar +4, Apr -5, May +3, Jun -4, Jul +2, Aug +2, Sep -2, Oct +1, Nov -1, Dec 0. Resulting errors were small in relation to a patient's age (maximum for a child born in February 28th, normal year, rated after 306 days on the following Jan, 1st: -8.5%); the maximum possible errors were below 1.5% for a 5 years old patient, below 0.8% for a 10 years old and below 0.2% for a 40 years old patient. Thus, the error remains within least significant digit of the age provided in output files, being close to the resolution of this digit for most patients, and is below the resolution of the last provided digit in printouts except for very young children. If someone should need perfect results in their *.anq files, I can provide a utility that corrects computed age data in existing *.anq files upon request. Version 2.59 and above contain a corrected algorithm. The error became apparent when I experimented with high-resolution output of the computed age for new purposes. - The file usedname.ini containing the variable part of the last used anq output filename did not work in a well-defined way when it was read by another configuration using a different number of fixed leading output filename characters than the configuration that had last written usedname.ini. Now, excess zeroes are removed or unused zeroes are added to the variable digits read from usedname.ini to exactly match the number of available digits left over by the current fixed leading characters setting each time before the next available filename is generated. Moreover, the algorithm protecting existing anq files from being overwritten by new results after e.g. tampering with or removing usedname.ini did not work with fixed leading characters. Now, it works.

Added: 	The actual filename for usedname.ini can now be specified per configuration; it can be changed in the output file options dialog or in the corresponding *.ini file. The new function GETAGE has been added to the UPN implementation.

Version 2.58 14.12.2002

Corrected: 	The newly added #UPN....#UPN-functionality brought an error that could cause AnyQuin to abort with an RTE when certain questionnaires with empty text elements were displayed. The external modules demo was e.g. affected.  In cumulative printouts, reference values and immediately computed local statistical references were not offset in graphs that did not have 0 as minimum.  The sequence in which various reference values and ranges are produced has been rearranged: Now you can select multiple combinations of reference values and ranges from internal and external sources without experiencing that value lines become invisible when range bars are drawn over them. Additionally, 1 SD ranges are printed after 2 SD ranges, and inner quartile ranges are printed after outer quartile ranges for the same reason.  If there were at least one measurement(s) with questionnaire A, and one new measurement with questionnaire B for the same patient, and you wanted to generate a cumulative printout including questionnaire B which should show imprinted twofold standard deviation computed from the n most recent measurements, AnyQuest would abort with "run time error 205 at address FFFF:FFFF", and only be able to produce the cumulative printout when at least two measurements would exist for the second questionnaire.

Improved: 	Shareware introduction dialog text redesigned.

Version 2.57 07.07.2002/11.07.2002

Corrected: 	The UPN function GETC left an undefined value on the stack before its result, thus causing errors reporting unused elements on the stack.

Improved: 	The stack counter may now be decreased to 0 (=empty stack) in the course of any computations. Before, a stack underflow error was already generated when this occured, so pre-loading was required e.g. if CSTOP should be used.

Added: New UPN functions GETVAL, VALS, STRS commands can be used to convert strings and numbers into each other. SETC command can now also uncheck an answer field. In the edit-layout-mode, the number of each answer field is shown additionally before its numeric or text value and other options. The first answer field of each question has the number 1. GETLSC and GETLSNC can now retrieve labels of and answer field depending on whether it is checked. GETMCSSLSC and GETMCSSLSNC can do the same for multiple answer fields and automatically concatenate their label texts seperated by a comma and a space. The UPN machine was enhanced to be able to process #UPN....#UPN sections within question, explanation, explanation two and answer field label text. Thus, more dynamic questionnaires have become possible, e.g. displaying a patient's name on every screen while presenting the questionnaire.

Version 2.56 25.06.2002

Corrected: 	In version 2.54, on-screen buttons with numbers for collection of numeric patient identification data, street address and ZIP code were deactivated in the process of improving the PID collection dialogs. They are available again. The Patient ID recognition feature introduced with 2.54 did not work with non-English *.msg files. This has been corrected.

Version 2.55 13.06.2002

Corrected: 	Fixed a very small memory leak in the new recognize PID code.

Version 2.54 26.04.2002

Added: 	Functionality in the Patient ID collection dialogs: [ESC] or [Alt]-[F4] can now exit the PID collection immediately. Pressing on the displayed [<<<] button when cursor is leftmost in text field will go back to previous screen. Recognize PID in follow up session functionality can be activated: it will fill in complete PID from previous ANQ file, if a previously used numeric or alphanumeric patient ID field is entered in one of the name/initials collecting screen.

Version 2.53 25.04.2002

Corrected: 	Using multiple an/or large images could make the program and the GUI hang completely. The underlying cause is in a StretchBlt function of the various MS Windows operating systems which has been admitted to be buggy. I've modified the software to display the images in another way. Additionally, a resource leake appearing when images were attached to answer fields was fixed.

Improved: 	After resizing, the AnyQuest main window will now redraw its contents immediately - which is most obvious when you display bitmaps but doesnt affect other contents except for some buttons so far, because questionnaires are designed to be operated with a full screen display layout anyway.

Version 2.52 28.03.2002

Improved: 	If you do not select "not empty" from the options of a DirectText answer field, other checked options will only be tested, if anything has actually be written into this field. Error messages after a failed test for a valid time format have previously only been delivered unspecifically, now, a more specific message will appear if reasonable and possible. For all of these tests (valid number, positive number, time, date), the more specific error messages will appear as well, if in addition to the single specific test, "not empty" has been checked. Before, specific error messages would only appear when only the specific test was checked.

Version 2.51 11.03.2002

Corrected: 	In cumulative printouts, brackets supposed to appear around missing measurement to distinguish them from zero results had been lost. When Result Formula Labels were right aligned substrings of other Result Formula Labels from the same questionnaire, cumulative output generation could become confused. Re-activation of response to three-level menu restriction parameters in configuration file which did not work any more since version 2.42.

Improved: 	In single printout, horizontal line can now be shown as it used to be, in dotted style, or not at all. Indicators of a result exceeding the min - max range have also been added. Whereever round shapes are printed, the ellipse function is used now instead of pie; resulting in nicer looking shapes without a horizontal line in them. The UPN machine has been made more robust against mathematical expressions rendering undefined results: Division (/), LOG, SUM, AVG, MIN, MAX, GETC, SETC, COPYC now check their parameters before executing and return "undefined" instead of aborting the program when they come across a problematic one. The program now checks long and short names of loaded questionnaires to be not empty and to contain at least one non-space character when a questionnaire administration is started.

Added: 	Printout functionality to generate profiles for both single and cumulative printouts by printing connecting lines between individual measurements. Additionally, options to print circles in both printouts types. Support of various constellations of min and max for graphs: in addition to 0 < min < max and 0 = min < max, the abszisse is now also printed at y=0 for min < 0 < max, min < max = 0 and even vor min > 0 > max. An option was added to ignore the "initials" field under certain conditions when testing for the PID of a result file (to enable people who abused the initials field to conveniently collect a parameter like number of therapy cycle to generate cumulative printouts more easily).

Version 2.50 03.01.2002

Corrected: 	In version 2.49, during questionnaire editing, a run time error 202 at 0009:0032 could occur due to a stack overflow in conditional branching formula consistency check when a certain sequence of actions were issued. The respective part of the formula consistency check algorithm was identified and modified to use less stack space. It should also have become faster as a result of the modifications. In version 2.49, a run time error 5 at 000B:.... could occur when trying to write a *.qdw or *.qdt file over a write protected file or something similar. A nicer error handling has been included for this, showing an error message (couldnotbesaved) which has been added to the *.msg file.

Version 2.49 16.09.2001

Added: 	Some new UPN commands to manipulate strings, and to manipulate question text, answer field notes and answer field labels during the presentation of a questionnaire. UPN command to stop the execution of a UPN formula depending on a condition. These features can be used to generate morphing questionnaires, e.g. to allow a patient to enter an additional symptom in a direct text edit field, and later to ask how strong this symptom was in a separate question, or to load question texts or answer field labels during questionnaire presentation from an external application. Formula consistency check for the CCA command introduced with version 2.48.

Improved: 	The automatic cursor reset function available via [Ctrl]-[F11] now sets the cursor outside the lower right corner of the desktop, and no more to the lower right corner of the question. When you browse backwards through the questions and you are not in the edit layout mode, AnyQuest skips backwards until it hits a question which has actually been displayed. Whenever a question is skipped due to a conditional branching formula while advancing forward, any checks and notes which have been added to this question, are now removed. Both features are useful during navigation through interactive questionnaires.

Corrected: 	The formula consistency check did not decrease references from conditional branching formulas when questions were deleted.

Version 2.48 08.09.2001

Added: 	Ability to produce deferred single and cumulative printouts looking identical to those which would have been produced automatically by the immediate printout function. Ability to select individual result files or groups of result files using a comfortable dialog and to generate lists of output file names from these selections. Ability to process lists of output file names automatically to generate: Single printouts, cumulative printouts, cumulative printouts ignoring the patient ID, basic statistics printouts, box and whiskers plots, course over time plot, individual export files for subgroups. Ability to write an *.anq output file even for aborted sessions. Possibility to limit the number of printed date/time of test information items to two lines for cumulative printouts. Ability to write detailed information regarding interruption, continuation, resumption, abortion of sessions into the output file using a new section [session log]. This section can be processed adequately by the data export and file selection tools. UPN machine supports the new command CCAn to count the number of checked answer fields in a given question. QDT export and import functionality can now also handle conditional branching formulas. Possibility to suppress printouts for questionnaires with undefined or empty results.

Improved: 	Separate context sensitive helps are now shown for result formula and conditional branching formula editing dialogs. Formula consistency check is automatically deactivated during loading of questionnaires if the edit layout mode is not activated to save time. Stability when trying to use the Undo functionality after starting AnyQuest from a read-only data storage medium. Stability when using keyboard shortcuts to edit non-existant answer fields. Data export routine will not modify decimal separator for unknown sections in *.anq output files any more. The menus have been re-arranged and a new menu "Analysis tools" has been created. Several internal improvements in the code, mostly regarding memory handling and memory access.

Corrected: 	The functions of the keys [Ctrl]-[F1] .. [Ctrl]-[F4] have been resorted in order to match the description in the on-line help file.

Version 2.47 08.08.2001

Added: 	Support of keyboard code "an" for "answer field numeric or coded value". Answer field label and answer field value processing capability in Jörg's Magic Questionnaire-o-Matic.

Corrected: 	After the resource management optimization, Version 2.46 of the generic evaluation version did not ask for the patient date of birth (or another purely numeric identification) any more because the necessary dialog resource was missing.

Version 2.45 25.06.2001

Corrected: 	Run-Time-Error 201 (Range Check Error) at 000A:3BBD could occur when the result formula edit window was displayed when the currently displayed questionnaire definition file had no result formulas and questionnaire definition files with result formulas had been loaded or created and removed before.

Added: 	Functionality to disable specific buttons from the "AnyQuest Navigation" menu in order to prepare a secure configuration.

Version 2.44 26.03.2001

Corrected: 	Erroneous processing of the FN command was possible under certain conditions. This could result in FN interpreting the given formula number the wrong way, putting the numerical result of another than the expected formula onto the UPN calculation stack.

Version 2.43 08.03.2001

Corrected: 	Erroneous calculation of test durations above 1 hour. Direct text edit areas and contained text might remain visible when switching from a question directly to the navigation dialog. When the checking of direct text contents was initiated through the continue-button or the transport-bar, after a notice that the direct text answer field contents did not match the requirements, the cursor would not remain in the affected direct text answer field.

Added: 	New UPN command Em:n interprets direct text answer field contents as time, computes the corresponding number of seconds and places them onto the UPN computation stack. New option Edit - UPN formula debug mode allows questionnaire designers to trace execution of UPN formulas step by step, watching the UPN machine's internal condition.

Version 2.42 18.02.2001

Corrected: 	A minor possible memory leak was closed around the calling of external applications.

Added: 	New UPN commands to enable AnyQuest to call external applications at any position in UPN formulas e.g. to perform calculations, and commands and a protocol to exchange data with these external programs. (This functionality was added to create an effective implementation of the SF-36 scoring algorithm as depicted in the SF-36 user's manual.) New options in the *.ini-file can restrict the menu items available when the program is started, so menus for editing or loading/saving questionnaires can be disabled. Another option controls whether questions can be answered and one can flip through loaded questionnaires in setup mode.

Version 2.41 12.01.2001

Corrected: 	When looking through the [computed test results] section of *.anq-files for included measurement units, the export file generation now skips all such result dimensions where the last character is a space. It assumes that this indicates that *no* unit was defined in the result formulas. Prior versions interpreted everything after the first space as a unit even when there was a trailing space in the result, thereby splitting occasional text results with included spaces into value and unit erroneously at the first space.

Version 2.40 15.12.2000

Corrected: 	Direct text input field immediate check options now also work for the last loaded question.

Version 2.39 17.08. - 16.10.2000

Improved: 	Keyboard editing commands will only be recognised when the AnyQuest main window is the active window. Redrawing approach of patient ID collection screens. Support for building and maintaining versions with custom specific layout with optimized build directory structure and central control of customizing parameters (including internal "howto" covering this topic). When a question is being skipped, now its "was shown"-flag will be reset. This avoids endless "missing questions..." loops which could be provocated by using the navigation keys in earlier versions with special questionnaire definition files.

Corrected: 	Formula consistency check would unwantedly change source and target references in CBFs while questionnaires were loaded. Navigation commands issued with Page-up, Page-down, Home and End keys would produce a run-time-error when no questionnaire was loaded - now, they are ignored in this case.

Updated: 	SC logo and contact address in the background of the generic version.

Changed: 	Most dialog resource fonts moved from System 10 Pt. (default) to Arial 10 Pt. In patient ID screens, characters from the buttons are now fed directly into the text input field instead of being decoded via a button number. "Jörg" in copyright message for printouts and *.anq file replaced by "Joerg" to allow correct appearance with Greek (or other nonstandard) fonts. The "T" and "F" UPN commands do not remove the top element from the stack anymore.

Added: 	Support of Greek (and partly, other) character set for the text-edit box, the patient ID collection (including additionally prepared screens for collection of alphabetic and alphanumeric information with 24 Greek character buttons), the Continue-Button (the new any-font-support and auto-sizing/positioning-behaviour of the button are available as an alternative to the old button font and behaviour), the messagebox used to display messages from AnyQuest directed to patients (using a new message box routine, it also displays line-breaking by including #013 in the message text within the *.msg definition file), result printout label edit fields in the formula definition window, printout elements. Character sets and patient ID screens used can be controlled from *.ini file, and (partly) from a new menu option. Notification about used character set in the produced *.anq file. Option to define an external application which is called after *.anq file has been written and printout has been produced in the *.ini file (to actively trigger data collection into third party system). Option to define an external application which is called after all selected (or none, if none are selected) patient ID screens have been displayed and thereby collected (or empty) patient ID record has been written to a file in the *.ini file (to have collected patient ID tested against existing third party database, or completed from existing third party database, or completely supplied by third party software, e.g. a card reader controlling software). Ability to print out patient ID data collected from third party external application. UPN commands undefined and testundefined.

Version 2.38 30.07.2000

Corrected: 	When the software was started using a root directory as working directory, it could not write temporary files.

Improved: 	Key assignments to menu items completed for the main menu and the context menus.

Added: 	Keyboard command support for several editing commands, so that a user who creates or edits questionnaires needs to change between pointing device and keyboard less often.

Version 2.37 18.07. - 20.07.2000

Corrected: 	File - Import of items from *.qdw files would not work correctly in several situations. Import is replaced by file load automatically when there is no questionnaire loaded so far. The program would not work correctly when its memory limits would have been reached during loading an old file format *.qdw. No matter where questionnaires were inserted, their new questions would be appended at the end of the question storage area, so the progress indicator could get confusing during editing; now, questions should alsways be stored in the same order as their questionnaires. Removed a debug-message which appeared when opening/importing files. When deleting questions, some text fields might not be correctly cleared from memory.

Improved: 	Quesitonnaires are now not always loaded after all other loaded questionnaires, but directly after the one which contains the current question. When questions are imported from *.qdw or from *.qdt files, the first imported question will appear behind the currently displayed question. Improved security of scaling algorithms that handle different display resolutions.

Added: 	Availability of quite complex formula consistency check for result formulas and conditional branch formulas that should treat all formulas correctly when questionnaire definition files are imported into other questionnaire definition files from out of *.qdw files. Generation of ASCII text files *.qdt which contain clearly readable representations of main parts of questionnaire definitions which can be edited with an external text editor. Possibility to execute such text files to generate a questionnaire definition. Possibility to select a prototype question which controls the appearance of new questions and answer fields while editing. Possibility to jump to the selected prototype question while editing. Possibility to select another anchor question. Possibility to jump directly to this other anchor question while editing.

Version 2.36 30.06.2000

Corrected: 	When using certain screen layouts for questions of type VAS/LASA, where the x-axis-middle of "Can not answer" / "Do not want to answer" fields would be situated within the x-axis-middles of the VAS/LASA endpoints, computation of numerical results would erroneously include numeric values of these special fields. The error becomes obvious when testing such a questionnaire. It was probably introduced when VAS/LASA questions first learnt to display additional fields simultaneously. - Some remaining old phone numbers removed. Answer field option "Show text input field on check" could not be set using the appropriate checkbox correctly. A run-time-error 201 could occur when editing result formulas while a question without any answer field was displayed.

Added: 	Individual answer fields can now have the property of unchecking all other answer fields of the same questions when checked and vice versa. This can be used to construct answer field groups like: "Check all that apply:" - "No days" - "Yesterday" - "2 days ago" - "3 days ago". New UPN commands: min and max. In result formula editing, leaving the label for single or cumulative printout empty makes the respective result ommitted from the printout. New file-format version 2.36.

Version 2.35 30.03.2000, rebuilt and packaged 18.05.2000

Updated: 	My phone and fax numbers in the program; usability of evaluation version extended until 31.12.2000.

Version 2.35 30.03.2000

Corrected: 	ANQ file would not contain text collected via the additional text input feature of *regular* answer fields. Instead, text entered there would be erased immediately after going to the next question. Strange looking behaviour when a regular answer field would be checked, and later on unchecked, after other questions had been displayed: the additional text input windows of "can't answer" / "don't want to anser" from the prior question would open up. Cumulative bargraph printout would not work correctly for result dimensions with minimal value other than zero, instead, bargraphs would exceed maximum value. Questionnaires containing answer fields with empty "numerical or string values" could not be loaded (relatively new automatic decimal-/thousands-separator adjustment caused trouble here). When trying to store recorded data into an invalid targed data path, AnyQuin would abort instead of showing a dialog. "PC speaker simple sound config" help button activated.

Improved: 	If there is any text entered in an additional text input field of an answer field, a pencil shaped indicator appears in the field. When a questionnaire session is started pressing "Go!" in the "Navigation Window", AnyQuest checks for the availability of the defined target data path even before the session starts. It handles problems appearing after the session quite reasonably now. In personalized (registered) versions, AnyQuest comes up directly with the "AnyQuest Navigation" window, instead of the hitherto remaining about dialog. "Data folder setup" directory browser works now without a filename to be specified.

Updated: 	My e-mail and WWW-Adresses in the program. Common appearance of all dialog windows.

Version 2.34 03.01.2000

A version of the main program generated specifically for the preliminary study of an electronic EORTC QLQ application, accompanied by specific on-line-help and setup program; all accompanied by general versions for anypak.

Version 2.33 18.11.1999

Improved: 	Cumulative printout function will not include data collected with prior questionnaire definition file versions, if version descriptors have been set. In cumulative printout, undefined results and those from prior qdw versions are indicated by parenthesis around the measurement index to make it easier to distinguish them from results which equal minimum values.

Version 2.32 02.11.1999

Added, improved, corrected: Several features required by the eIBSQOL; e.g. statistics and reference value printout options for cumulative printout. Generation of a customized version without editing options in the menu.

Version 2.32 beta, 11.10.1999

Added: 	New file-format version 2.32. Questionnaire definition file language and version documentation support. More keyboard support: Tab/Shift-Tab now available in all dialogs. Home, End, Page Up, Page Down resemble transport bar functionality. Cumulative printout can include reference value or reference range from external file. Overriding anyquin.msg can be specified in *.ini file.

Corrected: 	Limited decimal separator and thousands separator functionality begun in 2.28 would not support old QDW-files on different international configurations producing strange computed results. Now, the current separators are stored with each QDW-file. On a target system, separators used in purely numeric answer field values are adjusted to local settings. "File" - "Clear-All" would not work correctly in all cases. Last result formula of each qdw could not be deleted in all cases; result formula definition dialog behaviour is now changed. Generating export files would not handle occurences of multiple parameters with the same label in different sections of the anq file correctly.

Improved: 	Cursor-movement with arrow-keys has accelerating profile. Export table size limit enhanced from 1002 to 16384 columns. Generate export file options are more differentiated now, including questionnaire definition file meta data. While exporting, the search for and replacement of decimal separator in output data now leaves more probable text fields untouched.

Version 2.31 beta, 20.08.1999

Added: 	Print margings are now adjustable via printout options dialog.

Corrected: 	Cumulative printout would only read first result section of any *.anq file, thereby producing empty cumulative printouts for all loaded questionnaires but the first one.

Improved: 	Minor adjustment in cumulative printout: numbers labelling individual bars where shifted down a bit.

Version 2.30 beta, 11.08.1999

Corrected: 	When resuming a session, previous versions would initialize all questions answered in preceeding sessions with an undefined numeric result and not-yet-shown-flag. Now, the values from the interrupted session are retained correctly. Help button for *.anq output file options works now.

Version 2.29 beta, 17.07.1999

Corrected: 	Since version 2.28, date of birth would have been accepted even if a day in the future was entered. In this case, a wrong age would be computed. Both errors are corrected.

Version 2.28 beta, 17.06.1999

Corrected: 	Immediate reaction of all answer fields of a question upon text input into direct text answer fields restored. Direct Text edit windows appear with 2 pixels frame on all of their sides instead of an asymmetric one. Run Time Error that appeared, when no questionnaire was loaded and loading a questionnaire was unsuccessful or aborted eliminated. UPN processor and UPN formula consistency check will now be resistant to empty formulas. Internal string processing improved, as dump tree function did not work with long question texts. Finally corrected the error that would cause "modified"-flag to be set when an additional text input window was used. Checking of correct contents of direct text edit windows, before currently displayed question changes. Save/resume/navigation windows have reasonable behaviour now, with correct re-display of questions as required. Undo-mechanism and save/resume do not leave any questionnaires loaded before loading those from the undo-store any more.

Improved: 	Year-2000 Compliance has always been there :-). But now, year 1900-compliance is, too - this means, that the "29.02.1900" will not be accepted as date of birth any more. Some improvements in Save-/Resume functionality and its handling.

Added: 	A question can have the new property "Direct-Text + Discrete answers, single check". New file-format version 2.28. Some limited additional support for international settings concerning the decimal and thousands separator. Immediate checking in direct text input fields for valid not_empty_field, number, positive number, date, time. *.anq-output-file options can be set: Ability of AnyQuest for Windows to remember the last used file name in a directory and to continue generating filenames from the succeeding one. Ability to use up to seven fixed leading characters for the generation of *.anq filenames. Ability to write questionnaire related meta-information into the *.anq-files. Ability to set the mouse cursor away from the answer fields and to the lower right angle of the question area when a new question is displayed during the application of a questionnaire.

Version 2.27 beta, 01.06.1999

Corrected: 	Printout might cause an error when preparing fonts for very high resolution printers. Security-check "questionnaire modified but not saved, do you want to exit anyway?" could appear erroneously since version 2.25. "File"-"Clear all" and "Undo" treat (even filled) direct text edit fields correctly, now (Version 2.27 immediate fix release).

Changed: 	UPN default formula displayed in Result formula edit window replaced by empty string.

Improved: 	File-format expanded to version 2.27, still downward compatible until version 2.13, to allow long result formulas. Result formulas can now be up to 32384 characters long (instead of 255).

Added: 	UPN formula FN to put the result of a previous result formula onto the UPN machine's working stack.

Version 2.26 beta, 22.05.1999

Corrected and improved: Background colour is showed correctly behind numeric result or string result. Live display of numeric and string result for individual questions. Answer field logic for single- and multiple answers. An answer field's numeric or text value can now be set to empty string without GPF. Statistics display will not disappear for long result strings anymore. Default file extension in dialogs set back to *.qdw. German internal texts ending with space now show space correctly. Errors upon changing printers corrected. Wording of German error message for missing answers corrected. If you chose to ask for a simple name, this will be asked after christian name, given name and before date of birth now (instead of after patient id code). UPN-Machine now allows for processing of formulas of up to 32384 characters length internally (instead of 255). UPN-Machine now has working stack of 6552 numbers of extended precision (instead of 255). File-format expanded to version 2.26, still downward compatible until version 2.13.

Added: 	Additional text input windows come with different text depending on whether they are Cannot/Don't want to answer or regular answer field. Text input windows in editing mode show the type of the item whose text is being edited. Answer fields can have new property "DirectText" which allows text input fields directly in a question. Status display can display total numbers of questions and loaded questionnaires in addition to current numbers. Graphical progress indicator. UPN formulas to retrieve additional text or direct text from an answer field and to send text to internal patient-id variables. Keyboard support to fill in questionnaires (except for Lasas, so far). All printing related menu commands moved to a new menu "Printing". Cumulative printout generation. Print Layout function. Added functionality in print options. Test printouts directly accessible from menu "Printing". Added functionality to save and resume interrupted sessions. Function "File"-"Memory Report".

Removed: 	Code to generate minimal demo-questionnaire from menu "File".

Version 2.25 beta, 13.04.1999

Corrected and improved: Private text clipboard enhanced to hold more than 255 characters and to work correctly, if an empty text is copied to it.

Added: 	(Finally...) Undo functionality · .

Added: 	Processing of texts coded to answer fields instead of numeric values only (was possible in MS-DOS version before).

Version 2.24 beta, 16.03.1999

Corrected and improved: Functionality of translation utilities as well as copying of objects' positions.

Corrected: 	Header line of generated *.anq files.

Version 2.23 beta, 15.03.1999

Re-established: 	In Auto-Proceed-To-Next-Question mode, the 300 ms delay after giving an answer was re-established. It hat been disabled to speed up processing internally during questionnaire development. Please be careful when comparing questionnaire answering times between questionnaires filled in with different versions of the software! (Note in Helpfile added.)

Improved: 	In Auto-Proceed-To-Next-Question mode, the timer for proceeding to next question after answering, is killed when: any transport-bar button is pressed during timed delay (previously: only after go to next question button) or: a given answer is removed in a single-answer-question.

Version 2.22 beta, 07.05.1998

Corrected: 	If text was entered in certain text fields which had been loaded empty, a runtime error occured. A resource ID concerning properties of answer fields had been used twice - this was corrected, too.

Version 2.21 beta, 02.05.1998

Added: 	Display of directory of loaded questionnaires with navigation window. Support for displaying images as background for questions, answer fields and texts.

Improved: 	*.ini and *.msg file names specified as command line parameters are expanded to current directory. Most internal strings (especially texts for questions, explanations, labels) have lost the limitation to 255 characters. *.qdw file format upgrade to 2.21: usually smaller files; formats 2.13 and 2.20 are still supported. Improved default question properties (fonts, questionnaire name position). Corrected: Internal handling of patient identification dialog display, question display, transport bar display and screen refresh. German text for "Messung nach" in printout corrected. "Changed" flag is set correctly after loading a questionnaire. Sound file playing capacities now work correctly.

Updated: 	My address in the startup screen logo.

Version 2.201 beta, 06.04.1998

Added: 	functionality to specify an autoload *.qdw in the command line. Import questions from questionnaire function.

Version 2.20 beta, 31.03.1998

Improved and added: Functionality of "question - options" for automatic alignment, distribution, size change of answer fields (started briefly on 130398, completed on 310398) and automatic alignment of answer field labels relatively to answer fields. Added "Help" button. File format changed from 2.13 to 2.20, but automatic support for loading of files in older formats (2.13, so far) has been added. Improved handling of added answer fields when they exceed window border.

Corrected: 	Changing answer field options will no more move the corresponding label into a standard position below the answer field. Double entry "clear text" in a context menu removed.

Invented and added: 	Jörg's Magic Questionnaire-o-Matic :-).

Version 2.19 beta, 18.01.1998

Improved: 	Single printout: design improved, correct support of printers with other resolutions than 300 dpi added, missing printout of age corrected. Navigation window changed into a modal dialog, i.e., you cannot do anything else with AnyQuest for Windows while it is displayed, especially not mess with any items in a questionnaire being displayed behind the navigation window.

Version 2.18 beta, 03.10.1997

Added: 	Functionality to support translation of questionnaire definition files into other languages: ability to copy text from and to next/all/succeding one/all similar items and to/from private clipboard. Functionality to copy positions of objects, which alredy had included copy to clip, paste from clip, copy to prev, copy to next, copy to all, extended by copy to all prev, copy to all succ likewise.

Version 2.17 beta, 06.08.1997

Addresses of author updated. jsUnPack and Setup now collaborate in cleaning up files after automatic installations to avoid a Windows protection fault which occured in some environments.

Version 2.16 beta, 11.03.1997

Added: 	Patient ID collection configurable with possible collection of extended address data (not described in the help file yet). Improved dialogs for patient ID collection, including alphanumeric one. Texts from anyquin.msg are actually displayed in dialogs now.

Corrected: 	Uncertain recognition of pointer position within answer fields when using context menus corrected. AnyQuest Navigation Window: Button labels match help file description, and help buttons of sub-dialogs of the "Edit"-Menu work now. (Thanks to Chatchawan Silpakit!).

Version 2.15 beta, 28.12.1996

Added: 	Formula consistency check for CB-formulas across all loaded questionnaires.

Improved: 	Formula consistency check inactive for deletion of whole questionnaires. Formula consistency check code given better structure, effectiveness & reentrance-ability. Formula consistency check now works across all questionnaires loaded when a respective command is issued. Behaviour of CB- and result formula windows on deletion and adding of questions more logical (but still maybe not perfect). All (?) dialog boxes can now be controlled using the keyboard immediately. Softer reaction on expiration date, in English.

Corrected: 	CB-Formula definition dialog UPN and CB-destination string length limit to 10 characters removed. Go back button updates window-caption in edit mode when moving to another questionnaire.

Version 2.14 beta, 16.12.1996

Added: 	Conditional Branch support, including Check for completeness change. Demo Files for CBF. License owner is included in printout and file output. Questionnaire definition file copyright and history documentation.

Improved: 	CBFormulaDefinitionDialog behaviour when stepping through questionnaires. Outputs xage, xyears, errdirdatafolder, generate export file messages and other additional messages now translatable. Display of numeric result is now updated as well after all answers of a question have been unchecked. Numeric results of each question initialized as undefined after questionnaire loading and recomputed before each redraw. Algorithms for computation of numeric question results improved. Initialization routines on startup tidied up.

Corrected: 	Severe error not transferring questionnaire results which do not have a succeeding unit into export file already imminent in 2.1. Severe result computation error introduced to 2.13 removed again. Window caption in edit layout mode is set to correct questionnaire after start up. No more debris is saved to *.qdw-files with UPN formulas.

Changed: 	New *.qdw-file format.

Version 2.13 beta, 01.12.1996

Added: 	More UPN-functions for binary logic, comparisons and stack manipulation.

Improved: 	After startup, first question of first auto-loaded questionnaire is displayed. Variable definitions and procedures for other object support. File header support. Conditional branch formula definition. Small improvements in dump tree function.

Version 2.12 beta, 30.11.1996

First post-pre-release version.

Improved: 	When a question is deleted, the display will not switch to the preceeding question any more if at least one succeeding question is there. Default settings of some options with missing *.ini-file are now more convenient. International translation file now contains almost all messages.

Added: 	Consistency check for formulas referencing questions when questions are deleted or added. Registration and Author's Adress in help menu.

Changed: 	Shareware license, About, Formula definition, Printer setup, Data dir selection, Export dialogs (Context sensitive help added et al.). Formula edit dialog displays formula numbers locally to current questionnaire.

Version 2.11 beta, 29.11.1996

Improved: 	jsUnPack and Setup remove temporarily unpacked files after unpacking followed by automatic installation.

Version 2.1 beta, 02.10.1996

Added: 	"AnyQuest Navigation"-Window.

Improved: 	Automatic scaling of answer field default radius and distance.

Version 2.0 beta, 25.09.1996

Added: 	Supports special answer fields for "Can't answer" / "Don't want to answer". Supports fields for input of additional text information which open up when answer fields are checked, and output of additional text information into a new section of *.anq files. Supports answer fields in different sizes in a single question. Separate text format for special answer field labels (Can't/Don't want). Supports "Jörg M. Sigle's multi-segmented non-linear Visual Analogue Scales".

Improved: 	Improved handling of added answer fields. Correct removal of extreme LASA/VAS checks, when a new point is checked. Correct handling of LASA/VAS-questions which don't start at 0.00. Generate export file: Corrected handling of name and delta time. No erroneous decimal character replacement in dates any more. Sorting of all found labels from all files according to file-section and original label order. Improved text input fields.

Version 1.9 beta, 13.09.1996

Changed: 	Single debug menu options removed from "navigation" menu.

Corrected: 	"Generate demo" corrected.

Added: 	Installation program provided to install from compressed disk files.

Version 1.8 beta, 09.09.1996

Improved: 	More robust handling of patient date of birth input. Button "Next Question" re-labelled to "Continue...". Improved memory management and data protection. PC-Speaker sound timings have been improved with respect to machine speed independence.

Corrected: 	Corrected printing font size. Corrected malfunction of "File Load"- and "File Save"-dialogs under Windows NT 3.xx.

Version 1.7 beta, 22.08.1996

Added: 	support for different display resolutions. Enhanced *.QDW file format.

Version 1.6 beta, 28.07.1996

First version given to selected people for evaluation.

Historic predecessors: AnyQuest for DOS, GraTaSim, extract and others

AnyQuest for Windows has been developed when Pen-Computers (similar to what has been termed "Tablet-PCs" in recent years) with colour displays had become available, namely the Fujitsu Stylistic ST-1000.

It is based upon AnyQuest for DOS, which had been developed and successfully used since ca. 1993. Initial versions of the software could only handle one questionnaire, beginning with the EORTC QLQ-C30 or QLQ-C30+3, but multiple questionnaire and configuration files support had been added very early.

These early implementations of the concept of the Quality-of-Life recorder all accepted input from a  digitizer (graphic tablet) and a TSR (terminate and stay resident) software (GraTaSim), freely programmable by means of a corresponding CAD environment (GraTaGen, GraTaPrn etc.) to implement a user interface that could easily be handled even by elderly or ill patients without any training.

The general principles of operation as well as the result file format and postprocessing tools originally used by AnyQuest for DOS are still compatible with the modern environment.

Please visit http://www.jsigle.com/prog and http://www.ql-recorder.com for further information!


About this documentation

This documentation informs you about the purpose and the functions of the software package you are looking at. It shows you how to use it to design and edit electronic questionnaires, how to use these questionnaires and what results are produced.

The contained information is structured to fit different people's needs from beginners towards experts.

Included are some Step-By-Step-Guides for both presenting and creating questionnaires. You may, but you shouldn't try to use this software without having had a look at them.

It contains a comprehensive index that helps you find information on a given topic.

You can find out what's new in this version by reading the document and product history.

Enjoy!


Overview

Any Quest is a software package which provides means to allow people untrained in computer use to fill in electronic questionnaires. Typically it may be used to present quality-of-life questionnaires to patients.

AnyQuest for Windows is a descendant of AnyQuest Version 2.21 for MS-DOS, which is part of the Quality-of-Life-Recorder developed by Jörg M. Sigle at the Cancer Centre of the University of Ulm, Germany.

Through its range of supported input-devices, AnyQuest for Windows allows the use of the most economic (trackballs, certain touch-screens) as well as the most advanced (Pen-computers and multi-media) hardware platforms.

AnyQuest for Windows is specialized in handling questionnaires - and it comes with integrated tools which make it easy to transfer any of your questionnaires into an electronic version.

AnyQuest could provide means to achieve standardized data acquisition and exchangeable data storage in any further study or application throughout the world.

Several customer specific or specialized applications and extensions have been prepared based upon AnyQuest for Windows.

Some of these include simplified applications that offer menu commands for questionnaire presentation and configuration only; all editing commands have been removed.


Supported operating systems

AnyQuest for Windows was designed under Microsoft Windows 95.

It has been successfully used under:

Windows 3.1,

Windows 95,

Windows 98,

Windows NT 3.51,

Windows NT 4.00,

Windows 2000,

Windows 2003 (on a Chinese system including basic Chinese character support),

Windows XP,

Windows Vista 32-Bit,

Linux with X11, KDE and Wine on an Intel based PC, including touch-screen support,

Linux with X11, KDE and VMware on an Intel based PC,

SoftWindows for IRIX 6.5 on an SGI Octane.

It should run under IBM OS/2 as well, under SoftWindows or SoftWindows 95 on an Apple Macintosh or PowerMac, and on more modern emulators for iMacs etc. (BOCHS, VMware, Parallels...) of course.

A PDF-generator or the MS Journal Writer as virtual printers are supported.

Operation with multiple clients over a network is supported.

Several possibilities for connections to databases or practice management software or tumor registry software as backends are supported.

If you want to collect questionnaire data from patients, and you don't have computers running one of the above mentioned operating systems, you can use the original Quality-of-Life-Recorder using GraTaSim, which only requires a 80286 procesor and MS-DOS 3.3.

(Please note, 2008: I came across a PC emulation via BOCHS in Java for the Nokia/Symbian 60 platform. Well... probably not the most efficient environment, and it ran very slow. But it worked - and this means, we may expect PC emulations including MS Windows 3.x on mobile phones, and as soon as their displays become reasonably sized, AnyQuest should be able to run on something like this (or whatever runs Java and has a usable display, like a Windows CE box) without any other prerequisites. On the other hand, if you can and want to support the continuation of the native AnyQuest for Java (player) development, please do not hesitate to contact me.)

(The above text lists some trademarks ® without further notification - they are the properties of their various owners.)


Supported hardware

AnyQuest for Windows was designed to be used with a variety of man-machine-interface-hardware. It supports input using the common mouse, trackball, touch screen, digitizing-tablet and especially the stylus of a pen-computer. The final version will support keyboard input and the original Quality-of-Life-Recorder's digitizing-tablet with its graphical templates through GraTaSim for Windows.

You can use barcode readers to scan patient identification data - and you can integrate AnyQuest for Windows into an existing IT environment to complete a small scanned ID with information taken from a database.

AnyQuest for Windows supports the association of digitized sound files (Wave-files) with many objects within a questionnaire and with certain events. This means, that using any standard soundcard, you can implement a questionnaire that is read aloud to the patient. Wave-files are standard Windows soundfiles. They can easily be recorded and manipulated, so there are hardly any limits to your creativity! · Using speaker.drv, a Windows driver available from Microsoft, Wave-files can also be played via the usual PC-speaker in limited quality.

AnyQuest for Windows supports printouts on printers or similar output devices which support printing graphics. This includes fax-modems, so you can actually fax your printouts directly to another place.

Using wireless networking systems and a pen-computer, AnyQuest for Windows can serve as a completely mobile data capturing unit with direct storage of the data in a hospital computer network.

AnyQuest for Windows is a graphically designed program that uses rather complex memory access. This means that although you can run it on PCs beginning from 80386sx, it makes more sense to use 486 based machines.

If you plan to give it to a patient, take care of selecting a clearly visible display with high contrast. In laptop or pen-computers, an active matrix TFT-display would of course be nice. AnyQuest for Windows supports colours and displays with different resolutions.

Since November, 1998, the Palmax PD-1000, a mini-notebook with 6,1" TFT-display and integrated touch-screen is available in Germany for about DM 2.000,- .. 3.000,-, depending on its configuration. To people with sufficient budgets, I might suggest to use the pen-computers Fujitsu Stylistic 1000, Fujitsu Stylistic 1200 or EPSON EHT 400 C. In contrast to the pen-based organizers you might have seen, these operate on fast 486 CPUs and have reasonable colour displays. Enjoy AnyQuest for Windows on these 20th century drawing slates - and thereby join the avantguarde...

Update, 2008: It still runs and looks very nice on Fujitsu-Siemens Stylistic ST5010, ST5020 etc. machines. They are still "avantguarde" items, but more "Tablet-PCs" and "Convertibles" in price ranges from about 700 EUR to 2.000 EUR and with a multitude of screen sizes are available from a variety of hardware vendors. There are some links to sources of hardware and additional information on my WWW site, http://www.ql-recorder.com.


Display resolutions

Support of different display resolutions

AnyQuest for Windows was designed to support displays with different resolutions.

Pen-computers and most laptop computers currently available offer a display resolution of 640 x 480 pixels. However, some modern laptops and many desktop computers offer higher display resolutions of up to 1600 x 1200 pixels.

To take advantage of these machines' capabilities, AnyQuest for Windows scales each electronic questionnaire to fit the display of the machine on which it is loaded. Theoretically, you can edit an electronic questionnaire on any PC with any display resolution available, and use it on any other machine with any other display resolution without any further considerations.

However, in reality I observed small variations among different Windows display drivers. As a result, the display of text may vary slightly between different machines. Primarily, this might affect the spacing of characters, and consecutively, line-breaking within text boxes. Occasionally, an unexpected, very small gain in length of a text may result in a word broken to the next line - and if the space provided for this text has no additional line, that word (or a succeeding line) may be hidden completely.

This may happen more often when you use the automatic resizing of text boxes to perfectly fit the contained text. Problems can be avoided by disabling this feature (after having used it to get the currect number of pixels in y-direction, to achieve automatic alignment in y-direction), and providing at least some extra space in x-direction for all text boxes.

If you use AnyQuest under Wine in an Linux/X-Windows environment, it will be advantageous to use TrueType fonts made available via a TrueType font-server. They are available for free.

To avoid any unfavourable surprises, please check how your electronic questionnaires are displayed on a given machine before you present them to patients!

Update, 2008:

Please note: The built in "Analysis tools" dialog requires at least 800x600 pixels screen resolution; and the Fast-Input-Form dialog requires about 1024x768 pixels screen resolution.

Operating systems like Windows XP and Windows Vista will also contain configuration dialogs that may exceed 640x480 displays.

Nevertheless, if you need to use a small system for administering questionnaires in AnyQuest's normal, patient oriented mode, this is perfectly feasible even on 640x480 displays.

When designing and deploying questionnaires on systems with different screen geometries, answer fields may appear dysproportionally squashed or streched, and text scaling may result in texts exceeding their reserved space.


Linux, X-Windows, Unix

AnyQuest for Windows and Linux

AnyQuest for Windows can run under the Linux operating system. :-)

This gives you the advantage of an environment that is said to offer better stability and security than various MS Windows environments.

I have tested it first under Caldera Open Linux 1.3, Linux Kernel 2.0.35, X-Free 3.3.3.1, KDE 1.0 and Wine from May, 1999 on my Intel Pentium II 350 MHz.

Directories and drives were supported without any problems. File/Directory selection dialogs are even better than in Windows, as the 16-bit application can show long filenames under Wine. Speed is no problem either. However, with that version of Wine, printing did not work and without a TrueType font server, texts within *.qdw files appeared using different fonts in different sizes from those used under Windows. Moreover, large font sizes appeared with huge pixels.

On a later system, I've tested AnyQuest under Wine with a TTF font-server that can provide the fonts used under MS Windows to X-Windows applications. If you adjust Wine and your X-Server to the correct resolution (maybe you have to try several settings), this works fine. Under recent versions of Wine, printing also works.

If you cannot install or do not want to use a TTF font-server, another alternative is to design your *.qdw files in Wine, choosing reasonable fonts of your X11 environment.

I even found an X-Server especially tailored to support the stylus (touch-screen) of the Palmax PD-1000 pen-computer. There are, by the way, excellent pages in the WWW covering laptop and PD-1000 use under Linux.

Most of the recent AnyQuest for Windows development, by the way, has been done on an MS Windows environment that runs within VMware under Linux, and under such an environment, of course, AnyQuest runs without any difficulties.


Pixel

What is a "pixel"?

Common computer screens usually display a picture which is made up from hundred-thousands of single dots of different colours. Each of these dots is a "picture element" - a so-called "pixel".

With more and finer pixels, the images a computer can display can be defined into greater detail. However, more pixels require more display memory and faster hardware.


Functionality of AnyQuest for Windows

AnyQuest for Windows includes, among other components, a questionnaire editor as well as an interpreter.

The editor allows any user to take a paper questionnaire to the computer with little effort. Text and answering fields can be manipulated on the screen. The results can be tested immediately. Easily, it should let you prepare a nice looking electronic version of a questionnaire with 30 questions in an afternoon.

In questionnaire application centered packages like the eIBSQOL, the editor may be deactivated to keep the structure of the menu system and handling of the package more simple.

The interpreter presents questionnaires to a patient and guides him through answering the questions. It checks answers for completeness, computes results, stores them in files and generates printed output. It can be put into an unattended endless "kiosk" mode, which means, that one patient after another can complete the questionnaire not requiring staff interaction. Multiple questionnaires can be used in a single session. Questions can offer different types of answers:

•	Visual Analogue Scales (VAS) = Linear Analogue Self Assessment Scales (LASA)

•	discrete answers with a single selection

•	discrete answers with multiple selections

•	answers with direct input windows for text, time, date and numeric data

Every answer field supports options to allow patients to check "I can't answer this question" and "I don't want to answer this question". With any checked answer, AnyQuest can prompt for additional unformatted text information.

Conditionally asked questions are supported now through Conditional Branch Formulas.

AnyQuest can immediately compute results according to formulas specified in UPN (Reverse Polish Notation). It supports many mathematical functions. Missing answers can be allowed and then handled correctly, while the treshold level for generating a "missing value"-result can be specified independently for each result formula. (Which means, you're able to follow e.g. the EORTC QLQ-C30 manual's directions).

Configurable output characteristics include different result labels and formatting for file storage and print and bargraph generation. Both single and cumulative printing possibilities are included in this release, which means that you can get good-looking printouts on any of your Windows printers or faxes. From version 2.26 on, cumulative printout is available, featuring the display of results of all recent assessments of a given patient. Reference values from files or from basic statistical evaluations of locally collected data can be included in the output.

Integrated analysis tools are there which can generate deferred printouts, allow to select individual measurements or groups of measurements based upon versatile criteria, and to generate several statistical analyses, including simple explorative statistics, box-and-whiskers-plots and a course-over-time-plot. Their output can be redirected to the printer, the screen, or to files for direct use in publications.

For advanced analysis using external statistical software, comfortable data export functions exist. These can export data even when you don't know which questionnaires were used to collect them. This may be really helpful when you plan to do a meta-analysis of data collected several years before by colleagues who have all moved to different areas of interest. Or to different data base systems.

There are also neat possibilities for integration into existing environments: AnyQuest for Windows can call external applications for collection, verification or completion of patient identification data, notify them after a result file has been written, or call external software to assist during result computations. Actually, whereever a formula can be used within AnyQuest, including both result formulas and conditional branching formulas which among other things control interactive questionnaire presentation, external software (including software communicating with database applications, over a LAN or over the Internet) can be called and communicated with. All communication with AnyQuest involves pure and simple ASCII text files. Solutions are already available to forward collected data automatically into SQL databases, also including a prototype of a dynamic WWW/HTML frontend for collected data, or to integrate AnyQuest for Windows seamlessly with existing practice management software or hospital systems using the readily available GDT/LDT or HL7 interfaces. And of course, it works with a barcode reader or RFID reader to acquire patient ID or case ID etc. without typing.

If you wonder, whether you can use the Quality-of-Life-Recorder to present a really large set of questionnaires, the following figures may comfort you: AnyQuest for Windows can load into its memory at the same time (and, theoretically, present to a very poor victim in a single session) 16383 questionnaires, 16383 result formulas, 16383 questions, 16383 answer fields and 16383 additional objects like CBFs or images. Theoretically you can attach about 3,5 hrs. CD-quality sound recordings to each text-item or event. Theoretically, you can collect an unlimited number of data files from quality-of-life assessments. However, your storage devices might keep the practical limits lower.

Remembering the avantguarde thing? Well, if you use a suitable pen-computer, patients can (if they want to) actually hand-write their name and date of birth into the respective input fields. Additionally, AnyQuest supports taking hand-written notes to any question - which is especially useful for questions a patient could not or did not want to answer.


Basic handling concepts

AnyQuest for Windows is designed to be operated preferring the pointing device over the keyboard. It is especially simple to be used on a pen-computer. As it supports any pointing device which runs with Windows, you can obviously use it on any hardware your taste and your budget provide.

During questionnaire design, both buttons of the pointing device are essential, with the second button often bringing up context menus for the objects pointed at.

During questionnaire completion, only the primary button of the pointing device is required - which means, it can be replaced by the patient's finger-tip on suitable hardware.

If you use direct text input fields or additional text input fields, patients can use the keyboard for typing or even use a pen for writing, if your computer supports this.

If you want to move around between some answer fields using the keyboard, you can use the tab-key to move forward and the shift-key and tab-key together to move backwards. This also works to go to the next or to the previous question, even if the transport bar is not activated. In this case, the space-bar checks or unchecks the answer field below the cursor.


Additional text input

Collection of additional text information

In some cases, you might want to ask a patient for an explanation of an answer he has given. For example, if a patient chooses an answer field labelled "I don't want to answer this question", you might wish to know why.

Usually, the interviewer or clinical data manager would have to ask the patient and take notes.

However, in AnyQuest for Windows, you can enable an option for each individual answer field, which will cause an additional text input field to appear, when the answer field is checked. Depending on other attributes of the answer field, this input field asks for further information in general, or specifically for the reason why a patient can not or does not want to answer the question.

Information can either be written into the text input field using the keyboard, or it can be hand-written using the stylus of a pen-computer.

For this special purpose, I did not supply buttons with all characters of the alphabet, because in my opinion, this task is specialized enough to justify either the use of a pen-computer, which may recognize a patient's handwriting, or the assistance of a clinical data manager, who can enter the information via a keyboard. However, if users should request it, I can change this detail and supply buttons with alphabetical characters.

One text input field can hold up to 32383 characters since AnyQuest version 2.26.

The text which is entered here, appears in a seperate section of the output file. It is arranged in a special column when an export file including raw data is generated.

This feature of AnyQuest for Windows can be enabled or disabled for all loaded questionnaires through the "Display"-menu.

• Direct Text Input

• Answer field options


Direct text input

Direct collection of numerical or text information

Sometimes you will find checkable answer fields not convenient to collect the data you like. This will happen, if you wish to collect texts, very variable numbers, dates or times.

To accomodate for this, you can give answer fields the property "Direct text entry" in the "answer field options" window.

If you give such a field a background bitmap, it will appear as a frame. You can also select the font for text in direct input fields.

Information can either be written into the input field using the keyboard, or it can be hand-written using the stylus of a pen-computer.

If you want to move around between some answer fields, you can use the tab-key to move forward and the shift-key and tab-key together to move backwards.

For this special purpose, I did not supply buttons with all characters of the alphabet, because in my opinion, this task is specialized enough to justify either the use of a pen-computer, which may recognize a patient's handwriting, or the assistance of a clinical data manager, who can enter the information via a keyboard. However, if users should request it, I can change this detail and supply buttons with alphabetical characters.

One text input field can hold up to 32383 characters since AnyQuest version 2.26, but if the scrolling options are disabled, character input is limited by the layouted size of the field and the size of the used font.

The text which is entered here, appears in a seperate section of the output file. It is arranged in a special column when an export file including raw data is generated.

• Addidional Text Input

• Answer field options


Answer field options

Selecting "Options..." from the context menu of each answer field, you can open a the "Answer field properties..."-dialog box to change the following:

Answer field type

An answer field can be of one of the following types:

•	"Regular": this is the typical answer field which is either checked or unchecked, and which codes into a numerical or text value if checked.

•	"Special": this is similar to "Regular", but intended to code either for "I can't answer this question" or for "I don't want to answer this question".

•	"Direct text entry": this field appears as an area, where the patient can enter and edit free text information.

In contrast to a regular answer field, those of the types "Can't answer" field and "Don't want to answer" field behave differently:

•	They can be enabled or disabled for all loaded questionnaires through the "Display"-menu.

•	Font and colour of their labels can be changed seperately from those of regular answer fields.

•	When checked, previous checks are removed from all other fields of the same question.

•	They return the numeric value "Missing value".

•	In the section [raw data] of the output file, the strings "¬Can" or "¬Want" are added to the missing value code, respectively.

•	They are not aligned automaticaly, when the button "Apply" is clicked in the "Question properties..."-dialog box.

The checkbox "Show a text input field on check" controls the collection of additional text information. for regular and special answer fields.

This functionality can be enabled or disabled for all loaded questionnaires through the "Display"-menu, too.

If the checkbox "Clear all other fields on check" is checked, the answer field becomes a special one and cannot be checked together with others in the same question, even if the question type would allow that. As soon as such an answer field is checked, all other answer fields are unchecked and their respective additional text information is cleared. The other way round, if any other answer field is checked, the special answer field will be cleared itself. This feature is useful if you want to design questions with multiple answers which can be checked together, and one special answer like "none at all".

Direct text answer fields are useful to collect text, numerical values, dates, times through directly editable fields. The checkboxes right to "Direct text entry" are used to control the scrolling behaviour of direct text entry answer fields.

Answer field size

This field can be used to set the relative size of an answer field with respect to the default size specified in the "Question properties..."-dialog box. It may be especially helpful to construct smaller answer fields for "Can't answer" and "Don't want to answer".

Beyond the answer field options dialog

Position, size, value, text, background image, sound file etc. of answer fields and their labels can also be copied, pasted, or otherwise modified through entries in the context menu of these objects, or using keyboard shortcut commands.

Automatic arrangement or distribution of multiple answer fields is controlled through the "Question" - "Options" dialog; and text search- and replace options are available from the main menu via the "General editing tools" dialog.

• Direct Text Input

• Addidional Text Input


Data compression

To be able to store more data on a single storage device, or to increase throughput in data exchange through networks or telephone lines, data can be compressed.

Compression does not imply loss of quality or data reduction, because (in a simplified explanation) it uses mathematical algorithms to find regular patterns in data. Information about these patterns can be stored in a more compact way than the original data.

Compressed files can either reside inside a single big archive file (which often has an extension like *.arj, *.zip, *.lze, *.tar, *.arc, *.zoo, *.cab) or they can still be stored individually. Some of them can be recognized, because they have an underscore "_" as the last character of their file name extension, e.g. anyquin.ex_.

Before you can use a compressed file, you will have to decompress it. For this purpose, there are decompression programs available: arj.exe, pkunzip, untar, expand, extract...

Some archives, however, contain their own decompression software - they have the extension *.exe and you don't need any tools to unpack them.

If you downloaded AnyQuest for Windows from a WWW or FTP site, you probably received the self extracting archive file anypak.exe.

If you received AnyQuest for Windows on a single floppy disk, it is likely that you received compressed files. However, they are uncompressed automatically by the installation program setup.exe which is located in the root directory of the floppy disk.


Installing the program

Installing AnyQuest for Windows

Generally, "installing AnyQuest" means: Placing the software into its own directory on a harddisk and creating some links pointing to it from the Windows 3.x program manager or from the Start menu of the Windows 95 Explorer.

By default, AnyQuest for Windows is installed into the directory c:\anyquin and some subdirectories.

The steps you have to follow, depend on what you have and what you want to do:

•	If you have the self extracting archive file demopak.exe, please follow the instructions in the accompanying file readme.txt.

•	If you have the compressed archive file demopak.zip, you have to extract it using an unzipping program (e.g. WinZip, PKunzip, CleverZip) to get demopak.exe.

•	If you have the self extracting archive file anypak.exe...

•	If you have compressed files and the setup program setup.exe...

•	If you do not have the setup program...

•	If you don't have a soundcard and want to install speaker.drv....

•	If you received a package coming with 8 Bit sound files and want to install 16 Bit files...

Whatever you do, it might be wise to preserve some logically structured directory tree under c:\anyquin, seperating sounds, questionnaires and data, but you don't need to if you don't want to.

AnyQuest for Windows can support multiple configurations, including coexisting configurations for multiple languages and secured configurations.


Installing the program from anypak.exe

Installing AnyQuest for Windows

If you have the self extracting archive file anypak.exe...

Just running the program anypak.exe unpacks its contents and gives you the option to run setup automatically.

To do this, just...

•	create or locate an empty directory on your harddisk.

•	move anypak.exe into this directory.

•	run anypak.exe.

Alternatively, you can...

•	run it directly from a floppy disk, if you should have received it on a floppy.

If you want to run run anypak.exe from a directory which has too little space to extract its contents, you need to have defined an environment variable TEMP=(temporary directory with enough space).

After the setup has been completed, the setup utility should remove the files that were extracted from anypak.exe again, if it was started directly from anypak.exe.

I have found that on some systems, this may cause an error. However, the setup will still have worked correctly and the installed software will work.


Installing the program from compressed files

Installing AnyQuest for Windows

If you have compressed files *.??_ and the setup program setup.exe

You can setup AnyQuest for Windows automatically. To do this, just...

•	...make sure that all files you received are in one directory.

•	...run setup.exe.


Installing the program without setup.exe

Installing AnyQuest for Windows

If you do not have the setup program...

In this case, please contact me to get a complete package.

Although you can arrange all files manually, I would prefer to have the same directory structure and the newest version running at all users' places.


Installing speaker.drv

Installing AnyQuest for Windows

If you don't have a soundcard and if you want to install speaker.drv....

For Windows 3.x:

•	Locate the file speak.exe which you should have received with your copy of AnyQuest for Windows.

•	It is a self extracting archive. Run it to extract its contents.

•	Using the program manager, issue the following commands: "File" - "Run" - "control.exe" - "OK".

•	In the system control window, issue the followin commands: "Drivers" - "Add" - "not listed.../disk" - "(enter the path to speak.exe here)" - "OK".

•	That's it.

For Windows 95, please contact me to receive instructions.


Installing 16-Bit sound files

Installing AnyQuest for Windows

If you received a package coming with 8 Bit sound files and want to install 16 Bit files...

You may receive these files on a seperate disk or with a separate download file.

Be sure to replace every 8 Bit file in c:\anyquin and all subdirectories with its corresponding 16 Bit version.


Starting the program

Starting AnyQuest for Windows

If you installed the simple example package anypak.exe or another package with pre-defined configurations

AnyQuest for Windows can support multiple configurations.

If you have MS Windows 3.x or MS Windows NT 3.x, the automatic installation routine may have generated a program group "AnyQuest for Windows" which you can locate in the program manager and then open.

If you have MS Windows 95 or newer, or MS Windows NT 4.0, or any more recent version of MS Windows, the automatic installation routine should have installed AnyQuest for Windows and its help file in your "Start" menu. In more recent versions of Windows, you may have to look for it under "All programs...".

In either environment, you will find quite a number of thematically sorted pre-supplied configurations with different patient questionnaires in different languages in this program group / submenu.

A few entries are special:

•	"AnyQuery for Windows" is a very small tool to view the content of result files in a graphical display. It is currently not maintained and provided as is.

•	"AnyQuest for Windows Help" opens the on-line help you are currently reading. (Users of MS Windwos Vista may have to download and install a the winhelp.exe viewer for Windows help files in the original format, which Microsoft may not have included in the default installation any more.)

•	"AnyQuest for Windows (without any details)" is a configuration that uses the default configuration file. It is equivalent to starting the program directly as described below.

•	"AnyQuest for Windows - Your Own" is a placeholder configuration provided which you can change to your own specific needs very easily.

For now, select either the default configuration, or "Your Own", or any one offering a patient questionnaire you're specifically interested in.

If you received the eIBSQOL or another specially prepared package, you'll find corresponding pre-configured setups for different languages. All can be accessed via your Start-menu or your program-manager directly by double-clicking the respective icon.

If you have not installed the simple example package, or your "Start" menu does not work as expected, or for special purposes

You may start the main program (using any configuration file currently in the default position, or creating a new one) by just double-click anyquin.exe (probably in c:\anyquin) to start AnyQuest for Windows.

After the program has been started

A title screen and, in an unregistered copy, some shareware dialogs with information about the program and its shareware status will appear. Please read it carefully and close each dialog by clicking on "Ok" or "Continue...".

Finally, the "navigation dialog" will appear. Depending upon the configuration you used, it may offer a number of buttons, or only one "Start!" button.

If you don't have a valid language file (default: c:\anyquin\anyquin.msg or configuration specific *.msg), some general dialogs may appear in German.


Language specific *.ini file example overriding system default fonts

Example of sections from a language specific *.ini file

The following entries in the example file en.ini advise AnyQuest for Windows to load translated messages from en.msg and to load the questionnaire definition files introen.qdw and qnren.qdw:

[General]

OverridingMsgFile=C:\ANYQUIN\EN.MSG

[LoadedQuestionnaires]

NumberOfLoadedQNs=2

LoadedQNFilename1=C:\ANYQUIN\QUESTNS\INTROEN.QDW

LoadedQNFilename2=C:\ANYQUIN\QUESTNS\QNREN.QDW

While the other entries shown above are automatically written according to the current configuration by AnyQuest for Windows when it closes, the section header [General] and its entry OverridingMsgFile are not produced automatically yet (as of Version 2.32).

Since version 2.82, the following entries may be added to set the date format for dialogs and printouts: Setting each parameter to 0 or leaving it undefined selects the default format of DD.MM.YYYY for display or printing and acceptance of all similarly arranged formats for input. Setting it to 1 selects the alternative format of YYYY-MM-DD for display or printing and acceptance of all similarly arranged formats for input. The format used in *.anq files will remain as DD.MM.YYYY in any case.

[Options]

DateFormatDialog=1

DateFormatPrint=1

The following entries in the example file gr.ini specify (Greek) fonts and character sets which AnyQuest for Windows should use for several items which are displayed on screen:

[Fonts]

Greek_PID_collection_and_printouts=True

font_for_message_window_message.lfFaceName=Arial

font_for_message_window_message.lfCharSet=161

font_for_message_window_message.lfHeight=0

font_for_message_window_message.lfWidth=0

font_for_message_window_message.lfEscapement=0

font_for_message_window_message.lfOrientation=0

font_for_message_window_message.lfWeight=0

font_for_message_window_message.lfItalic=0

font_for_message_window_message.lfUnderline=0

font_for_message_window_message.lfStrikeOut=0

font_for_message_window_message.lfOutPrecision=0

font_for_message_window_message.lfClipPrecision=0

font_for_message_window_message.lfQuality=0

font_for_message_window_message.lfPitchAndFamily=0

font_for_texteingabe_window_message.lfFaceName=Arial

font_for_texteingabe_window_message.lfCharSet=161

font_for_texteingabe_window_message.lfHeight=0

font_for_texteingabe_window_message.lfWidth=0

font_for_texteingabe_window_message.lfEscapement=0

font_for_texteingabe_window_message.lfOrientation=0

font_for_texteingabe_window_message.lfWeight=0

font_for_texteingabe_window_message.lfItalic=0

font_for_texteingabe_window_message.lfUnderline=0

font_for_texteingabe_window_message.lfStrikeOut=0

font_for_texteingabe_window_message.lfOutPrecision=0

font_for_texteingabe_window_message.lfClipPrecision=0

font_for_texteingabe_window_message.lfQuality=0

font_for_texteingabe_window_message.lfPitchAndFamily=0

font_for_texteingabe_window_editarea.lfFaceName=Arial

font_for_texteingabe_window_editarea.lfCharSet=161

font_for_texteingabe_window_editarea.lfHeight=0

font_for_texteingabe_window_editarea.lfWidth=0

font_for_texteingabe_window_editarea.lfEscapement=0

font_for_texteingabe_window_editarea.lfOrientation=0

font_for_texteingabe_window_editarea.lfWeight=0

font_for_texteingabe_window_editarea.lfItalic=0

font_for_texteingabe_window_editarea.lfUnderline=0

font_for_texteingabe_window_editarea.lfStrikeOut=0

font_for_texteingabe_window_editarea.lfOutPrecision=0

font_for_texteingabe_window_editarea.lfClipPrecision=0

font_for_texteingabe_window_editarea.lfQuality=0

font_for_texteingabe_window_editarea.lfPitchAndFamily=0

font_for_result_formula_printout_label_editarea.lfFaceName=Arial

font_for_result_formula_printout_label_editarea.lfCharSet=161

font_for_result_formula_printout_label_editarea.lfHeight=0

font_for_result_formula_printout_label_editarea.lfWidth=0

font_for_result_formula_printout_label_editarea.lfEscapement=0

font_for_result_formula_printout_label_editarea.lfOrientation=0

font_for_result_formula_printout_label_editarea.lfWeight=0

font_for_result_formula_printout_label_editarea.lfItalic=0

font_for_result_formula_printout_label_editarea.lfUnderline=0

font_for_result_formula_printout_label_editarea.lfStrikeOut=0

font_for_result_formula_printout_label_editarea.lfOutPrecision=0

font_for_result_formula_printout_label_editarea.lfClipPrecision=0

font_for_result_formula_printout_label_editarea.lfQuality=0

font_for_result_formula_printout_label_editarea.lfPitchAndFamily=0

font_for_PID_screens_Greek.lfFaceName=Arial

font_for_PID_screens_Greek.lfCharSet=161

font_for_PID_screens_Greek.lfHeight=30

font_for_PID_screens_Greek.lfWeight=800

font_for_PID_screens_Greek.lfWidth=0

font_for_PID_screens_Greek.lfEscapement=0

font_for_PID_screens_Greek.lfOrientation=0

font_for_PID_screens_Greek.lfItalic=0

font_for_PID_screens_Greek.lfUnderline=0

font_for_PID_screens_Greek.lfStrikeOut=0

font_for_PID_screens_Greek.lfOutPrecision=0

font_for_PID_screens_Greek.lfClipPrecision=0

font_for_PID_screens_Greek.lfQuality=0

font_for_PID_screens_Greek.lfPitchAndFamily=0

font_for_PID_screens.lfFaceName=Arial

font_for_PID_screens.lfCharSet=0

font_for_PID_screens.lfHeight=30

font_for_PID_screens.lfWeight=800

font_for_PID_screens.lfWidth=0

font_for_PID_screens.lfEscapement=0

font_for_PID_screens.lfOrientation=0

font_for_PID_screens.lfItalic=0

font_for_PID_screens.lfUnderline=0

font_for_PID_screens.lfStrikeOut=0

font_for_PID_screens.lfOutPrecision=0

font_for_PID_screens.lfClipPrecision=0

font_for_PID_screens.lfQuality=0

font_for_PID_screens.lfPitchAndFamily=0

font_for_continue_button.lfFaceName=Arial

font_for_continue_button.lfCharSet=161

font_for_continue_button.lfHeight=0

font_for_continue_button.lfWeight=0

font_for_continue_button.lfWidth=0

font_for_continue_button.lfEscapement=0

font_for_continue_button.lfOrientation=0

font_for_continue_button.lfItalic=0

font_for_continue_button.lfUnderline=0

font_for_continue_button.lfStrikeOut=0

font_for_continue_button.lfOutPrecision=0

font_for_continue_button.lfClipPrecision=0

font_for_continue_button.lfQuality=0

font_for_continue_button.lfPitchAndFamily=0

The first shown option activates the use of Greek variants for the patient identification collection screens and of the Greek character set 161 for generation of printouts.

All other options define fonts which will be used in the referenced items within the program. If these fonts are specified, AnyQuest will use them instead of the default fonts. You need to specify only parameters which you want to have specifically changed; when the *.ini file is written from AnyQuest the next time, it will write out default values for all other parameters of the respective font definition. If you want to use the default font for an item again, please remove all corresponding entries for that item from the font section. If you want to create a set of configurations for both Greek and other languages, you can define fonts for the non-Greek PID screens, and for other items in the non-Greek initialization files, too, to achieve a consistent layout of your questionnaire environment for all languages.

Please note: Currently (Version 2.39), AnyQuest does not scale specified font sizes for these items.

You can edit the *.ini file with any text-editor (e.g. notepad.exe).

• Multiple configurations

• Preparing a secure configuration


Secure configuration *.ini file options

Options in the *.ini file to harden a configuration

The following entries in the configuration file anyquin.ini (or any *.ini that you use) can be used to make a predefined AnyQuest for Windows configuration more secure against undesired use of the program. Most of the configurations prepared in my self-installing packages have some of the security options set in order to protect themselves against accidental changes.

You can edit the *.ini file with any text-editor (e.g. notepad.exe).

The first of the following options only disables all menu options used to edit questionnaires, and the second one disables all menu options to load or save a questionnaire and thereby to change the set of loaded questionnaires within a configuration. The second option automatically includes the first one.

[Options]

DisableEditMenus=True

DisableLoadSaveMenus=True

The following option changes AnyQuest's behaviour in the "Setup" mode: When it is true (the default setting since Version 2.44), clicking to somewhere else than the menus in "Setup" mode, or trying to flip through the loaded questionnaire(s) will directly show the "Navigation" window again.

[Options]

DisablePlayInSetupMode=True

Each of the following options can be used to disable a specific button from the "AnyQuest Navigation" window. Disabled buttons are displayed in a gray style and cannot be clicked or selected anymore. When the Exit button is disabled, AnyQuest cannot be closed anymore, i.e. the exit via Alt-F4 is also locked, and if the program shall be terminated, this must be done either by logout, system shut down, or using the task-manager (available via Ctrl-Alt-Del or Str-Alt-Enf).

[Options]

DisableNaviSetupButton=True

DisableNaviHelpButton=True

DisableNaviExitButton=True

Since version 2.92, the following option replaces all four buttons on the standard navigation dialog with only one button labelled "Start". As a side effect, AnyQuest cannot be closed anymore, i.e. the exit via Alt-F4 is also locked, and if the program shall be terminated, this must be done either by logout, system shut down, or using the task-manager (available via Ctrl-Alt-Del or Str-Alt-Enf).

A small resume button labeled ... will nevertheless appear when resumable sessions are available.

[Options]

NaviMinimal=True

Up to Version 3.50 02.07.2010, this option would cause slightly higher scaling of questionnaire content in y-direction, and consequently, of all fonts (affecting both height and width) used to display text items of questionnaire content. This could distort answer field geometry and cause final words to be missing in text item display. The option does not only replace the original four button navigation window by a reduced version with only one large "Start" button, but also removes the menu bar from the navigation screen. The program, however, measures the available clientrect size already on that screen. So before version 3.50, the missing menu bar resulted in a larger clientrect measurement in y-direction. In version 3.50, the measured clientrect size is reduced by the height of a menu bar plus a non-sizable window frame when NaviMinimal=True is set, so both options cause identical (correct) scaling of questionnaire content.

Since version 3.52, the following options provide the minimal navigation dialog, but with an additional "Exit" button. Thereby, AnyQuest can be closed again, even when the minimal navigation dialog shall be used:

[Options]

NaviMinimal=True

NaviMinimalShowExit=True

Since version 3.13, the following options can switch of elements of the AnyQuest for Windows main window. These options are effective both during the display of the navigation window, in setup mode, and during questionnaire presentation. While this makes it more difficult to minimize the main window during questionnaire presentation, it remains still possible - e.g. by double clicking on the window title. Although the "Close window" button becomes greyed out this way, the program can still be closed via the "Exit" button on the navigation menu if that has not been locked. The keyboard input Alt-F4 also continues to work to bring up the "continue, save, abort..." dialog during presentation of a questionnaire.

[Options]

DisableMainWindowMinimizeBox=True

DisableMainWindowSystemMenu=True

Since version 3.13, the following options make AnyQuest ignore the referenced signals during questionnaire presentation. Blocking these signals alone suffices to prevent minimization, changing window size etc. during questionnaire presentation. At least the options named $F... should be used in order to prevent a window size change with double clicks on the taskbar, even if the options given above are used to remove the minimize button and system menu. Each of these options can be individually controlled. All of them are only effective during questionnaire presentation. As long as the navigation window is displayed, however, they are not required as the navigation window itself is a modal dialog and will not allow any manipulation of the AnyQuest main window while it is active.

[Options]

f_Ignore_sc_minimize=True	(sent to window if minimize button clicked)

f_Ignore_sc_maximize=True	(sent to window if maximize button clicked or remaxed from task bar)

f_Ignore_sc_restore=True	(sent to window if restore-to-normal-size button clicked or restored from task bar)

f_Ignore_sc_f012=True	(sent to window on single click or first click of double click on title bar of normal window)

f_Ignore_sc_f032=True	(sent to window on second click of double click on title bar of normal window)

f_Ignore_sc_f122=True	(sent to window on second click of double click on title bar of maximized window)

f_Ignore_sc_size=True

f_Ignore_sc_close=True

Since version 2.92, The following options can switch of the standard listing of loaded questionnaires on the title screen, and display a proprietary headline. They can be used separately or in combination.

[Options]

DontListQDWs=True

ConfigTitle=Your own proprietary title

Since version 3.23, The following options can switch of the display of the JMS-Rainbow and of any bitmap graphic logo otherwise visible in the title screen. Setting both parameters to True gives the title screen a plain empty white background, no matter whether you use the generic anyquest.exe or a customized version, like eortcqlq.exe, esiro.exe or eibsqol.exe etc.

[Options]

TitleSuppressBitmap=True

TitleSuppressRainbow=True

You will probably use these options only when you want to provide a well-tested configuration to its final users in a fixed environment.

As long as the "Setup" button is disabled, changes regarding the set of loaded questionnaires, patient identification parameters to be collected, target data storage path and printer configuration, can only be made by changing the configuration file (first). If the configured printer or data storage path should become inaccessible, however, AnyQuest may present appropriate dialogs to handle the error condition automatically, and changes made via these dialogs will most probably be written into the configuration file if that has not been write protected.

If you disable both the "Setup" and the "Exit" button using the above options, there is no way left to close AnyQuest for Windows from inside itself. If you still want to close it, you can bring up the task manager by pressing Ctrl-Alt-Del, then select AnyQuest for Windows and close it from there. If you want to use a single machine to present a given questionnaire for good in so called kiosk-mode, please disable all three buttons, and additionally, replace the standard Windows shell (usually the Explorer or Program Manager) by AnyQuest for Windows.

When the menus are configured to be restriced or when the "Setup" button is configured to be disabled, AnyQuest will automatically exit the edit layout mode if that should have remained configured active inside the configuration file.

If you want to perform a pseudonymous or anonymous data collection, and thus do not want the date of birth to appear on printouts and/or in the *.anq result file, and the computed age of the patient to be written to the *.anq result file with reduced resolution so that the exact date of birth can not be computed from it, since version 3.50, you can use the following options. These can be set via the configuration file, or via the General printout options and *.anq output file options menus.

[Options]

PrintSuppressPatientDOB=True

[*.anq Output File Options]

anqfile_SuppressDOBWriteOut=True

anqfile_AgeOfPatientPrecision=1

The default resolution for the computed age of the patient is 3 decimal places, the allowable values are 0 to 3.

Known limitation: 	The option anqfile_SuppressDOBWriteOut=True is currently not compatible with a configuration that collects a date of birth and recognizes a previously used patient ID when the PID is collected by the interactive PID collection screens before the date of birth and the *.anq result file causing the PID recognition, because an empty date of birth will be read from the external file and as of 3.50, this will cause an error message, but no dialog to manually enter the DOB will be shown.

• Multiple configurations

• Preparing international environments

• Language specific *.ini file example overriding system default fonts and date format

• Questionnaire definition file language and version


International environments

Preparing international environments

If you want to provide a questionnaire in a set of different languages, and make all languages available via individual shortcuts or start-menu-entries or program-group-entries, you need to prepare or use the following:

•	Translated versions of all required *.qdw-files (e.g. introen.qdw, introde.qdw, introfr.qdw, qnren.qdw, qnrde.qdw, qnrfr.qdw).

•	Translated versions of AnyQuest's message file anyquin.msg (e.g. en.msg, de.msg, fr.msg).

•	One version of anyquin.ini for each language specific configuration multiconfig (e.g. en.ini, de.ini, fr.ini).

•	One shortcut or start-menu-entry or program-group entry for each language specific configuration (e.g. en.lnk, de.lnk, fr.lnk).

The examples given in brackets refer to an environment containing English (en), German (de) and French (fr) versions of a set of questionnaires made up from two parts: intro*.qdw and qnr*.qdw.

If you want to prepare language specific questionnaire definition files, you should probably prepare a master file first, then generates all *.qdw files for other languages using Jörg's Magic Questionnaire-o-Matic.

To obtain international versions of AnyQuest's message file anyquin.msg, you can either ask me or translate the provided anyquin.msg using a text-editor.

In each language specific *.ini file, you would include references to the required language specific *.msg and *.qdw files, and also set the desired date format for dialogs and printouts to either DD.MM.YYYY or YYYY-MM-DD like in this example.

In each language specific shortcut/start-menu-entry/program-group-entry, you would specify one specific *.ini file as parameter to supply to anyquin.exe.

• Multiple configurations

• Questionnaire definition file language and version

• Preparing a secure configuration


Multiple configurations and multilevel cascaded configuration files

Basic information about *.ini configuration files

AnyQuest for Windows reads most configurable options from a configuration file *.ini when the program starts. It can also write these settings back to the same file when the program ends. Thus, by default, AnyQuest can remember the current settings even after the program has been closed and restarted. If you deploy AnyQuest mainly in an interactive way, this mechanism ensures that you can continue to work in the same environment every time you restart AnyQuest.

Configurable options include patient ID variables to ask for at the beginning of a session, external software to be plugged in, a list of the loaded questionnaire definition files, the data storage folder, printout related settings etc. etc. As of version 3.66, about 500 configurable options can be controlled, and most have reasonable default values.

The configuration file is a plain text file which you can directly edit with any text-editor (e.g. the editor notepad shipped with MS Windows, or more comfortable editors like TextPad, PSPad, or nedit).

If you want to prepare a variety of configurations or if you want to copy a configuration to another machine, this is faster and much more convenient than using AnyQuest's menus. Some options are not even available through the menus at all, they can only be set by editing the configuration file directly.

Most configuration file options are have self-explanatory names and settings. Many are explained in the related section of this on-line help file; some (especially some newer and for technically advanced users) are only mentioned and briefly explained in the product history section of this on-line help file.

When you start AnyQuest for Windows directly by clicking on the program file anyquin.exe, its default configuration file is anyquin.ini. If you delete the default configuration file (usually: c:\anyquin\anyquin.ini) and start, and then end, the default executable program file (usually: c:\anyquin\anyquin.exe) without specifying a configuration file to be used, a new default configuration file will be written that contains entries for most default settings. As of version 3.66, only a very small number of rather exotic parameters are not written out by default.

Provided the default configuration file is not write protected (see below), you can also call c:\anyquin\anyquin.exe, select your preferred settings using the built in menus (e.g. selection of various primary and secondary printers for different types of printouts), end the program and review the updated configuration file to find the correct way (like: printer names etc.) to specify these settings.

Preparing multiple configurations in advance

Please note: Some application examples for multilevel configuration files are given below and also included in the "simple example package" and all project specific packages.

In typical application projects, one configuration file is prepared in advance for every (set of) questionnaire(s) in every language or usage mode. Each of these configuration files only needs to specify those parameters that deviate from AnyQuest's default settings. All of these configuration files are usually write protected, so future (accidental) changes will not be written back into them. Thereafter, whenever a given (set of) questionnaires in a given language shall be administered, AnyQuest can simply be called with the name of the respective configuration file.

If you want AnyQuest to use a certain initialization file, you can specify it as command line parameter. For example, you might create different icons in your program manager (Windows 3.x) or in the Windows Start-Menu (Windows 9x and newer) or on the desktop. Each of these shortcuts or entries might call AnyQuest with another *.ini file, thus being able to use its own set of questionnaires, its own set of configurable options, and its own place for storage of recorded data.

The various entries created when you install the example package AnyPak use this technique.

A nicely looking programmable menu surface to select from pre-arranged configurations is also available upon request (jssplash). This has been used in multiple application projects and is especially useful when you want to replace the MS Windows program manager or Explorer desktop by something that is more easy to use, and provides less functionality for unintended usage.

Finally, configuration files can also be synthesized on the fly and temporarily provided by an external application directly before AnyQuest is called from that application. The meQ/TSS application developed in co-operation with Stefan Heckel Medizintechnik GmbH, Esslingen, Germany, follows this approach.

Write protection

Since version 2.68, you can set disable_write_ini_file=True in the *.ini file to protect your *.ini file from being changed accidentally. Unwanted changes in an unprotected *.ini file might occur, e.g. after a patient used the setup mode in an unprotected configuration, or after questionnaires which should have been loaded from a file server when AnyQuest started where not available at this time. Before version 2.68, this protection could only be achieved by write-protecting the *.ini file, but there were reports that this might not have been sufficient in all environments.

(In version 2.68, this flag erroneously also affected saving of configuration data when a session was interrupted and saved for later resumption, this has been corrected in version 2.69.)

Date and time format

Since version 2.82, you can set DateFormatDialog and DateFormatPrint to either 0 or 1 in the *.ini file, thereby telling AnyQuest which date format it shall expect in dialogs and date format checking, and which date format it shall use when it generates printouts. Setting each parameter to 0 or leaving it undefined selects the default format of DD.MM.YYYY for display or  printing and acceptance of all similarly arranged formats for input. Setting it to 1 selects the alternative format of YYYY-MM-DD for display or printing and acceptance of all similarly arranged formats for input. The format used in *.anq files will remain as DD.MM.YYYY in any case.

Brief introduction to *.msg message files

These files may be named e.g. de.msg, en.msg, fr.msg, chn.msg, ne.msg etc. They (re-)define common messages which are not related to individual questionnaires but rather to a given language or location.

This includes messages used during patient identification data collection (e.g.: plsdob='Please enter your date of birth (YYYY-MM-DD)'), as well as error and information messages (e.g.: thanx='Vielen Dank!'), and some labels used in result files and produced printouts (e.g.: xcaseid='Fallnummer:'). If you want to change what appears above any given PID collection dialog, you only need to redefine the respective text. This can be used for translations, or if you want to collect variables that are not originally listed in AnyQuest's selection of patient identification options to be asked for and printed out, or if you want to e.g. give instructions to use a barcode reader to scan a Case-ID. Overall, a large subset of all general text displayed by AnyQuest for Windows can be changed using this file.

Please review message files available to you to learn about details - they can be opened with a simple text editor and usually contain comments. Messages not redefined by a *.msg files will currently (as of version 3.44) use default content in the German language.

A message file to be used for a given configuration can be specified either via command line parameter or via an entry in the *.ini file:

[General]

OverridingMsgFile=c:\anyquin\yourproj\config\de.msg

Since version 3.44, additional parameters buttons_selection_PID, buttons_selection_CaseID, buttons_selection_physiciannumber, buttons_selection_sex, buttons_selection_ethnicity, buttons_selection_nationality, buttons_selection_group, buttons_selection_subgroup, buttons_selection_cycle, buttons_selection_subcycle, buttons_selection_rater, buttons_selection_infosource, buttons_selection_assessment in the *.msg file are supported to control which buttons are actually enabled in certain PID collection related dialogs. If either parameter is not specified or defined as an empty string, the buttons included in the respective default dialog are left and used unchanged. If either parameter is set to a non-empty string, all buttons from the respective default dialog are screened, and if the text found on a button is not included in that string, the button is disabled, grayed, and the displayed text is removed.

Questionnaire scaling control and overriding screen size

The new section [Scaling] can have the following new parameters: suppress_scaling_during_loading=True - causes the loaded content of the questionnaire definition file not to be scaled to any currently seen clientarea size; show_info_scaling_during_loading=True - causes debug information to be displayed on the currently seen clientarea size, the size stored in the questionnaire definition file currently being loaded, and the applied scaling factors derived from this information. The parameters assume_aqwinwidth and assume_aqwinheight can be used to override the measured clientarea size, if either value is set to a value above 0.

Known limitation: The values used (and stored in questionnaire definition files) for aqwinwidth and aqwinheight are one unit above the expected clientrect size values. The measures stored in a questionnaire definition file created on a 1024x768 pixel display would be reached using assume_aqwinwidth=1025 and assume_aqwinheight=723. The actual values may vary depending upon the system metrics, which may vary with different versions of MS Windows and user adjustable settings.

Multilevel, structured, cascaded, shared, centralized configuration files

Please note: Some application examples for multilevel configuration files are given below.

In version 3.50, the new parameters ConfigFileAfterBefore1=c:\anyquin\mystudy\config\cfgbef1.ini etc. and ConfigFileAfterCurrent1=c:\anyquin\mystudy\config\cfgaft1.ini etc. in the new section [MultiLevelConfig] were originally added. They caused secondary, tertiary etc. configuration files to be processed before or after the currently processed configuration file. Back then, however, the new options were not really useful because all possible configuration options were evaluated for all *.ini configuration files; so default values would be used for each option unspecified in any given configuration file.

In version 3.62, the new functionality has been completed and has become practically usable. Since then, AnyQuest automatically uses adequate discretion in filling in - or not filling in - default values for parameters not explicitly specified in a given configuration file:

By default, the first configuration file completely processed (i.e. the first in a cascade that has no actually honoured ConfigFileBeforeCurrent=... entry) will cause default parameters to be used for unspecified parameters; whereas all files whose processing is completed thereafter will only affect parameters actually specified.

Please note that the first configuration file to be completely processed is not necessarily the same file that was supplied as parameter when AnyQuest for Windows was being called!

This behaviour can also be changed manually, so that a configuration file processed later in the cascade would re-install default values anywhere if desired; but that should rarely be necessary.

As of version 3.66, each configuration file may contain up to 9 references to other files to be processed before the current one, and up to 9 references to other files to be processed after the current one. The references are honoured up to a total depth of 4 levels - this is an arbitrarily chosen limit to protect against excessive stack usage in AnyQuest.

After all, it is now possible to deploy a scheme of cascaded configuration files, that provide certain aspects of machine-local, user-specific or site-global settings, also across various questionnaire setups, language-versions, or projects, in separate, named files, which can be distributed across networked or local media.

For example, a single file config\common\printout.ini may include all settings that control the printout features, including which types of printouts are produced (and copied) on virtual PDF or real printers etc., and this file can be referenced by all other configuration files on the systems. So changing printer settings, can be accomplished centrally by editing just one file.

Or if one printout.ini file is placed onto each local machine in a network, each machine can automatically be instructed to use the network printer located most conveniently to it - etc. As before, both referenced and referencing configuration files only need to contain the settings which they want to change from their default (or from previously determined) settings.

The newly supported parameters are:

[MultilevelConfig]

OnlyReadParametersAlreadyInTheFile=True|False

ConfigFileBeforeCurrent1=...

..

ConfigFileBeforeCurrent9=...

ConfigFileAfterCurrent1=...

..

ConfigFileAfterCurrent9=...

Please note: Multilevel configuration files should preferrably be deployed together with the parameter disable_write_ini_file=True. As of version 3.66, any current settings would only be written to the first level configuration file anyway. Even if all parameters would be written back into that file, this should not cause any functional difference, but it would probably remove any improvement in legibility and easy comprehensibility of configurations provided by structured, cascaded configuration files. Writing back settings into the primary configuration file for parameters which would later be changed by second level configuration files, could even be misleading to less knowledgeable or less alert readers.

When current settings are written into a temporary configuration file during the saving of an interrupted session for later resumptions, only one temporary configuration file will be employed, and the section on [MultilevelConfig] will neither be stored nor used.

Recommended directory tree structure and arrangement of files for multiple configurations and multiple projects

All *.ini files except the default file anyquin.ini should be kept in a nicely organized manner somewhere below c:\anyquin\yourproj\config.

Originally (outdated!), I had suggested to organize files for multiple configurations which are made for multiple purposes, by using matching subdirectories like c:\anyquin\config\yourproj, c:\anyquin\questns\yourproj, c:\anyquin\data\yourproj etc.

A much better approach, however, is to arrange all subdirectories required for your project below one common subdirectory, like c:\anyquin\yourproj: This means you should use c:\anyquin\yourproj\config, c:\anyquin\yourproj\questns, c:\anyquin\yourproj\data etc. This enables you to backup or copy or package into a *.zip file everything required for your configuration in a single step, and maintain it undisturbed from files belonging to other projects or other people.

Organizing your files like this helps to avoid confusion of yourself now, and of any system administrators to come after you in the future.

Here is a suggested directory tree layout for use with multilevel cascaded configuration files. The example is taken from the setup prepared for the HELPS project.

Please note that up to AnyQuest for Windows 3.71 running under Windows, only filenames following the (ancient) 8.3 scheme are supported.

z:\anyquin
  |
  |--helps                           A subdirectory containing everything related to one application project
  |    |
  .    |--data                       *.anq result files from this application project
  .    |
  .    |--printout                   Automatically created *.pdf or *.xps etc. documents with graphical result prinouts
       |
       |--extract                    Pre-defined configurations for the extract tool
       |
       |--gdt                        Components of the xDT/GDT/LDT interface used by this application project
       |
       |--image                      Image files used within this application project
       |
       |--sound                      Sound files used within this application project
       |
       |--doc                        Documentation related to this application project
       |
       |--tools                      Various tools related to this application project
       |
       |--questns                    All questionnnaire definition files related to this application project
       |    |
       |    |--de-de                 For the German language
       |    .    |
       |    .    .
       |    .    .
       |         .
       |
       |--config                     All configuration files related to this application project
       |    |
       .    |--common
       .    |    |
       .    |    |--allowall.ini     Settings for configurations allowing (almost) all menu options
            |    |--allowuse.ini     Settings for configurations allowing only user menu options
            |    |--dirs.ini         System wide settings for the data storage directory
            |    |--extnapp.ini      Settings regarding external applications (interfaces)
            |    |--getidetc.ini     System wide settings regarding patient ID details to be collected
            |    |--pointer.ini      System wide settings for reset cursor position
            |    |--prefxall.ini     *.anq file name prefix for configs with all questionnaires
            |    |--prefxal.ini      *.anq file name prefix for configs with questionnaires on alcohol
            |    |--prefxnu.ini      *.anq file name prefix for configs with questionnaires on nutrition
            |    |--prefxoh.ini      *.anq file name prefix for configs with questionnaires on oral health
            |    |--prefxpa.ini      *.anq file name prefix for configs with questionnaires on pain
            |    |--prefxsm.ini      *.anq file name prefix for configs with questionnaires on smoking
            |    |--printout.ini     System wide settings for all printout related options
            |    \--other.ini        System wide settings for all other non-default options
            |
            |--de-de                 Configuration files for configurations using the German language
            |    |
            .    |--language.ini     This file covers all language specific settings
            .    |--standard.msg     A German standard message file
            .    |
                 |--normal           Configurations For patients to fill in questionnaires directly
                 |    |
                 |    |--al.ini      Configuration file for use of the alcohol questionnaire
                 |    |--nu.ini      Configuration file for use of the nutrition questionnaire
                 |    |--oh.ini      Configuration file for use of the oral health questionnaire
                 |    |--pa.ini      Configuration file for use of the pain questionnaire
                 |    \--sm.ini      Configuration file for use of the smoking questionnaire
                 |
                 |--fastform         Configurations For staff to record and score paper questionnaires effectively
                 |    |
                 |    |--al.ini      Configuration file for use of the alcohol questionnaire
                 |    |--nu.ini      Configuration file for use of the nutrition questionnaire
                 |    |--oh.ini      Configuration file for use of the oral health questionnaire
                 |    |--pa.ini      Configuration file for use of the pain questionnaire
                 |    \--sm.ini      Configuration file for use of the smoking questionnaire
                 |
                 \--analysis         Configurations for staff doing data analysis and data export tasks etc.
                      |
                      |--al.ini      Configuration file for use of the alcohol questionnaire
                      |--nu.ini      Configuration file for use of the nutrition questionnaire
                      |--oh.ini      Configuration file for use of the oral health questionnaire
                      |--pa.ini      Configuration file for use of the pain questionnaire
                      \--sm.ini      Configuration file for use of the smoking questionnaire

This structure is especially helpful in larger projects, with configurations covering multiple questionnaires in multiple languages, and multiple usage modes (patient fills in vs. fast input form etc.). The actual filenames of files with identical function remain the same across various languages, or usage modes. Functionality to be shared between various configurations is specified in second-level configuration files shared at the language level, at the usage-mode-level, or even across all configurations of the same project.

All this makes the structure of configuration files much more easy to understand and to maintain.

---

Here are several files from the above directory structure:

Multilevel configuration file z:\anyquin\helps\config\common\printout.ini (partial):

;Note: This config file references files on drive C:
;      prepared for the HELPS project, Guenzburg
;
;      This file is part of a multilevel config file structure.

[Printout]
SinglePrnDrv=
SinglePrnDev=
SinglePrnOut=
CumPrnDev=
CumPrnDrv=
CumPrnOut=
...
Single2PrnDev=
Single2PrnDrv=
Single2PrnOut=
Cum2PrnDev=
Cum2PrnDrv=
Cum2PrnOut=
...

PrintRandLeftmm=25
PrintRandTopmm=10
PrintRandRightmm=10
PrintRandBottommm=10

Trailer1=Adoption of the HELPS questionnaires on AnyQuest for Windows.
Trailer2=Prepared by Jörg Sigle, joerg.sigle@jsigle.com, www.ql-recorder.com, 2010

BitmapHeaderLeftPath=c:\anyquin\helps\image\hl.bmp
BitmapHeaderCenterPath=c:\anyquin\helps\image\hc.bmp
BitmapHeaderRightPath=c:\anyquin\helps\image\hr.bmp
...

[Options]
AutoQnrFilledInPrintout=True
AutoSinglePrintout=True
AutoCumulativePrintout=True
PrintoutForQnWOResultFormula=True

PrintSuppressLicenseInfo=True
...

---

Multilevel configuration file z:\anyquin\helps\config\de-de\language.ini:

;Note: This config file references files on drive C:
;      prepared for the HELPS project, Guenzburg
;
;      This file is part of a multilevel config file structure.

[General]
OverridingMsgFile=c:\anyquin\helps\config\de-de\standard.msg

[Options]
DateFormatDialog=0
DateFormatPrint=0

Greek_PID_collection_and_Printouts=False

[WaveSounds]
file_playwaveWrongBirthday=c:\anyquin\helps\sound\de-de\dobwrong.wav
file_playwaveMissingAnswer=c:\anyquin\helps\sound\de-de\missing.wav
file_playwaveMissingAnswers=c:\anyquin\helps\sound\de-de\missings.wav
file_playwaveThankYou=c:\anyquin\helps\sound\de-de\thanx.wav
file_playwaveInputLastName=c:\anyquin\helps\sound\de-de\lastnm.wav
file_playwaveInputfirstName=c:\anyquin\helps\sound\de-de\firstnm.wav
file_playwaveInputPatientID=c:\anyquin\helps\sound\de-de\patid.wav
file_playwaveInputDateOfBirth=c:\anyquin\helps\sound\de-de\dob.wav
file_playwaveAtLeastOneChar=c:\anyquin\helps\sound\de-de\onechar.wav

---

Multilevel configuration file z:\anyquin\helps\config\de-de\normal\al.ini:

;Note: This config file references files on drive C:
;      prepared for the HELPS project, Guenzburg
;
;      This file is part of a multilevel config file structure.

[MultiLevelConfig]

;The following entries are references to other configuration files
;with settings that can be centrally adjusted
;for all languages and questionnaires:

ConfigFileBeforeCurrent1=c:\anyquin\helps\config\common\other.ini
ConfigFileBeforeCurrent2=c:\anyquin\helps\config\common\dirs.ini
ConfigFileBeforeCurrent3=c:\anyquin\helps\config\common\extnapp.ini
ConfigFileBeforeCurrent4=c:\anyquin\helps\config\common\getidetc.ini
ConfigFileBeforeCurrent5=c:\anyquin\helps\config\common\pointer.ini
ConfigFileBeforeCurrent6=c:\anyquin\helps\config\common\printout.ini

;The following entries are references to other configuration files
;with settings that can be semi-centrally adjusted
;for one language, one questionnaires topic, or one operation mode:

ConfigFileBeforeCurrent7=c:\anyquin\helps\config\common\allowuse.ini
ConfigFileBeforeCurrent8=c:\anyquin\helps\config\common\prefxal.ini
ConfigFileBeforeCurrent9=c:\anyquin\helps\config\de-de\language.ini

ConfigFileAfterCurrent1=
ConfigFileAfterCurrent2=
ConfigFileAfterCurrent3=
ConfigFileAfterCurrent4=
ConfigFileAfterCurrent5=
ConfigFileAfterCurrent6=
ConfigFileAfterCurrent7=
ConfigFileAfterCurrent8=
ConfigFileAfterCurrent9=

[LoadedQuestionnaires]
NumberOfLoadedQNs=1
LoadedQNFilename1=c:\anyquin\helps\questns\de-de\al.qdw

[Options]
ShowQnrFastInputForm=False

Debug output that can be enabled via the configuration file

Since version 3.62, new *.ini configuration file parameters can activate the production of some debug output at runtime.

Newly supported parameters are:

[Debug],

inifile_rw_filename=True

qdw_rw_filename=True

ini_fontinfo=True

ini_prndevnames=True

ini_thisprn_try=True.

All debug output initially available through this function is related to configuration file processing.

By default, the debug output currently appears in a window which is positioned on a second monitor located in the upper left of the primary monitor.This option is a preliminary implementation - the intention is to use e.g. a single global configuration file providing some common options, for multiple configurations, that can be included from multiple specific configuration files. The intended usage is, however, currently not possible, because

• Command line parameters

• Preparing international environments

• Language specific *.ini file example

• Preparing a secure configuration

• Fast-Input-Form mode to record and score paper questionnaires


Running the fastest demonstration available

Using all default options

If you're trying out the software for the first time, and your configuration has already loaded at least one questionnaire definition file, I would recommend you to try the program without changing any of the supplied settings.

By default, AnyQuest will try to use any printer (or PostScript- or PDF- or JournalFile writer) that was the default system printer when it started up.

To have a look at what a patient might see, just click on the "Go!" or "Start!" button to begin a questionnaire administration session.

Configurable options

If you want to become more familiar with the system, to explore any available options and to change them to your requirements:

First, please note that any configuration prepared for AnyQuest for Windows can be protected against unwanted changes.

Depending upon the configuration you started, you may be able to click on a "Setup" button, and afterwards to modify several settings, or you may not.

If access to "Setup" mode is available, you may either be restricted to adjust settings for patient-ID-collection, sound, printing and the like (typical for most of the pre-supplied patient questionnaire configurations), or you may even be allowed to change the loaded selection of questionnaires (typical for use of the generic configuration file, and for the configuration "Your Own").

The questionnaire definition file which is pre-supplied and automatically loaded in the configuration named "Your Own" explains how to load other questionnaire definition files into that configuration.

If you want to change anything in your currently used configuration:

(1)	E.g., if you don't want to receive any printout or don't have a printer:

•	In the window "AnyQuest Navigation", press the button "Setup".

•	In the "Printing"-menu, uncheck the options for QFI printout, single printout, and cumulative printout.

•	In the menu "Navigation", chose "Show navigation window".

(2) In the window "AnyQuest Navigation", press the button "Go!", to start the questionnaire administration with changed settings.

The user's selections of many configurable options throughout AnyQuest's menus would normally be preserved in the currently used configuration-file (default: c:\anyquin\anyquin.ini, or any configuration specific one instead), even after the program has been closed. However, the configuration-files supplied with the simple example package may be write protected, so user changes are discarded when the program is ended. If you want to change this behaviour for the pre-supplied (or your own) configurations, please read on about configuration file details.

What's inside the demonstration?

What's there for the eyes?

What's there for the ears?

The pre-supplied configurations illustrate how AnyQuest for Windows can be used to administer electronic questionnaires to patients.

If you should want to learn how you can use it to prepare your own electronic questionnaires:

• The quick guide: how to make your questionnaire go electronic


Running the fastest demonstration available

What's there for the eyes?

AnyQuest for Windows will change its look and ask you for your identification. Then, you will be able to answer the provided questions just by clicking with your pointing device at the point where you would like a check-mark to appear.

Note: AnyQuest will continue to the next question 0.3 seconds after you last checked an answer, except for those of the type "discrete answers - multiple selections". To answer these questions, any combination of the answer fields can be checked. A button "Continue...", which appears automatically, has to be pressed when the user has checked all answers he wanted to.


Running the fastest demonstration available

What's there for the ears?

AnyQuest for Windows supports PC speaker sound signals as well as the playback of digitized sound files.

During my stay in Australia, my brother recorded some digitized sound files for me. In the meantime, the AnyQuest for Windows pre-release package comes with new sounds which fit onto a floppy disk and can be played by speaker.drv.

If you don't hear anything, you might have one of the following:

•	disabled wave sound in the "Sound"-menu,

•	sound files which are not located where AnyQuest looks for them,

•	no soundcard and speaker.drv not installed,

•	a soundcard but no drivers installed,

•	a soundcard but no speakers connected,

•	at least one crucial volume slider set to zero :-)


Presenting questionnaires to a patient

This is just as easy as running the fastest demo available. Just load the questionnaires you want to present in the sequence you like, and optionally review the configuration of different options.

Then, either press "Go!" in the "AnyQuest Navigation" window, or from the menu "Navigation", select "Remove Menu & START ASKING QUESTIONS".

Plese note: If you have one or multiple predefined configurations as, for example, supplied by the anypak.exe package, or prepared by yourself or your system administrator, you may directly select a configuration from your start menu and just start the questionnaire presentation with the "Go!" or "Start" button.


Preferred settings for questionnaires

Preferred settings for the supplied actual quality-of-life questionnaires

It is not necessary for a patient, to see the questionnaire title continuosly. So presenting questionnaires to a patient, the following menu settings might be most useful:

"Sound" 	PC speaker	checked (if desired)

Wave output device	checked (if desired)

Setup PC speaker	all checked

"Display"	Show long questionnaire name	unchecked

Show short questionnaire name	unchecked

Show explanation	checked

Show explanation 2	checked

Show Can't/Don't want to answer	unchecked

Show additional text input windows	checked

Show questionnaire number	unchecked

Show question number	unchecked

Show numeric and string results	unchecked

Show graphical progress indicator 	checked (if desired)

"Printing" 	Automatic single printout	checked (if desired)

Automatic cumulative printout	checked (if desired)

"Navigation" 	Automatic proceeding to next question check, calculate, output...	checked

Automatic check, calculate, output...	checked

Endless question asking 	unchecked

Patient identification options to ask for...	check "given name", "christian name", "date of birth" or as desired

Show transportbar	unchecked

Please note: Since version 2.63, you can show or hide the "Can't/Don't want to answer" fields by clicking four times in sequence in the lower left area of the AnyQuest main window during questionnaire presentation. Since version 2.68, this functionality is disabled by default and can be activated by setting kblessctrlspecialclickcheck_1=True in the *.ini file.


Generated results

After the last question, the answers will be checked, questions with missing answers will be displayed again. If all questions have been answered, the results are stored in a file *.anq, and, if configured, printouts are generated.

You can look at the *.anq file with any text-editor and it can be copied or transferred to any other computer platform.

The printouts AnyQuest for Windows can generate immediately after each session, can show results from the current session, the course of the current patient over time and even externally supplied static or dynamically computed reference values or ranges. Since version 2.97, a prototype of a new printout resembling a filled in questionnaire is available.

Some basic statistical analysis of collected data can be generated and printed at any time, including interactive condition based selection of results into groups, basic descriptive statistics and box plots.

However, usually all required information from a number of collected files would be exported into a single file which then can be imported into a spreadsheet, database or statistical sotware for a more sophisticated analysis.

AnyQuest does not include sophisticated a file-viewer itself, because of the superior performance of common statistical, mathematical or database software. However, my brother contributed AnyQuery for Windows to the project. If users should request it, I might include some minimal statistical functions in a future version.

Detailed information about data storage and about interfacing to third party applications is included in this help file.


Data storage and data protection

Note on data storage and data protection

To assure that your data storage and data protection measures are appropriate, you should either have sufficient knowledge in these areas and concerning secure computer operation yourself, or you should consult a local expert.

This is not only a legal, but also an ethical obligation.

Please review the considerations regarding collected patient identification data in a section of the quick guide for questionnaire users.

Here are some more hints regarding data storage and data availability:

•	One of the goals of the Quality-of-Life-Recorder concept is to make quality-of-life data retrievable, readable and exchangeable among researchers. Both AnyQuest for Windows and AnyQuest for MS-DOS store data in a format which may appear very redundant, storage space waisting, out of date and inefficient. However, the same format guarantees that all stored data are clearly readable and understandable even without any manual and any software besides any computer's operating system, and that data are easily exchangable even among different computer platforms.

Update, from 2009: Apparently, my preceding valuation, written in about 1996, was a little bit ahead of its time. Similar advantages are nowadays claimed for XML based storage and data exchange formats. Whereas *.anq can be converted into an XML format very easily (a converter can be provided upon request), it may be more easily readable, and smaller than many XML files produced by contemporary applications.

•	Please be sure to keep your original *.anq files, as they are intended to serve as a standardized means of storing quality-of-life data with guaranteed, platform- and software-independent exchangability and readability.

•	Do not forget to implement an adequate backup strategy for collected data.

Here are some more hints regarding data protection from unauthorized access:

AnyQuest for Windows itself does not offer support in this area, because this issue is already covered by various operating systems, network operating systems, and by several hardware- and software-solutions for storage device encryption. So you should consider the following measures:

•	Consult available literature, applicable law and experts: Applicable law depends on where and how you work. A lot of material is available from different sources; much is available on-line. Material is provided and standards are defined locally by many organizations as well as by governmental institutions. If you collect patients' data, you may may have a legal obligation to contact either local or governmental experts and to report what data you are collecting. (This may, by the way, be independent from whether you record data electronically or on paper, but applicable regulations may vary depending on whether you do scientific or routine medical work.)

•	Keep your knowledge up-to-date: Knowledge about possible security leaks increases over time. You should know as much as the people against who you're protecting your data :-)

•	Only collect required data: Do not collect a detailed and clearly readable patient identification if you do not need that. But definitely do collect a reliable patient identification code if you need to join data from different measurements or from different sources, and consider collecting and processing your patients names', if this helps to show them that you do not treat them as numbers, but as individuals.

•	Limit physical access to your computer: Keep your pen-computer locked away while not in use. Don't leave patients alone with for an inadequately long time! Don't have it sold - accidentally - in the trunk of a colleague's car!

•	Use passwords to protect your computer, your screen saver, your operating system, your network: If used inappropriately, this may not be unexpectedly insecure, because e.g. a harddisk with data can be removed and built into another system, that does not ask the spy to enter any password.

•	Use an operating system with access rights, e.g. Linux, Windows NT, Novell: This is the preferred solution for whole networks, and it may require some thorough configuration work. However, it is feasible and can give good data protection, especially when the actual data storage device is located in a computer which is not easily physically accessible. For example, a workstation in a network might be allowed to write, but never to read files from a given directory.

•	Use wireless networks for laptops and pen-computers: Thus, no data are kept on the hardware device which could be lost or broken most easily. Be sure to configure wireless communication security adequately.

•	Remove unsafe applications that are not required or limit access to them: Don't forget that Windows is a multitasking environment. You should not try to protect AnyQuest and your floppy drive, and then leave your statistical software running in another window with data loaded on the same machine. And of course, computer literate patients could use a locally available notepad.exe to view locally available and unprotected *.anq files.

•	Hide and/or protect collected data: Do not place an unprotected link to "My collected patient data" onto your desktop; rather set the attributes of c:\anyquin\data to "hidden", set your Windows Explorer options so that such folders are not shown - or rather use an operating system that allows you to grant access rights to collected data and operating system resources in a sufficiently sophisticated way, e.g. Linux.

•	Use on-the-fly-encryption of anything that goes to the harddisk and deciphering of what is read: If you don't enter a password at system power up, nothing can be read. This works even, if a harddisk is stolen and built into another computer, because all data on the harddisk are encrypted at all times. For example, IBM ship their laptop computers with such equipment by default (1996).

•	Restrict access to several devices like keyboard, floppy-disk-drive and so on: AnyQuest for MS-DOS could completely inhibit any abuse of the Quality-of-Life-Recorder PC, because it eliminated any unauthorized keyboard access. AnyQuest for Windows still is only a data caption tool and does not offer possibilities to view data; if you use a pen-computer, a keyboard may not be available, either. However, the export function, which was integrated into the main program for convenience, might be abused to copy data onto an external floppy drive. So you might wish to ensure that this can't be done by measures like removing, disabling or locking your computer's floppy drive - or just by setting up a Windows configuration without any other accessible programs and putting AnyQuest into endless question asking mode = unattended "kiosk" mode.

•	And: consider removing the paper-based patient files from your hospital's hallways: The "security" of this traditional medium might be determined by its illegibility alone...


The transport bar, simpler navigation buttons, the "Continue..." button and anchors

The transport bar and anchors

Alternatively to automatic proceeding through questions, a transport bar can be displayed. It has four buttons:   |<-   <-   ->   ->|    which allow the user to go one question ahead, one question backwards, to the beginning, or to the end of the current questionnaire. If neither the transport bar nor the automatic proceeding are checked, AnyQuest for Windows will still proceed automatically through qestions if appropriate, after "Navigation" - "Remove menus and start asking questions" has been selected, as the usual menu will have disappeared then.

Even when the transport bar is disabled, if the patient wants to go back e.g. to correct a mistake, assisting personnel can help using these keys.

Since version 2.63, you can show or hide the transport bar by clicking four times in sequence in the lower middle area of the AnyQuest main window during questionnaire presentation. Since version 2.68, this functionality is disabled by default and can be activated by setting kblessctrlspecialclickcheck_2=True in the *.ini file.

In the layout edit mode, the transport bar is always visible.

Simplified navigation buttons

While the transport bar offers four buttons and thus may be too complicated for some patients, and thus should not be displayed all the time during questionnaire administration, there is a simpler alternative available since version 2.84. The following entries in the *.ini file control the display and behaviour of these buttons:

[Options]

ShowTransportButtons=True

ShowTransportButtonsBackWanted=True

TransportButtonsPlacement=38

Setting ShowTransportButtons=True activates the display of only the middle two buttons   <-   ->    from the original transport bar, so that the patient can advance or go back only one question.

The parameter TransportButtonsPlacement controls where these buttons are displayed, and it also controls whether both buttons are displayed, or whether only the "back" button   <-    is initially displayed, and when the patient goes back one question, removed and replaced by the "forward" button, so that a patient can go back exactly one question, but not more at any time. Staff can still use the keyboardless control function explained above to toggle the display of the complete transport bar at any time in case more navigational freedom should be required. The default setting for this parameter is 38 = 6 + 32, the following table explains the various possible values in detail:

 Placement strategies for Small Transport Buttons:

          [ <--- ]                           [ ---> ]                  y-position:

    1: 1/3 window left of  center      1/3 window right of center        bottom line, same level as continue/transportbar

    2: 1/3 window right of center      1/3 window right of center        bottom line, same level as continue/transportbar

    3: 1/3 window right of center      center                            bottom line, same level as continue/transportbar

    4: left, 1/10 of window            left, 1/10 of window              bottom line, same level as continue/transportbar

    5: centered above progress bar     centered above progress bar       above progress bar

    6: left above progress bar         left above progress bar           above progress bar

  +32: same as 64, but disabled button is not there - just an empty space, affecting position of available button.

  +64: always show a combination of one enabled, selected, labelled button, and one disabled, unselected, unlabelled button.

  +128: both buttons visible and enabled, more desirable button preactivated, equivalent to transportbar without |<- and ->|

Built-in logic ensures that the simplified "forward" button is not displayed when the "Continue..." button would be more appropriate, and that the "back" button is not displayed in the first screen of a set of questionnaires.

The parameter ShowTransportButtonsBackWanted is reserved for internal use by AnyQuest. It stores information on whether the "back" or the "forward" button is currently needed, and it must occur in the *.ini in order to maintain whatever current status through interrupt and resumption of a session. Changing it manually does not have an effect on newly started sessions.

The "Continue..." button

Whenever an Infoscreen is displayed, and the transport bar is not activated, a button labeled "Continue..." is automatically displayed. This enables the patient to the next question when he has finished reading the infoscreen.

The actual text displayed in the "Continue..." button can be defined in the *.msg file specified by a configuration. The button resizes automatically to accomodate the specified text. AnyQuest itself processes #013 in the text as a line break, however the graphical environment appears not to support multiline texts on buttons, so this function is probably not useful at this time.

Normally, certain system settings are used to control the font and character set of the "Continue..." button (and several other items in AnyQuest), but you can define alternative overriding settings in the *.ini file. Click here to view an example of an *.ini file switching to a Greek font and character set.

Anchors

If you have selected a question via "Edit" - "Set anchor question", you can jump directly to the respective question using the "Edit" - "Jump to anchor question" command. If you have selected a question via "Edit" - "Set prototype question", the respective "Edit" - "Jump to prototype question" command will work alike. So you have indeed up to two anchor points for moving around quickly within all your loaded questionnaires. Please be sure to read about additional effects of setting a prototype question before using it as your second anchor.

• keys


Display options

White fillers between individual screens button

Since version 2.84, the display of white filler screens can be activated between successive questionnaire screens, so that the change from one question to the next can be recognized more easily. The following entries in the *.ini file control the display and behaviour of these buttons:

[Options]

UseFillerBetweenQuestions=True

HideTransportDuringFiller=False

Setting UseFillerBetweenQuestions=True activates the display of the white filler screens. Setting HideTransportDuringFiller=False keeps the transport buttons elements visible during the filler screen, resulting in a more quiet and stable perception of screen content belonging to the software environment, not the questionnaire.

Display of various questionnaire elements

According to every project's requirements, different parts of all questionnaires can be displayed or hidden via the "Display"-menu.

So if you wonder where certain parts of a questionnaire might have disappeared, review the settings of this menu.

Since version 2.63, you can show or hide special answer fields "I cannot/I do not want to answer" by clicking four times in sequence in the lower left area of the AnyQuest main window during questionnaire presentation. Since version 2.68, this functionality is disabled by default and can be activated by setting kblessctrlspecialclickcheck_1=True in the *.ini file.

Since version 2.63, you can show or hide the transport bar by clicking four times in sequence in the lower middle area of the AnyQuest main window during questionnaire presentation. Since version 2.68, this functionality is disabled by default and can be activated by setting kblessctrlspecialclickcheck_2=True in the *.ini file.

Since version 2.63, you can enable or disable pc speaker sound signals immediately by clicking four times in sequence in the lower right area of the AnyQuest main window during questionnaire presentation. Since version 2.68, this functionality is disabled by default and can be activated by setting kblessctrlspecialclickcheck_3=True in the *.ini file.

 If you like it, you can have the JMS-Rainbow displayed in the usual questionnaire background. You might also want try different background colours: You change them via the background's context menu or via the "Edit"-menu. Colours are stored with every questionnaire. This implies, that within a set of questionnaires, you can have individual colour schemes for each included questionnaire.

I regret that I have not any data about how quality-of-life results vary depending on different background and foreground colours, on the JMS-Rainbow or on sound yet. However, this might be a study which somebody might do using AnyQuest for Windows - the required software features are all there.

• The transport bar, simpler navigation buttons, the "Continue..." button and anchors


The edit layout mode

The edit layout mode...

...lets you generate a new questionnaire definition file, or change the layout of an existing one.

Using the transport bar, which is always there when you are in the edit layout mode, you can step through the questions forwards and backwards. Context menus are active in this mode, so things can be added, moved, coloured, selected, otherwise edited and finally deleted again.

If the edit layout mode is activated, you can see the filename of the questionnaire which is currently being displayed in the caption of AnyQuest's main window. There is an indicator to show you, whether you have modified this questionnaire since you last saved it, as well.

If the edit layout mode is activated, above each answer field, you can see its number within the sequence of answer fields of the current question, and its numeric or text value and indicators for some of the options that may be set for this answer field.

After you have made changes to any loaded questionnare definition, AnyQuest for Windows will usually remind you to save the edits (into the original file, or into a new file) when you would otherwise lose them by ending the program or otherwise clearing a questionnaire definition.

While the edit layout mode ist activated, no Automatic check, calculation, output & erase after the last question will occur. I chose to program it like this because accidentally hopping over that border all the time - what I did · - might become a bit annoying when you want to concentrate on editing your layout.


The editing grid

The editing grid...

...allows you to quickly arrange your questionnaire elements horizontally and vertically, by aligning them to a grid automatically or manually.

The grid has been introduced in version 2.73. Initially, it could be operated only via keyboard commands. Since version 3.33, respective menu entries are available in the "Edit" menu as well:

g1 	grid resolution 10 pixels

g2 	grid resolution 20 pixels

g3 	grid resolution 30 pixels

g4 	grid resolution 40 pixels

g5 	grid resolution 50 pixels

g6 	grid resolution 60 pixels

g7 	grid resolution 70 pixels

g8 	grid resolution 80 pixels

g9 	grid resolution 90 pixels

g0 	grid resolution 100 pixels

gs 	grid show on/off

go 	grid oorigin screen center/top left

gl 	grid lock on/off

rcg 	qestionnaire coordinates round to grid resolution (affects all elements of a single questionnaire)

qcg 	qestion coordinates round to grid resolution (affects all elements of a single the question)

Please review additional information regarding keyboard commands here. Especially note the commands to align answer fields individually, because this may be necessary after automatic grid alignment operations. Also note that you may use Question options to automatically re-size and re-distribute answer field scales after they may have been pressed into a grid that did not fit them well.

The grid is only visible in edit layout mode; you can show or hide it with the keyboard command sequence gs.

If the grid is shown, an additional pair of blue dashed lines marks the horizontal and vertical center of the available screen. Red dashed lines mark the 25% and 75% locations. The grid resolution can be selected by the keyboard commands keyboard command sequence g1 (10 pixels) through g9 (90 pixels) and g0 100 pixels. Please note that the actual number of grid divisions that fit your screen depend upon your screen resolution. I recommend to generally use a resolution of 1024x768 with hidden task bars as a standard for editing, if possible.

In order to use the grid for alignment purposes, it needs not be visible.

The origin of the grid can either be aligned with the center of the available screen, or with its top left corner, using the keyboard command sequence go. Generally, you should prefer alignment with the screen center if you want to use centered questionnaire elements.

If you want to align elements to the grid, you may either use the keyboard command sequence qcg (question coordinates round to grid) to align all elements of the currently displayed question to the current grid resolution, or use the keyboard command sequence qcg (question coordinates round to grid) to align all elements of the currently displayed questionnair. In any case, results of automatic alignment will most probably need review and manual editing afterwards: typically, answer fields previously distributed in equal intervalls before such an operation might be distributed unevenly afterwards as a result of the rounding and automatic alignment process. Moreover, answer fild labels previously centered with respect to an answer field might be off center afterwards for the same reason.

However, even if elements may not be distributed perfectly after an automatic grid alignment, their edges are at least located on the grid, and that means, that elements whose positions were a few pixels (but not easily visibly) different before, are either visibly regularly arranged (on exactly the same x- or y-position in the grid, of the same size in the grid) or clearly visible irregularly.

After automatic grid arrangement, you may either use functions like Question options to automatically re-size and re-distribute answer field scales and labels, or you may use the keyboard commands lth, lal, lar, laa, lab to arrange these items individually.

Moreover, you can use the keyboard command gl to activate grid locking mode. In this mode, the mouse pointer will stick to the grid when you move selected elements or resize them by dragging the handles of the selection frame. This function has been implemented in a special way that will make it easy to drag borders newly onto the grid, and having done that once, also to move objects in grid resolution distance steps.

The grid functionality is certainly a feature that speeds up the layout of good looking questionnaire definition files enormously.


The size of text objects

For every displayed text object in a questionnaire, AnyQuest stores its position. The term "Position" refers to a rectangle, which may be bigger or smaller, than the space which the text of a given object might require.

In the "Edit" menu, there is an option "Show text rectangle size". If it is checked, the rectangles of all text objects are displayed in the edit layout mode.

Normal mode - bounding rectangle rules over text

Normally, text of a text object is displayed within its allocated rectangle. If the text doesn't fit in a single line, it is broken into multiple lines. If the rectangle is too small to display the text, only the part located inside the rectangle is displayed.

You can choose whether text of a given object is aligned left, centered, or aligned right within its allocated rectangle.

Alternative mode - text rules over bounding rectangle

There is a second mode of operation, "Auto adjust text rectangle size". If this is checked, then the rectangle of a text object is automatically adjusted to fit the text it contains. If necessary, the horizontal size is modified in a way which preserves the texts position, respecting its selected alignment mode.

The adjustment of the size rectangle, however, only occurs when an edit box for such an object's text is opened. (Even if you cancel the text edit, the size of the rectangle will be adjusted in this version of AnyQuest for Windows.)

Be careful!

As long as you don't have the size of the rectangles adjusted automatically, a single line of text will be broken and word-wrapped to fit into a given rectangle. However, if the size of a rectangle is adjusted to fit a given text, then a text object with multiple lines will only result, if the text contains line breaks.

This is the reason, why not all text boxes are adjusted automatically, when you turn the option on: In this case, you could destroy the layout of a questionnaire which relies on the size of its text rectangles by switching to the automatic rectangle size adjustment.


Line breaks

Text objects can contain multiple lines: either, they are broken automatically to fit into their bounding rectangle, or you can insert a linebreak manually by typing Ctrl-Enter at any position within the text.

You need to use Ctrl-Enter. Typing just Enter would not insert a line break, but close the text input dialog window instead.


Electronic questionnaires

Electronic questionnaires in AnyQuest for Windows

AnyQuest for Windows is a generic platform to present electronic questionnaires to patients (or other candidates) who require no training to use it.

For this purpose, AnyQuest can load one or multiple questionnaire definition files:

Each questionnaire definition file can contains a series of InfoScreens (which cannot be answered, like the introduction at the beginning of a questionnaire), and questions (which can be answered). Preferrably, questions are aranged to be presented one after another, in order to increase readability and simplify the handling for patients.

Each InfoScreen or question can contain a variety of objects; namely question text, explanation text, answer fields, and answer field text. All objects can have bitmap images (e.g. to display smileys as answer fields) and wave files (e.g. to make a talking or a musical questionnaire).

Moreover, a questionnaire definition can contain result computation formulas (which control scoring, generation of result files, and printouts), conditional branching formulas (which control non-linear ways through questionnaires or dynamically changing questionnaires), and text inline formulas (which control dynamically changing text as well). These formulas and other, specialized mechanisms, also enable communication with external data sources, targets and processors.

AnyQuest includes an editor for electronic questionnaires. Designing or modifying such a questionnaire definition file is accomplished by manipulating objects which appear on the screen.

A questionnaire definition file can, however, also be saved in a plain text format resembling a sequence of statements that will construct a questionnaire. This file can be edited with a text editor, and all of that file or individual portions can be "executed" - thereby, working electronic questionnaires can be built from simple text files, or even synthesized by external software (like an item-bank database application).

Thus, AnyQuest allows you to reproduce the contents and the layout of a large variety of paper questionnaires.

At the same time, it adds features like automatic data checking, processing, standardized storage and immediate availability of computed test results, interactivity, as well as colours and sound.

Beyond the questionnaire definition file, optional extenal programs, control files and reference data files can customize the data processing, appearance and the content of printouts to some good extent:

The inclusion of your logos is possible as well as arranging results in multiple sections, inclusion of simple or complex reference indicators which may be static, dynamically computed on the fly, or selected according to properties of the current candidate. Custom text, like footers with staff instructions and space for a signature to aid in process management can also be included.

Automated and interactive statistical analysis tools and data export facilities are included in AnyQuest as well: A few clicks can export all collected data to another statistical or mathematical software package - even if they were obtained from multiple centers, with various questionnaire definition files.

Automated data export and several analysis functions can work even while the original questionnaire definition file is not available. The delayed creation of certain printout types, and certain specialized other analyses, however, may require the original questionnaire definition file because they use the printout labels defined therein.

Finally, AnyQuest enables you to prepare multiple configurations on the same system. These may address different patient groups, different languages, or different studies. The configuration file controls - naturally - the questionnaire definition files to be used, the appearance and behaviour of the startup screen and the main program as well as the availability of various options, message files, patient-id collection, some aspects of printing and communication with external software and many other aspects.


Adding objects and using prototypes

To add an object (starting with a new questionnaire, if nothing is there), click the secondary button within AnyQuest's main window to get the context menu of the background. Select the object you wish to add.

An object can be "added" after the current object or "inserted" at its position in the sequence of objects of the same type stored in memory.

When a new answer field is added, AnyQuest for Windows copies the position of the new answer field from neighbouring questions, or it extrapolates the position of the new answer field from the positions of the last two preceeding answer fields of the same question, if available.

When adding questions, the formula consistency check is a useful feature.

If you want to copy or clone a question, you can select it via "Edit" - "Set prototype question". If one question is selected, new questions will appear in a layout that resembles this question, and new answer fields will as well. You can use that option even to copy question layouts across questionnaires. So you will not need to arrange any individual question layout manually more than once.

In addition to adding objects individually, you can import them from either regular *.qdw questionnaire definition files or generate them through special *.qdt files. Please read explanations of the respective commands from the file menu before you use them.

Since January, 2001, a file c:\anyquin\questns\demo\prototyp.qdw is available. It includes prototypes for numerous question layouts and should speed up your questionnaire construction enormously.


Selecting objects

Many actions can be performed on objects through their context menu without selecting them first.

However, there are some actions which can only be performed on a selected object or on a group of selected objects. Among others, these include moving an object, changing of the size it is allowed to occupy and aligning multiple objects.

Objects can be selected in the edit layout mode only, and only the selection state of displayed objects can be changed.

You can change the selection state of displayed objects using different methods:

Generally, you position the pointer over an object or a number of overlapping objects and then press the first button of your pointing device.

If you are not holding down any key:

Only one object will be selected

All other displayed objects will be deselected.

If you are holding down the Shift-key only:

All objects currently pointed at will be selected.

All other displayed objects will deselected.

If you are holding down the Ctrl-key only:

Only one object will change its selection state.

All other displayed objects will not be affected.

If you are holding down the Ctrl-key and the Shift-key together:

All objects currently pointed at will change their selection states.

All other displayed objects will not be affected.

To deselect all objects, position the pointer over a part of the background not occupied by any object and press the primary button without holding down any key.

When at least one object is selected, you will see a selection frame including all seleted objects. A display in the left lower corner tells you: how many objects, coordinates of the corners of the frame, coordinates of the midpoint of the frame.

The selection frame has handles which allow you to modify the size these objects may occupy by dragging the handles to another position. You can also drag the whole selection frame to modify a selection's position without affecting its size. Further, a selection has a different context menu than its individual components. It allows you to perform actions which can affect all selected objects.

Note: In some cases, not all options of context menus of individual objects are available in the context menu of a selection.

Selected objects keep their selection state even when you switch to different questions or questionnaires. You can come back later and admire your unchanged selection frame. In fact, you can even save it with your questionnaire


Manipulating and cloning objects

Objects can be almost anywhere on the screen.

To move an object, select it first and then drag it to another place. Drag the selection handles to redefine the space an object can occupy.

In the context menus of an object or of a selection, there are "Position" commands to align multiple selected objects. Further, there are commands to copy positions (or only the size) to or from objects in a question, between questions or to all similar objects in a questionnaire.

Each question has information about default values for properties of its answer fields. If you activate a question's context menu and select "Options...", a window appears that lets you define the type of the answers. Further, you can specify a default radius and default distance of the answer fields from each other as well as the distance and positioning of answer field labels. These controls can be very helpful to arrange answer fields and their labels semi-automatically.

If you copy the position of an object onto another one without moving the first one somewhere else first, they will occupy the same position. In this case it might be useful to know about the different possibilities to select objects.

Note: If you copy a position, or text, to any answer field or to any other text item, by commands that might affect multiple items at a time, parameters will typically only be copied between corresponding items. For example, suppose you have multiple questions, which have 6 answer fields each. If you change the position/size of the first answer field of the first question, and then use "copy position to all similar answer fields", this will affect only the position of each first answer field of all remaing questions, and it will not affect the position of any answer field of any question that has more or fewer answer fields. The other three answer fields will remain unaffected. Questions marked as "Infoscreen" will usually not be affected as well, when you transfer parameters from real (i.e. not Inforscreen) questions.

If you want to copy or clone a question, you can select it via "Edit" - "Set prototype question". If one question is selected, new questions will appear in a layout that resembles this question, and new answer fields will as well. You can use that option even to copy question layouts across questionnaires. So you will not need to arrange any individual question layout manually more than once.

Since January, 2001, a file c:\anyquin\questns\demo\prototyp.qdw is available. It includes prototypes for numerous question layouts and should speed up your questionnaire construction enormously.

Using the menu entry "Edit" - "Set anchor question", and the menu entries "Edit" - "Jumpt to prototype/anchor question", you can navigate to and fro between a prototype and a target (or other) question very fast.

In addition to manipulating objects inside AnyQuest for Windows through its graphical interface, you can generate a *.qdt file from any questionnaire definition, which can be manipulated with a text editor. Such a file contains human readable commands. If they are executed inside AnyQuest, they can build most items of a questionnaire. Please read explanations of the respective commands from the file menu before you use them.


What kind of objects are there?

Objects are the items you manipulate to design or modify an electronic questionnaire.

A questionnaire definition file contains information about the following objects:

•	The questionnaire itself, which contains all other objects.

•	The long questionnaire name, one per questionnaire.

•	The short questionnaire name, one per questionnaire.

•	Questions or Infoscreens max. 16383 per questionnaire.

•	Explanations, one per question.

•	Explanations #2, one per question.

•	Answer fields, max. 16383 per question.

•	Formula definitions, max. 16383 per questionnaire.

There are two additional objects:

•	The background, which can have a seperate colour with each questionnaire.

•	The JMS-rainbow, which is nice to look at :-).

Most of these objects are can be displayed and moved to different positions within AnyQuest's main window.

Properties like the text, position, background bitmap, associated wave-file of an object can be modified for each individual object. Other properties, like colour and font, can only be modified for a class of objects within one questionnaire. E.g., although you can label one answer field with the text "good" and another with "bad", all regular answer fields within the same questionnaire will appear in the same colour and font.

Most of the objects mentioned above can be enabled or disable for all loaded questionnaires via the "Display"-menu. Apart from some exceptions, only objects which are being displayed can be manipulated.

Using my Questio-Morph-o-Matic, text allocated to objects can even change dynamically during questionnaire presentation.

Is there anything else?

There are also items which do not belong to an individual questionnaire definition, e.g.:

•	A configurable navigation dialog allowing you to start a questionnare administration comfortably.

•	Built in screens for collection of patient identification data and study meta information data.

•	The transport bar or "Continue..." button used for navigation.

•	Dialog boxes appearing in various situations to give some information to the patient or to collect additional information.

•	Dialog boxes allowing you to interrupt, abort, save and resume questionnaire administrations, or to record brief notes at any point during a questionnaire administration.

•	A thank-you box appearing when a patient has filled in a questionnaire.

The text content and fonts of many of these items can be controlled through configuration files *.ini and message files *.msg.

AnyQuest can also call external programms and communicate with them at any point in time during questionnaire presentation and during computation of results. Integrating suitable external programs, you can make anything appear or happen whenever you like.


Question options

Selecting "Options..." from the context menu of a question, you can open a the "Question properties..."-dialog box to change the following:

Question type

There are different types of questions resulting in different behaviour of their answer fields. The following table tells you how a question's numeric result is generated from the different types of answer fields and how they behave if they're checked:

Discrete single: the numeric result will be the numeric value of the checked answer field.

It will be undefined if no answer field is checked.

Checking one answer field will remove checks that might be present in another one, and checking a checked answer field again will remove the check from this field.

Discrete multi: the numeric result will be the sum of the numeric values of all checked answer fields. It will be undefined if no answer field is checked.

Checking one answer field will not affect checks that might be present in other answer fields, but checking a checked answer field again will remove the check from this field.

LASA/VAS: the position of the numeric result between the numeric values of the extreme answer fields will be proportional to the position of the check-mark on a line between these answer fields on the screen. It will be undefined if there is no check-mark.

AnyQuest for Windows supports Jörg M. Sigle's multi-segmented non-linear Visual Analogue Scales: They can be built from more than two answer fields with different numerical values.

Checking a another position on a scale whith a check previously set anywhere on it, will move the existing check to the new position.

Infoscreen: A question can be marked to be an infoscreen. This means that it is ignored while checking for completeness, it does not appear in the raw data section of the output file, it's checked answer fields are not cleared when an empty set of questionnaires isprepared, and no patient can check or uncheck its answers. However, all of its visible objects appear on the screen, and its digitized sound appears through the speakers as usual. So it can be used to display different kinds of information.

For example, you can arrange its answer field labes anywhere on the screen and fill them with quite a lot of text to generate a first page with instructions before a questionnaire starts.

If you don't want the answer fields to appear on the infoscreen themselves, you can use a largtside the visible area. However, if you leave them on the screen you can even display an example how to check an answer. Recall: Checks are saved and loaded with a questionnaire template, and the patient can't change them on an "Infoscreen".

Questions of this type don't appear in the output file. Still, they are counted in the on-screen question number and they also have to be taken into account when specifying the question numbers to generate results from in the result formula edit dialog.

Whenever an Infoscreen is displayed, and the transport bar is not activated, a button labeled "Continue..." is automatically displayed. This enables the patient to the next question when he has finished reading the infoscreen.

Answer field defaults

Here you can enter default values for the arrangement of answer fields belonging to the question. Clicking any of the buttons belonging to this topic will re-arrange them or their labels, which can save you from trouble caused by putting too many of them on top of each other... :-)

You can also use these functions to generate horizontally or vertically arranged series of fields conveniently since version 2.20. Applying them only to selected fields allows you to generate multi-column arrangements, and it may be helpful to temporarily deactivate the display of any other elements while creating such an arangement.

It can be specified, whether thes buttons only affect regular answer fields or even special answer fields.


Colours and fonts

Colours and fonts...

...can be changed through dialogs for most items. They are defined with a questionnaire, not with every single question.


Text, numeric and text values, images and digitized sound

Text, numeric and text values, images and digitized sound...

...can be defined with each item, if applicable. Text and numeric values are edited through a text edit box. As in any edit box, the selected characters are replaced by the next one you type.

If you wish to translate a questionnaire, there are helpful functions to manipulate multiple objects alike.

I suggest you to code answer fields using numeric values. However, from AnyQuest for Windows version 2.25 on, you can use text values which can be processed and transferred directly into the output files.

Please read the sections on defining result formulas to learn how you can define how coded values shall be processed.

For input and display of numeric values of answer fields, the internationally different decimal separators are supported - and have to be used. (In this release, they are the only fields to support this.)

Digitized sound can be linked to most text objects via their context menus and to certain events via the "Sound"-menu.

Bitmap images can be linked to most objects (including the background of each question) via their context menus, too.


Digitized sound

Digitized sound...

...can be defined with most items which include text. Additionally, some sound files can be assigned to certain events, e.g. displaying the input screen for the first name can be associated with a sound file asking the patient to do so. (In a future version, sound files can optionally be repeated automatically after some time, if there hasn't been any input, and more events will receive sound support.)

Sound files are played asynchronously, if your hardware is capable of doing this. This means that AnyQuest for Windows can receive input while a sound file is still being played.

Sound files in the *.wav format for digitized sound can be recorded with the Windows wave-file-recorder or with the software that came with your soundcard. You'll need a microphone and speakers, though. As AnyQuest for Windows just plays digitized wave-files, and as most of the contemporary soundcards come with an ADC/DAC which is far better than their NF-section, you can either use a really cheap one or go for real HiFi!

ADC = Analog to digital converter, usually up to 16 Bit, 48 kHz, stereo

DAC = Digital to analog converter, usually up to 16 Bit, 48 kHz, stereo

NF-section = Niederfrequenz, German for low frequency = the analogue parts of a soundcard including filter, mixer, amplifiers and electrical noise from the neighbouring microprocessors or connected CD-drive cables.

For Windows 3.1, there is a driver (speaker.drv ) which enables the PC-speaker to output digitized sound without a soundcard. It gives a rather poor quality, but this depends on the speaker, and definitely it is better than nothing.

At the resolution reported above, one second (1 s) of uncompressed sound will result in almost 200 KB of data. The reported thoughts lead to the suggestion, that for recordings of a voice reading questions and answer possibilities, which will be the most common ones used with AnyQuest for Windows, 16 Bit, 22 kHz, mono (44 KB/s uncompressed) might certainly be sufficient in most environments.

(Voice is said to require frequencies up to 5 kHz, so according to the Nyquist sampling theoreme (translation?), 11 kHz are sufficient to reproduce it. Still, my experience says that using higher sampling frequencies adds more clarity to a recording, making it more pleasant to the ears. · )

In any case, it might be a good idea to try different sound qualities and to look at the disk-space occupied by the sound files as well as the speed of the computer. Using compressed formats can result in saved disk space. In any case, you can always record the title theme for your questionnaire collection in CD-quality HiFi-stereo...


Images

Images...

...can be defined with most items.

Each text item can have its image file which will work as text background. If the text is empty, only the image will be displayed.

Additionally, you can display image files which replace answer fields and you can define one image file as AnyQuest for Windows background for each question. If bitmaps are linked to direct text edit fields, they appear as frames of 2 pixels width.

All image files must be prepared as Bitmap (*.bmp) files with appropriate software. You can use scanned images (i.e. photos) as well as electronically prepared logos or background colour arrangements.

Upon display, image files are stretched to the size of the target object.

The quality of displayed images depends upon the display hardware you use. For photos, it should be capable of displaying 65.000 colours or better. The necessary resolution depends upon the size of the images you wish to display.


PC speaker sound

PC speaker sound...

can be associated with some events like checking an answer field, displaying an error box or saying "Thank you". There is a submenu in the "Sound" menu to enable or disable sound with these events individually.

PC speaker sound speed might depend on the system (and on the version of AnyQuest) your're using. Some sounds might get slower on 486DX33 and below based PCs. The speed may vary, if the computation speed of your machine varies, e.g. when it is slowed down by energy saving mechanisms.

The standard PC speaker signals are composed of different alternating frequencies, being quite loud and distinctive so that especially elderly people with limited hearing capabilities can recognize them well.

However, they may get annoying if you have to listen to them all day long. So I added the so called "PC speaker simple sounds". They only consist of two tones per signal, and you can configure the duration and the frequency of each of the two parts. As in the usual PC speaker sound, there are three types of signals for different occasions which can be controlled individually.

Since version 2.63, you can toggle the normal PC speaker sound by clicking four times in sequence in the lower right area of the AnyQuest main window during questionnaire presentation. Since version 2.68, this functionality is disabled by default and can be activated by setting kblessctrlspecialclickcheck_3=True in the *.ini file.

Since version 3.35, you can toggle PC speaker sound feedback of typing keyboard shourtcuts for questionnaire editing commands via the menu option "Sound" - "PC speaker keyboard edit control".


Deleting objects and clearing text

To delete an object, just open the correspondend context menu, think and then select delete. Don't forget to think, because there won' t be a dialog window asking you to press "OK" or "Cancel"...

Trying to do it with a selection, you will only be able to delete multiple answer fields of a given question, cause it would be redundant to delete selected answer fields AND the question or the questionnaire: just delete the latter and all associated answer fields will disappear.

Clearing an object's text is different: it only clears the characters displayed. Remember where an object was, because you won't see it anymore afterwards (This will be changed for the edit layout mode of future versions). Use this feature for example to clear answer fields' labels individually or to produce a single question without an explanation. Of course, you can add new text to the object later on.

When deleting questions, the formula consistency check is a useful feature.


Question numbering and the output file data format

When defining a UPN formula for a given questionnaire, using the V or C commands you have to take into account every single question in that questionnaire, even if it is declared to be an "Infoscreen".

In the output file, "Infoscreens" won' t be counted, and question numbering within the output file raw data section will always start from 1 for each questionnaire which was included in the set of questionnaires from which the output file is derived.

A single output file will contain data from all questionnaires scheduled in a single session, and it has a standardized data format. This data format is discussed in the documentation of AnyQuest for MS-DOS and will be described in further detail in the documentation of the final version of AnyQuest for Windows. The data file generated by AnyQuest or Windows is only slightly different to the one generated by AnyQuest for MS-DOS.

Here, I' d only like to mention that results are stored in fully self-explaining ASCII files, which are easily printable and readable (even without documentation) and transferrable to any computer platform. Apart from other captured data, each questionnaire scheduled within a single session has its own block, which itself includes raw data and computed results.

The results generated from each questionnaire can be defined in the result formula definition dialog. However, the fileformat is not completely free: it is ensured that the output file will comply with the defined standard in any case.

To get an impression, you may look at an output file generated after the completion of any questionnaire. It will have a number as filename with the extension ".ANQ" , e.g. 00000312.ANQ.

Data from many output files can be exported and put into a single file to be imported by Microsoft Excel, Microsoft Access, dBase, Spida, SPSS, SAS or many other programs. Using these commercially available programs, you would carry out further data analysis.

However, be sure to keep your original *.anq files, as they are intended to serve as a standardized means of storing quality-of-life data with guaranteed, platform- and software-independent exchangability and readability.

There is some further information available:

*.anq output file options...

Detailed description of the output file format of AnyQuest for Windows *.anq files

Differences between *.anq files from AnyQuest for MS-DOS and AnyQuest for Windows

Hints for writing import routines into third party applications

Communication with external applications, including UTF8 - ANSI character conversion


Glossary

Glossary - Nomenclature

A "questionnaire" refers to a collection of questions, possible answers, formulas for data evaluation and additional information, all belonging together, and being designed to retrieve some information from a person.

A "module" refers to a questionnaire which is designed to be used as an extension to another questionnaire. Usually, you would apply a core questionnaire and add one or more specific modules for specific patients (i.e. a breast cancer module for patients with breast cancer).

A "*.qdw file" is a file that holds one complete questionnaire definition for AnyQuest for Windows.

A prepared "set of questionnaires" can be specified in an "AnyQuest configuration" which defines all *.qdw files to present together with the patient identification options to ask for and other options that determine AnyQuest's behaviour.

A "session" refers to the process of collection of information from a patient by letting him use AnyQuest for Windows. It includes entering the patient identification, answering all necessary questions of all prepared questionnaires, and some processing done by AnyQuest.

A "destination directory" is a directory specified in an "AnyQuest configuration" where output files are to be stored.


*.anq output file example

Example of an *.anq output file

Please resize your help-window large enough to view this example completely.

SC-JMS AnyQuest for Windows V 2.34 © 1996-2001 Jörg Sigle, http://www.jsigle.com

[AnyQuest license]

The copy of AnyQuest for Windows which generated this file was licensed to:

AQ license 1: Unlicensed evaluation version.

AQ license 2: Not for regular use.

[patient identification]

group/pid:     28A124AX

name:          DOLCIANA DE LA VERITACIU

date of birth: 24.02.1965

computed age:  34.237 Years

[time stamp]

date of test:  17.06.1999

start time:    21:31:37

end time:      21:32:04

delta time:    00:00:27 (valid only if start and end timed on the same day)

[QOLD5 = Quality of Life questionnaire demo with 5 questions]

[QOLD5 meta information]

QOLD5 number of questions:        6

QOLD5 number of result formulas:  4

QOLD5 result formula 1 bar min:  0.00000000000000E+0000

QOLD5 result formula 1 bar max:  1.00000000000000E+0002

QOLD5 result formula 2 bar min:  0.00000000000000E+0000

QOLD5 result formula 2 bar max:  1.00000000000000E+0002

QOLD5 result formula 3 bar min:  0.00000000000000E+0000

QOLD5 result formula 3 bar max:  1.00000000000000E+0002

QOLD5 result formula 4 bar min:  0.00000000000000E+0000

QOLD5 result formula 4 bar max:  1.00000000000000E+0002

[QOLD5 raw data]

QOLD5 question nr. 1:  7.50000000000000E+0001

QOLD5 question nr. 2:  5.00000000000000E+0001

QOLD5 question nr. 3: --- ¬Can

QOLD5 question nr. 4:  7.50000000000000E+0001

QOLD5 question nr. 5:  7.50000000000000E+0001

[QOLD5 additional text information]

QOLD5 text input to qn nr. 3.6: Sorry, I did not have any treatment.

[QOLD5 computed test results]

QOLD5 Social function:  62.50 Units

QOLD5 Pain control:    --- Units

QOLD5 Appetite:         75.00 Units

QOLD5 Overall QOL:      75.00 Units

[end of file]


Detailed output file data format

Detailed description of the output file format of AnyQuest for Windows *.anq files

Please read this nomenclature first.

General remarks

AnyQuest produces one output file from each completed session. This output file is located in a directory which can be specified when preparing an AnyQuest configuration.

The output file has the filename extension .anq. The filename itself is generated automatically. Applicable rules can be specified using the menu "File" - *.anq output file options....

Here is an example of an *.anq output file. (If you wish, you can print it or open another instance of this help file viewer and place it near this one to view the example while you continue reading this description.)

Here are hints for writing import routines into third party applications.

General structure of the output file

The output file is a plain text file. It uses the ASCII character set, with possible extensions based on the codepage currently used by an actual system (i.e. Microsoft code page 1252 ANSI Latin, or ANSI Latin-1, or even UTF8 etc. for content accepted from external software). It contains lines which are separated by CR+LF. Most questionnaire definition files with pure numerical output can be designed to require less than 255 characters per line, but there is no defined maximum length of each line. This is relevant if lengthy text input shall be processed.

The output file can be viewed or edited with most available text editors. It can be printed (or copied) directly to a simple PC printer. It can be transferred to other platforms and communicated, e.g. via e-mail and the Internet, but you should not forget to use data encryption if appropriate.

The first line of the output file identifies the software which generated it, including its revision.

The rest of the output file is organized in separate sections.

There can be empty lines at any place in the file (usually after each section identifier and after each block of data to improve readability). They should be ignored.

Variable names and values

Most sections contain lines of information. Each line of information has the general format:

variable name:  value

Please note that the only fixed item is the separating colon. The number of spaces between the colon and the value is variable to support easier readability of the file for humans; generally, all of these spaces should be ignored.

If a section is related to one questionnaire, the short name of that questionnaire is included and its lines of information have the format:

qnr_short_name variable name:  value

Some lines can contain units, too:

variable name:  value unit

qnr_short_name variable name:  value unit

There will always be one space between the value and the unit. If the unit is an empty string, there will be one space after the value, though. There are no restrictions to the contents of the unit, but generally it should be short and should not contain spaces.

Section identifiers

The beginning of each section is identified by a line that begins with the character [ and ends with the character ].

The type of a section is identified by the contents of this line.

If a section is related to one questionnaire, the section identifier contains the short name of the questionnaire directly after the leading [.

The first section identifier within the file that is related to one questionnaire contains its short and its long name, separated by  =  (including one space left and right of the equal sign)].

If one file contains data from multiple questionnaires that were applied in a single session, all sections related to the first questionnaire are written first. Then comes another section identifier with short and long name of the second questionnaire, followed by all sections related to the second questionnaire and so on.

Contents and format of individual sections

Currently, there are the following sections (please view this example!):

[AnyQuest license]

If a personalized version of AnyQuest for Windows is used, the person or institution to whom it is licensed is written here.

The number of lines included in this section may vary. If a *.lic license file is available, that can be edited to select the lines to be included from all licensee description lines available therein.

These fields will usually also be included in a data export file (when AnyQuest for Windows' built in data export functionality, or a usual setup for the extract tool are used).

If multiple users put their *.anq files into the same folder, and then generate a data export file, entries from all contributing users will be shown. They can be used for example to identify the origin of each reported case.

[patient identification]

This section contains all data collected to identify a patient or the current rater, therapy cycle, measurement etc. All information is optional; its collection is controlled mainly through the menu "Navigation" - "Patient identification options to ask for...".

If a special font or character set has been used to collect patient identification data, AnyQuest for Windows will insert two lines with PID Collection FaceName  and PID Collection CharSet. For example, the character set 161 consists of an ASCII-like lower half and a Greek upper half. The Greek characters cannot be shown correctly in the ASCII file, but external programs may use the supplied facename (Arial) and character set (161) to use the right font to display them correctly.

If patient ID data has been accepted from external software, characters may have been supplied in the *.pid file in character sets that AnyQuest for Windows cannot handle itself, e.g. UTF8. These may be passed through to the *.anq file unchanged, or automatically converted upon reading them from the *.pid file. As of version 3.66, built in basic conversion functionality is available between UTF8 multibyte and ANSI single byte characters; see the section on external software for details.

Even if group/pid, name, date of birth are not collected, the variable names are written followed by the separating colon and empty strings.

If the date of birth is not collected, and the computed age can therefore not be computed, it is written as "---" or the string specified for an undefined result in the first available result formula in the loaded set of questionnaires.

The variable group/pid can contain any string that is usually collected as patient identification code.

Since version 3.53,

a button "Auto" can be displayed on the PID collection dialog. If this is clicked, AnyQuest for Windows automatically generates a PID that has not been used before in the data files it can currently see. The button is controlled by the option ShowAutogenPatientIDButton in the *.ini file. Currently, a 6 digit numerical PID is generated. Internally, options have been provided to specify the number of digits, charset and prefixes to be used, but these have not been linked with any *.ini file or menu options so far. The button may not be available in all custom versions of the AnyQuest for Windows program, because it must be provided in the respective ressource file definitions.

The variable name contains strings that are usually collected as first name, given name and simple name (which is usually collected alternatively to first + given names), separated by one space.

The variable date of birth contains the string collected as date of birth. If collected through the built in patient identification collection dialog, this has been checked for a correct format and for being prior to the day when the session took place. It will then be formatted as DD.MM.YYYY. However, there are some possibilities to collect unformatted or differently formatted information into this value. Since version 2.82, the desired date format for dialogs and printouts can be set in the *.ini file like in this example.

Since version 2.82, if DateFormatDialog is set to 0 (=DateFormatDDMMYYYY), AnyQuest's validate_date function will accept ddmmyy, ddmmyyyy, dd.mm.yy, dd.mm.yyyy, d.mm.yy, d.mm.yyyy, dd.m.yy, dd.m.yyyy, d.m.yy, d.m.yyyy, dd-mm-yy, dd-mm-yyyy, d-mm-yy, d-mm-yyyy, dd-m-yy, dd-m-yyyy, d-m-yy, d-m-yyyy. If DateFormatDialog is set to 1 (=DateFormatYYYYMMDD), AnyQuest's validate_date function will accept yyyymmdd, yymmdd, yy.mm.dd, yyyy.mm.dd, yy.mm.d, yyyy.mm.d, yy.m.dd, yyyy.m.dd, yy.m.d, yyyy.m.d, yy-mm-dd, yyyy-mm-dd, yy-mm-d, yyyy-mm-d, yy-m-dd, yyyy-m-dd, yy-m-d, yyyy-m-d. In either case, it will return the validated date as dd.mm.yyyy, which is also consistently used in *.anq files.

Additional patient identification related data can be collected, including address, phone, fax and so on. The respective options can be set via the Navigation menu or *.ini configuration file entries, or be supplied from an external application through a *.pid file. Only if they have been collected, respective lines will appear here.

A case ID number can also be collected; there is a prototype setup that demonstrates collection of only a case ID via barcode scanner, with AnyQuest for Windows calling an external interface program right thereafter, that contacts an external MySQL database (many others would be possible) and fills in all remaining information retrieved by supplying the case ID.

If the date of birth has been collected, the variable computed age will contain the age of the patient in years when the test was performed, computed for convenience with a resolution of less than 1 day. (Sorry, I do not guarantee for perfectly correct calculation, but it should be sufficient to compute correlations between collected data and age.)

As of version 3.64 (and for many versions before), the initials from the fields first name and last name, and 5 digits from the field group/pid are used for printjob names for printouts automatically generated after the end of a questionnaire administration session.

[time stamp]

These variables contain information about when a session took place and how long the patient needed to fill in the set of questionnaires.

The date of test is coded as DD.MM.YYYY, relying on the internal clock of the machine.

The start time and end time are coded as HH:MM:SS, relying on the internal clock of the machine. "Start" is timed when the patient checks the first question (this means: patient identification is not timed; neither are leading infoscreens.). "End" is timed after the last displayed question has been checked, completeness has been checked and before results are written to disk and the Thank-You-Box appears.

The delta time is coded as HH:MM:SS, too, followed by a remark concerning its validity. It is not valid, either, when a session was interrupted and resumed later.

As of version 3.64, the timestamp used for printjob names is generated from the date of test and start time fields for printouts automatically generated after the end of a questionnaire administration session.

[QOLD5 = Quality of Life questionnaire demo with 5 questions]

A line like the one above indicates that the sections of one applied questionnaire are going to follow. It contains the short and the long name of that questionnaire, separated by space equal-sign space. AnyQuest for Windows is not protected internally against using this code within the short name or long name, but no well designed questionnaire definition file should do that.

[QOLD5 meta information]

This is an optional section. It contains information related to the questionnaire that is useful for third party applications which cannot access or understand the underlying *.qdw file.

Currently, it contains information about the number of questions, number of result formulas and about the minimum and maximum values of each result as defined for the bargraph in AnyQuest's printout functionality.

[QOLD5 session log]

This is an optional section. It may contain information regarding interruption, aborting, saving, resumption, or just recorded comments regarding the questionnaire administration session. The number of entries depends upon the number of events that have been recorded during a session.

Generation of this session is configured via the "File" - "*.anq output file options..." dialog or via respective parameters in the *.ini configuration file.

[QOLD5 raw data]

For each question, this section contains the raw data.

If the question was of the type "VAS/Lasa-Scale", then the value will the numerical value calculated from the checked position on the scale as a linear interpolation between the numerical values of the adjacent two answer fields according to the distances of the mark to each of them.

If the question was of the type "Discrete answers, single check", then the value will reflect the text or numerical value coded to the selected answer field.

If the question was of the types "Discrete answers, multiple checks", then the value will reflect the concatenated strings or the sum of the numerical values coded to all selected answer fields. You can use bitmapping (decodable even within AnyQuest's result formulas) to identify individual fields from such a value, if you use numeric values like 1, 2, 4, 8, 16... for the individual answer fields.

If the value is really numeric, it will usually be written in an exponential format with extended precision within the raw data section. However, *.qdw-designers can decide to use text to achieve differently formated numerical values instead.

If the value is numeric, it should usually be free from spaces.

If the value is numeric and undefined, it is written as "---" or (for raw data) the string specified for an undefined result in the first available result formula in the loaded set of questionnaires.

If the value is the coded value of a special field for "I don't want to answer this question" or "I can't answer this question", it will be followed by one of the strings "¬Want" or "¬Can".

AnyQuest also supports the use of freely definable texts that can be affixed to individual answer fields (...because some applications required this. Originally, I had disabled that when moving from DOS to Windows...).

[QOLD5 additional text information]

If a user entered additional text input, either to an answer field that opened up an appropriate window after he checked it, or into a direct-text answer field, it will appear in this section. Otherwise (and regularly, for most simple applications), this section will be empty.

If it exists, each line has the format:

short_questionnaire_name text input to qn nr. question_number.answerfield_number: value

The question_number is given relative to the questionnaire, the first question (including infoscreens) is numbered 1.

The answerfield_number is given relative to the question, the first answer field is numbered 1.

The value is the text that was entered; it can be up to 32383 characters long. Special characters below #32 are re-coded to #149, so that line-breaks cannot occur.

[QOLD5 computed test results]

If result formulas are defined within a *.qdw file, the computed results appear in this section. Each result formula defines the variable name and the format of value and unit in a single line. Undefined numeric values are coded as the string defined in that result formula (preset: "---")

[QOLD5 computed test string results]

If result formulas are defined within a *.qdw file, computed string results may appear in this section. The variable names differ from the previous section by an additional "s" inserted between the short questionnaire name and the actual variable name.

The value may either contain detailed information in text form (like "Undefined" or "Stack overflow") corresponding to undefined results from the preceding section, or string results computed by special UPN statements, in parallel to the numerical results from the preceding section.

When string results are intended to appear on the printout, they may usually be prepared in the questionnaire language, and therefore, in contrast to the preceding section, return different content for different language versions of a questionnaire definition file.

[NQNR = Next Questionnaire]

[...]

If a file contains data from more than one questionnaire, the qeuestionnaire-related sections are repeated for the next questionnaire(s).

[end of file]

This line marks the end of the *.anq file. If you find it, the file was not truncated, e.g. by defective sectors or during telecommunication.


Writing import routines to third party applications

Hints for writing import routines into third party applications

Please read this nomenclature first.

General remarks

•	Verify that you have an *.anq file by checking the first characters of the first line: "SC-JMS AnyQuest".

•	If your import routine shall support the original QL-Recorder for MS-DOS, it should accept slightly different header lines from AnyQuest for MS-DOS.

•	Software version numbers may change quickly, so may my WWW-address.

•	You can give the user the option to cancel the import if that line does not match what you wish to be there.

•	It is often convenient to generate an import protocol for batch imports. This should identify the problem, the name and a patient identification of the concerned *.anq file.

Sections and data processing

•	Keep it as compatible as possible with all imaginable contents of an *.anq file.

•	However, most of the possibilities of the open *.anq format need not be supported for most purposes (e.g. support of more than 255 characters per line is not necessary to import general numerical questionnaire data).

•	You cannot make sure that all import routines work for all combinations that AnyQuest's *.qdw files can generate. But you can make routines that work for all *.qdw files made the way this help file (and common sense) suggests.

•	Search for the section headers you use. Ignore others, but let your software allow them.

•	Expect the first colon in a line to seperate variable name and value. Ignore the spaces which follow. If a *.qdw designer uses colons within file result labels, it is his fault.

•	Provide some intelligent processing of different possible numerical or text formats in the values. Usually, you can read in values as strings, then try to convert them to a numerical format which is internal to your destination application. If this does not work at all, it is probably a text. If it works up to a space (especially, the last one), it is probably number + unit.

•	You can include specific processing of different values for undefined numeric results, cannot, don't want and so on. If you need that.

Patient recognition

•	You can enter a patient identification code into AnyQuest which was generated by your destination application before.

•	You can enter a new patient identification code into AnyQuest and generate a new data set for that patient in your destination application. After user confirmation, if you wish.

•	Since version 2.39, AnyQuest can call an external application to check an entered identification versus any external source or to acquire patient identification data completely from an external source. If you do not use these features, you must not mistype the identification and your data import routine should perform a check.

•	Generally, I suggest that trained personnel enter the patient identification to ensure data quality. The patient may very well watch them and, thus, see and learn how to use the system.

•	To support a more reliable, simpler patient recognition, and future independent analysis, you should enter patient name and date of birth in AnyQuin, even if you could match data from *.anq files and from your destination application already by using the patient identification code alone.

•	If you want to blank out patient identification data later (e.g. when you wish to give your data away anonymously) without doing programming work, you can use a tool like TextPad (shareware) to edit multiple files and to perform regular expression replacements. Keep copies of your original files...

•	If you need to collect additional data, you can use additional dedicated *.qdw files in your setup to be filled in by trained personnel before the QL-Recorder is handed over to the patient.

•	Using special UPN commands, you can even collect patient identification data via (direct text or additional text) answer fields trough regular questionnaires.

Import into database applications

•	If you want to support any kind of *.anq file: Make an import routine that extracts the name of the destination data base from the short questionnaire name, the field name from the variable name and the format (optional, if text won't be enough) and value from the value of a line. If database and field do not yet exist, they can be generated on the fly when importing the first *.anq with unknown contents. After user confirmation, if you like.

•	If you want to keep it controlled, define a table that contains source short questionnaire name, source variable name, source value category (especially: not want, not can, undefined!), destination database, destination field, destination value (especially: for not want, not can, undefined!) and optional commands for import control.

Archiving after import

•	If you move files away from the destination directory where AnyQuest generates them, be sure to avoid the possibility of overwriting files by others with the same name. AnyQuest supports you here.

•	It may be useful to archive files away from the import source directory, after they have been imported into your destination application sucessfully.

•	Please don't delete imported files. They may be useful later on (e.g. by collecting files in the native *.anq format from different colleagues to do a meta-analysis years later).

•	If you need to rename a set of *.anq files, you can enter the DOS-Box (=MS-DOS Prompt, command.com) and enter (for example): ren *.anq aaa*.anq. This example will rename 00000000.anq, 00000001.anq, 00000002.anq into aaa00000.anq, aaa00001.anq, aaa00002.anq and so on.

•	You might also wish to learn about the commands copy, move, xcopy and about batch-files.


*.anq output file options

Using the menu "File" - "*.anq output file options...", you can specify the rules for generation of output file names and for the contents of an output file.

If all options are disabled or empty:

The first generated file in the destination directory is named 00000000.anq. If this file is not removed, then the next file is named 00000001.anq. If no files are removed, the following files are named: 00000002.anq .. 00000009.anq, 0000000A.anq .. 0000000Z.anq, 0000000!.anq, 00000010.anq and so on. Before AnyQuest uses a name, it makes sure that a file of that name does not exist in the destination directory. Should it be in use already, AnyQuest creates the succeeding filename. So no output files in the destination directory will be overwritten, and multiple instances of AnyQuest can share a single destination directory without any difficulties.

As soon as files are removed from the destination directoriy however, their names will be re-used. This means, that you have to be very careful when you move files in order to put them to an external archive or to another place from where a third party application performs an import or other processing: Because all filenames are re-used, you have the risk of new files overwriting older ones, if these have not been re-named or moved into security.

This strategy is identical to the one used by AnyQuest for MS-DOS.

If the option "remember used filenames in each directory..." is activated:

Filenames are created using a strategy similar to the one described above. However, when AnyQuest has used a filename, it writes the counting part of this filename (see below) into the file usedname.ini in the destination directory.

Before it creates the name for the next *.anq output file, it looks up the last used name in usedname.ini and starts creation of the new filename with the next succeeding one. This means, that you can remove files from the data storage directory, but still won't receive multiple files with the same name.

Of course, this mechanism only works, if you use only one destination directory, and if you leave the file usedname.ini untouched.

This is the default behaviour since AnyQuest for Windows Version 2.28.

Before AnyQuest Version 2.59, the mechanism could be confused if you added or removed fixed leading characters for the filename (see below) thereby changing the number of available digits for the variable part of the output file names. The mechanism has been improved so that if it retrieves the last used variable part of the filename, it adds or removes leading zeros until the number of variable digits matches the available digits, taking into account the currently used fixed leading characters. If there are excess variable digits taken from usedname.ini, and leading zeros cannot be removed (because too many filenames have already been used up and thus, too many non-zero digits are already there), counting will start over at 0 - with as many zeros used as digits are left available by the current number of fixed leading characters.

If "fixed leading characters for the filename" are specified:

This is an extension to the last option only. The specified leading characters will be used when the next output filename is created. As this setting is part of a prepared AnyQuest configuration together with the destination directory, you can achieve that different instances of AnyQuest (running on different machines or configured for different studies) generate their individual filenames.

You might, for example, use two pen-computers and have AnyQuin make files like A0000001.anq, A0000002.anq... on one machine and like B0000001.anq, B0000002.anq... on the other. After that, you could mix all your own *.anq files for archiving without any risk of new files overwriting old ones.

Since AnyQuest Version 2.59, you can additionally define an alternative "custom filename for usedname.ini" for each configuration. It is generally advisable to use an individual custom filename replacing usedname.ini for each QL-Recorder configuration using an individual fixed leading character definition. It should be possible to specify only the filename or the complete filename path here. This feature is especially useful if various configurations with different fixed leading characters access one directory, or if multiple QL-Recorders contribute data into one directory, that is synchronized among them from time to time - but not up to date all the time (like a Windows 2000 or Windows XP synchronized off-line directory).

For example, if you set the fixed leading character = A to get filenames like A0000000.anq, A0000001.anq... on one machine, and the fixed leading character = B to get filenames like B0000000.anq, B0000001.anq... on another machine, you should also define replacements for usedname.ini on both machines to be e.g. A-USED.ini and B-USED.ini, respectively.

(N.B.: The custom filename you specify will be checked and converted to upper case characters by the configuration dialog, but not when being read from the configuration file).

If the option "Write questionnaire meta-information into output files" is activated:

This option controls whether AnyQuest writes an additional block of questionnaire related information in the output file. This is useful, if a third party software must be informed about features of a questionnaire but cannot understand or access the corresponding *.qdw file.

Currently, AnyQuest writes the number of questions, number of result formulas and the minimum and maximum values for bargraphs specified for each computed test result.

If the option "Produce an output file even for an aborted session" is activated:

This option controls whether AnyQuest writes an output file after a session has been aborted. Normally, AnyQuest would just forget all data from an aborted session, but with this option activated, it will write an output file even when a session has been aborted. In this case, it will not check whether all displayed questions have been answered, and the written output file will probably include the patient identification (if collected), time stamp, session log (if activated), information related to used questionnaire definition files, and all recorded answers up to the point where the session was aborted. An abort request is treated with a high priority: When a session is aborted, AnyQuest does not check whether all displayed questions have been answered before it writes the output file.

If the option "Write session event log into output files" is activated:

This option controls whether AnyQuest writes a session event log into each generated output file. This information appears in its own section [session log] and currently reports the following events: Interrupting a session, continuing a session, saving a session, resuming a session, aborting a session. Each event is logged with date and time, current questionnaire short name, current questionnaire number, current question number (within the questionnaire), and for the continue, save and abort entries, an optional comment which can be entered in the session control dialog before the respective session event is issued.

If the option "Suppress any output for questionnaires not shown" is activated:

Since AnyQuest Version 3.00, this option controls whether AnyQuest writes anything at all to an output file for a questionnaire of which not a single question has been shown during a session. This can simplify the output file for configurations where you use one questionnaire to chose for each individual session those modules or questionnaires from a pre-loaded set which shall be applied. Especially, when your *.anq file is being postprocessed e.g. by anq2gdt for import into a third party target application like a practice management software or electronic patient record, you may want to suppress data from questionnaires that were loaded, but not used, during a session, so they won't appear in the final target application.


When defining a UPN formula for a given questionnaire, using the V or C commands you have to take into account every single question in that questionnaire, even if it is declared to be an "Infoscreen".

In the output file, "Infoscreens" won' t be counted, and question numbering within the output file raw data section will always start from 1 for each questionnaire which was included in the set of questionnaires from which the output file is derived.

A single output file will contain data from all questionnaires scheduled in a single session, and it has a standardized data format. This data format is discussed in the documentation of AnyQuest for MS-DOS and will be described in further detail in the documentation of the final version of AnyQuest for Windows. The data file generated by AnyQuest or Windows is only slightly different to the one generated by AnyQuest for MS-DOS.

Here, I'd only like to mention that results are stored in fully self-explaining ASCII files, which are easily printable and readable (even without documentation) and transferrable to any computer platform. Apart from other captured data, each questionnaire scheduled within a single session has its own block, which itself includes raw data and computed results.

The results generated from each questionnaire can be defined in the result formula definition dialog. However, the file output format is not completely free: it is ensured that the output file will comply with the defined standard in any case.

To get an impression, you may look at an output file generated after the completion of any questionnaire. It will have a number as filename with the extension ".ANQ" , e.g. 00000312.ANQ.

Data from many output files can be exported and put into a single file to be imported by Microsoft Excel, Microsoft Access, dBase, Spida, SPSS, SAS or many other programs. Using these commercially available programs, you would carry out further data analysis.

However, be sure to keep your original *.anq files, as they are intended to serve as a standardized means of storing quality-of-life data with guaranteed, platform- and software-independent exchangability and readability.


File formats of Windows- vs. MS-DOS-Version

Differences between output files generated by AnyQuest for Windows and Version 2.21 for MS-DOS

Labelled "initials:", AnyQuest for MS-DOS wrote two initials of a patient. The initial count was designed to be two to save patients from too much inconvenience caused by having to enter their name.

AnyQuest for Windows, however, asks a patient for his first name and for his last name. Both answers are written in a single line labelled "name:" and separated by a space.

AnyQuest Version 2.21 for MS-DOS did not write the computed date of birth into the output file. Instead, the data extraction utility Extract could be instructed through its configuration file to compute the age from a patient's date of birth and the date of the test, and to write it into its output file.

AnyQuest for Windows, however, computes every patient's age immediately and writes it into the output file following the label "computed age:". The unit of measurement is "Years", and the output has a precision of three decimals, so that every single day can be distinguished. AnyQuest for Windows adds the age to the printout as well.

Following the label "delta time:", AnyQuest for MS-DOS wrote the delta time between the point in time when the first and the last question of a set of questionnaires were answered. Separated by a dash ("-"), a comment followed.

AnyQuest for Windows will include this comment in brackets instead of separating it by a dash, because after export of the data to another application, the dash might be interpreted as a minus sign, but the comment would not perform very well in the role of a formula. J

AnyQuest for Windows supports the collection of additional text input like notes, explanations or suggestions. The resulting text strings are written into a new section of the output file. They are arranged in a special column when an export file including raw data is generated.

Still, data files from both AnyQuest versions can be processed successfully by the other version's extraction utility or function.


Duration to complete a questionnaire

Measurement of the duration to complete a questionnaire

The parameter labelled "delta time", in the beginning of each *.anq or *.qlq file gives a measurement of the total time it took a patient to complete the set of questionnaires whose results are stored in that *.qnq or *.anq file.

In AnyQuest for MS-DOS, measurement starts when the first input is made after the display of an empty questionnaire. This may be an input refering to patient identification or date of birth or any question of a loaded questionnaire.

Timing ends, when the field "Complete" or "Fertig" is checked.

In AnyQuest for Windows, timing starts when the first displayed answer field is checked.

Timing ends, when the last question has been answered and the window called "Thank-You-Box" is displayed.

This means, that you cannot compare measurements from both versions directly.

Even within AnyQuest for Windows, timing measurements cannot be compared without care, because they are measured for complete sessions instead of for individual questionnaires.

Before AnyQuest for Windows Version 2.23, there were some releases, in which the delay of 300 ms between answering a question and automatic proceeding to the next question was disabled.

This delay will be configurable on a question- to question base in future releases and more timing information will be available via the *.anq file.


Exporting data into other programs

For evaluation of the data you gained through a study in more sophisticated ways than AnyQuest's built in Analysis tools permit, you might want to use a mathematical or statistical software package like Microsoft Excel, Lotus 1,2,3, SPIDA, SAS, SPSS or Xplore. You might as well wish to take your data into a database application like Microsoft Access or dBase.

All these programs can import data coming as table, arranged in a simple format where each line represents data from each measurement, and individual values are separated by a special character (*.CSV or *.DAT or *.TXT file import). The details however might differ from one program to another. For example, one program might expect a ";" to delimit columns, whereas another one might expect a Tabstop., and one program might expect a "." as decimal separator and another a "," - this may even depend upon the country specific settings of your MS Windows environment.

You may either review the documentation of your target application and available tutorials on the AnyQuest for Windows WWW site to find a working configuration, or you may just try out some of AnyQuest's data export format options and the "data import" functionality of your target software together.

If a desired data export - data import path does not work as expected, it is possible to review the product of AnyQuest's data export routine using a simple text editor, so that you can discover whether a more sophisticated application like MS Excel or SAS introduces some (wanted or unwanted) data interpretation while importing, like unexpected misinterpretation of scientific data format.

Some third party software like SPIDA may also require the core data in one file in a tabular format, and headings in a second file *.NAM. One approach to produce such a set of files quickly may cutting the file originally produced by AnyQuest's built in data export functionality into two pieces using a text editor or a spreadsheet application.

You might also want to store your data in an SQL data base server like Oracle, SAP-DB/maxDB, mySQL or Borland Interbase, or you might want to pass on collected data into electronic patient files or practice management software using the GDT/LDT/xDT standard, or use another postprocessor to transfer data from *.anq files into an arbitrary format. Some examples of available postprocessors for these targets are given below.

Important note: Please make sure you keep your original *.anq files, as they are intended to serve as a standardized means of storing quality-of-life data with guaranteed, platform- and software-independent exchangability and readability.

Generation of tables with collected data

AnyQuest for Windows makes the generation of an tabular data export file a very simple task. Into this file, data from all *.anq files in the currently set data directory are exported. The generated export file can be imported or opened by another application out of those mentioned above.

AnyQuest for Windows can export tables with up to 16384 columns, including the first two columns used for numbers and names of the processed *.anq files. Please note however, that some destination applications may not be able to handle tables of that size.

Built in completely automatic data export

If you select "Generate export file..." from the "File"-menu, a dialog will allow you to choose from a range of options which affect the format of the generated file. Here you can also enter a filename or choose "Browse" to select a filename from your storage devices' contents.

More recent versions of AnyQuest for Windows offer additional options that can force all output data into some format with a fixed number of decimals, or into scientific data format, and can automatically recode AnyQuest's detailed information regarding missing data (like "don't want to answer", "cannot answer") e.g. into the standard SAS simple "." dot.

All settings in this dialog are preserved even after you close AnyQuest for Windows.

When looking for numbers in order to use the specified decimal separator, AnyQuest does not touch the sections [AnyQuest license], [patient identification] (except for computed age), [time stamp], [session log], language and version from [... meta information] and [... additional text information], nor does it touch sections of unknown type.

When AnyQuest for Windows looks for units after exported values, its strategy may fail under certain conditions for the parameter "computed age" in the [patient identification] section, if there are both files with and without computed age data. In this case, you may find the unit "Years" after each valid data value of this column instead of in the column heading. This issue may be corrected in a future version of the software if requested by any user.

By the way: modern spreadsheets just can substract two dates and return the day count between them.

Advanced built in automatic data export for selectable result files

Since version 2.48, export files can be generated using the built in data export facility, but selectively processing one or multiple interactively prepared lists of output file names; using a special dialog for selection of individual output files from the built in "Analysis tools".

Thus, you can e.g. conveniently separate a selection of result files into a number of groups, and generate multiple individual tabular data export files, one for each group, automatically given the group name.

External configurable, batch-mode capable data extract program

Through the "Generate export file..." option, effectively a subset of the possibilities of the utility program "extract.exe", which was shipped with AnyQuest for MS-DOS in the original Quality-of-Life-Recorder, is implemented. In fact because they make use of the standardized open file format, you can process files collected with either system with the other one's extraction tool. While "extract.exe" is instructed through its configuration file, which information out of the *.anq it has to process, the Windows version always automatically processes either all labels included in any of the processed files or, if instructed to, skips some sections.

Please review documentation on "extract.exe" in the AnyQuest for Windows WWW site, in the software library, and the "Tutorials, documentation..." page in the original QL-Recorder documentation.

Postprocessing using anq2gdt or anq2sql or dme2a

There are configurable external utilities to convert *.anq result files into LDT / GDT / xDT format (anq2gdt) or example Perl scripts to transfer data into an SQL data base (Interbase, anq2sql, available upon request in open source code), or an example that performs some generic transfer into a more simplified ANSI/ASCII plain text file (dme2a.pas, originally made for an example setup that collects German Disease Management Program Diabetes (DMP-Diabetes) related information, available.upon request in open source code).

These postprocessors can either be called manually to process one *.anq file or a set of provided *.anq files, or they can be called automatically after each completed questionnaire administration by setting up the used configuration file appropriately.

Please review documentation on these ressources in the AnyQuest for Windows WWW site, in the software library or send me an e-mail to obtain further information.


Selecting a data file folder

After a questionnaire session has been completed, AnyQuest for Windows places new data files into a folder that you can specify using the option "Data file folder..." from the "File"-menu.

Before you start a questionnaire session using "Go!" in the "AnyQuest Navigation" window, AnyQuest checks whether you have specified a valid data folder. If not, the "Data file folder..." dialog appears automatically. If you don't have selected a valid folder after 3 trials, AnyQuest will return to the "AnyQuest Navigation" window.

Even if there was a valid folder when you began a questionnaire session, AnyQuest may discover after the questionnaire session has ended, that it cannot write the output file correctly for a variety of reasons. In this case, the "Data file folder..." dialog appears, too. Here, however, you must definitely select a valid and correctly writeable folder before the programm will offer any other option. This behaviour helps you avoid the loss of already collected data.

In the "Data file folder..." window, there is an option that allows you to browse your storage devices directory structure to select a folder (which in this version is not implemented very sophisticatedly). Please just enter the folder you wish, and then select "OK" or "Cancel". You don't need to specify a filename here, because this is ignored.

You should collect data from each project in a different folder. Storing data in different folders, you can even run multiple studies on the same hardware system concurrently.


Setup for multiple studies

Setup for multiple studies running concurrently on one hardware system

It is possible to collect - on the same machine or network system, on the same storage device - data from different studies. There are a couple of different possible solutions for this task so far, all of which rely keeping data from different studies in different folders on your storage device.

You can...

...use multiple copies of AnyQuest for Windows in different folders. The simplest way to do it.

...under Windows 3.1: prepare multiple program icons in the program manager, and assign different configuration files as command line parameters.

...under Windows 95: prepare multiple short-cut icons anywhere on your desktop or on your harddisk, and assign different configuration files as command line parameters.

In this case, the different configuration files would contain different data file folders. To achieve this, you would have to start AnyQuest once with every new configuration file and select a different data file folder. If you are a more experienced user, you can as well prepare these configuration files with the windows notepad.

...under Windows 3.1: prepare multiple program icons in the program manager, and assign a different default directory to each of them.

...under Windows 95: prepare multiple short-cut icons anywhere on your desktop or on your harddisk, and assign a different default directory to each of them.


Intelligence is not a business of computers

AnyQuest is neither "intelligent" , nor does it think, but some added objects come with further default objects they definitely are going to have (e.g. a questionnaire comes with a question and at least two answer fields). If there are any objects around already, further objects of the same type come matching those already available. This will make it easy to construct a questionnaire of 30 questions with 4 answers each and all the same labels. To profit most, complete the first question with all its characteristics, and then simply add 29 more questions.

New formulas are added in a similar fashion.

If you want to use a question or its answer fields as a prototypes that are not nearby to where you are adding or inserting a new item, you can select the prototype question via "Edit" - "Set prototype question". If one question is selected, new questions will appear in a layout that resembles this question, and new answer fields will as well. You can use that option even to copy question layouts across questionnaires. So you will not need to arrange any individual question layout manually more than once.

Menu items are usually grey - which means, they are inactive - while the associated option would not make too much sense. For example, you won' t be able to select "Save" from the "File"-Menu while there is no questionnaire in memory.

• Jörg's Magic Questionnaire-o-Matic

• Quick guide to making your own questionnaires


The file menu

Multiple questionnaires can be loaded at a given time. They will be presented to a patient in the sequence they were loaded or created. Commands from the file menu are the main way to prepare questionnaire configurations to your questions and to control storage and export of collected data. Moreover, you will need some of these commands to support your advanced editing.

Basic commands from the file menu:

"Clear All" relieves the burden of knowledge about human beings' questionnaires from AnyQuest for Windows' mind. However, it presents you a dialog for confirmation if you might loose unsaved modificatons of questionnaires.

"Load *.qdw questionnaire definition file..." brings up a dialog which lets you select a questionnaire definition file to load. The new questionnaire is loaded directly after the currently displayed one.

"Save *.qdw questionnaire definition file" saves the currently displayed questionnaire definition file using its current name, if it has a valid one. A valid name should be there if you have either previously loaded the questionnaire from a *.qdw file, or if you have previously saved it to a *.qdw file, or if you have executed a *.qdt file which gave the questionnaire a name.

"Save *.qdw questionnaire definition file as..." brings up a dialog which lets you specify a name and location and then save the currently displayed questionnaire definition file.

"Exit" ends AnyQuest for Windows. The names of all loaded questionnaire definition files and the state of most available options are stored in the currently active initialization file and restored when you start AnyQuest the next time using the same initialization file.

Commands which control details of data collection:

"Data folder setup..." lets you select the folder where AnyQuest for Windows shall store *.anq files containing the collected data after a patients have finished a questionnaire session. The selected location will be stored in the currently used initialization file, so you may use different locations for differently prepared configurations on the same machine. This command is mostly useful if you prepare configurations for different concurrent studies on the same machine, or if you want to collect data in remote directories.

"*.anq output file options..." lets you control some options which influence how AnyQuest writes *.anq result files. They are useful for backward compatibility, for settings that involve multiple concurrent data sources and for settings where data are periodically collected and removed.

The command which controls the generation of an export file for all collected data:

The "Generate data export file from multiple *.anq output files..." command analyzes all *.anq files available in the folder specified above, and generates a table containing the collected data. This table can be exported to third party software for statistical analysing or other processing. The processed *.anq files may contain data from arbitrary questionnaires, languages, versions, registered users... so this button may be the perfect tool to prepare data from multiple centers and multiple studies for a meta-analysis. The contents of the table and its format can be configured in a dialog.

Commands for advanced users which support questionnaire editing:

"Import questions from *.qdw questionnaire definition file..." brings up a dialog which lets you select a *.qdw file. Out of this file, questions, answer fields and formulas are imported into the currently loaded file. The questionnaire history - if available - is imported enclosed into special remarks. General parameters as file name, questionnaire names, font size and so on are not imported, because they are already defined in the currently displayed questionnaire. Imported questions will appear directly after the currently displayed question. If formula consistency check is activated, it will adjust formulas of the currently displayed questionnaire as well as formulas of the imported questionnaire adequately.

"Execute *.qdt questionnaire definition file..." brings up a dialog which lets you select a *.qdt file. The commands found in that file are executed, which may result in items being added to or changed within the currently loaded questionnaire, or in one or many new questionnaires being built. A questionnaire history - if available - is imported enclosed into special remarks. If no questionnaire history is included in the executed file, a remark will be included in the currently loaded questionnaire's history. While some parameters fonts, font size colour and objects (including conditional branch formulas) can not be changed or generated from *.qdt files, others like questionnaire names, language and version, and even the filename can be set. Items will be created immediately after the currently loaded question or questionnaire or the last answer field of the currently displayed question. Important note: Please be careful not to give a questionnaire the name of another *.qdw file from out of a *.qdt file and then accidentally overwrite that other *.qdw file by carelessly selecting the above "File - Save".

"Generate *.qdt questionnaire definition file" generates a *.qdt file with a name and in a location matching that of the currently loaded questionnaire. This *.qdt file is a text file that contains commands defining many of the items and properties of the currently displayed questionnaire. You can edit it with a suitable text editor, e.g. to rearrange the sequence of questions or result formulas or do other modifications which are not natively supported by AnyQuest's editing capabilities, or which an experienced user can just perform quicker using a text editor. These possibilities should be used by advanced users only. They can also be useful if you want to generate questionnaire contents by third party software.

"Generate *.qdt questionnaire definition file as..." brings up a dialog which lets you select a the name and location of a *.qdt file and then generate it.

Debug commands:

"Dump tree" is primarily a debug command for my personal use. It shows some information about AnyQuest's memory contents. Important note: closing the resulting window will immediately abort AnyQuest for Windows. You should basically avoid to do that in order not to lose your work. If it should happen unintentionally, however, and you need to recover your work, please read the information in this help file regarding crash recovery before continuing to work with AnyQuest.

"Memory report" is primarily a debug command for my personal use. It shows some information about AnyQuest's memory usage. Important note: closing the resulting window will immediately abort AnyQuest for Windows. You should basically avoid to do that in order not to lose your work. If it should happen unintentionally, however, and you need to recover your work, please read the information in this help file regarding crash recovery before continuing to work with AnyQuest.


Endless question asking

Endless question asking = unattended "kiosk" mode

If this option from the "Navigation" menu is checked, after having presented the complete set of questonnaires to one patient, AnyQuest just does the same thing again. It does not leave this loop any more, and to close it, you should use the window's "Close" button or to select "Close" from its system menu. Note that neither of these is available while AnyQuest asks for patient identification data.

If this option is not checked, AnyQuest returns to normal operation, after one patient finished the set of loaded questionnaires.

To enter the loop, either press "Go!" in the "AnyQuest Navigation" window, or from the menu "Navigation", select "Remove Menu & START ASKING QUESTIONS".


Automatic check, calculation, output & erase

Automatic check, calculation, output & erase after the last question

If this option is checked, AnyQuest goes into data check and evaluation every time the last loaded question is displayed and a "move on to next question" sequence is issued. This may be done by pressing a button of the transport bar, the button "Continue..." in multiple selection type questions or just by answering any other type question when "Auto weiter" is checked.

While the edit layout mode ist activated, no Automatic check, calculation, output & erase after the last question will occur. I chose to program it like this because accidentally hopping over that border all the time - what I did :-) - might become a bit annoying when you want to concentrate on editing your layout.

Important Note:Although, if not in edit layout mode, you can complete a questionnaire for (questionnaire-design-) diagnostic purposes completely and have it evaluated and data stored, you won't be able to collect patient identification data like that. Likewise, timing of the duration it took to complete the questionnaires might be inaccurate and the display will not be freed from items that are only required for the construction of questionnaires.

Therefore it is recommended, that if you want to collect data from patients, you should select "Remove Menu & START ASKING QUESTIONS" with or without the "Endless question asking" option set.


Remove menu & START ASKING QUESTIONS

This command starts the presentation of all loaded questionnaires to a patient, preceeded by collection of identification data.

To improve the clarity of AnyQuest's display, its menu is temporarily removed for this purpose and its window is maximized.

To ensure that displayed questions can be answered, AnyQuest unchecks the edit layout mode and closes the edit result formulas window before it starts asking questions. It also guarantees that there is a possibility to move from one question to another - even if the user chose to have both automatic proceeding to the next question and the transport bar deactivated...

During the collection of patient identification data via the built in dialogs, no other controls of AnyQuest are active. If you want to interrupt the session, you have to enter some fake data to get through these screens.

After patient identification data have been collected, the session can be interrupted and even saved to be resumed later at any time.

During a session, AnyQuest provides some keyboard controls which should not be used by the patient, but by assisting personnel when the patient indicates certain problems.

Various options in the configuration file can control these functions and other details of appearance and functionality during questionnaire administration, sound signals, reaction to window control buttons (minimize, maximize, move, close), visibility of the title bar, a graphical progress indicator, the transport bar, or small specialized buttons to go back for one question etc.

After the patient has answered the last question within a set of questionnaires, answers are checked for completeness (which is especially reasonable if the transport bar was activated when the questionnaire was given to the patient), questionnaire completion time is measured, results are computed and stored, and printout is generated.

If "Endless question asking" is not checked, AnyQuest will return to normal operation, after one patient finished the set of loaded questionnaires and present the main navigation window. Otherwise, another presentation of questionnaires will follow immediately.


The "AnyQuest Navigation" window

When you start AnyQuest for Windows, this window appears to make the use of the software easy for everybody.

Who are you?

If you are the absolute beginner, and this is the first time you brought up the help file from the navigation window, I'd suggest you to:

•	either go to the table of contents of the help file, learn about the background of this software and get an overview on what's available,

•	or follow the quick guide for users to applying pre-configured Quality-of-Life-Recorder packages.

•	or follow the quick guide for designers and researchers to making and applying your own electronic questionnaires,

•	or to learn something about Jörg's Magic Questionnaire-o-Matic.

The buttons in the navigation window have the following functions:

"Start an assessment with the current configuration" (before version 3.72: "Go!")

This button starts the presentation of all loaded questionnaires to a patient, preceeded by collection of identification data. More details are given here. It is only visible, when at least one questionnaire resides within AnyQuest's mind.

"Resume a previously interrupted assessment" (before version 3.72: "Resume")

This button opens a list of available interrupted and saved sessions. It is only visible, if there are any saved sessions available to be resumed.

"Set up or review a configuration for assessments" (before version 3.72: "Setup")

This button removes the "AnyQuest Navigation" window. Afterwards, a set of questionnaires can be prepared and arranged for presentation. AnyQuest's configurable options can be set according to the user's needs. If you have no experience with these tasks, you might follow the quick guide for users  to configure the Quality-of-Life-Recorder environment exactly to meet your requirements, or read the quick guide for designers or researchers, a crash course to learn how to make and apply electronic questionnaires.

"Edit electronic questionnaire definition files" (since version 3.72)

This button removes the "AnyQuest Navigation" window. It not only goes into the "setup" mode, but also sets the "Edit" - "Edit layout" flag so you can create or modify questionnaire definition files.

"Perform statistical analysis or export collected data"  (since version 3.72)

This button removes the "AnyQuest Navigation" window. It not only goes into the "setup" mode, but also directly opens the dialog also available through "Analysis tools" - "Select and review results, generate printouts and file lists..." - "By predefined filters on certain individual fields". Effectively, you can use it to locate and review the results of individual assessments, to produce delayed printouts, or basic statistical analyses including a table with descriptive statistics, box plots, course over time plots, or data exports for all collected data or for prefiltered data. These can in turn be used for advanced statistical analyses with external programs or for bulk data transfers to third party database applications.

"Help"

This button opens the help file you're currently reading. If you place AnyQuest's main window and AnyQuest's help window next to each other, you can read the help file and try out AnyQuest's functions in parallel. Click here to go to the main table of contents!

"Exit"

This button allows you to exit AnyQuest for Windows.

Controlling the window

The "AnyQuest Navigation" window appears automatically when it is convenient for the user, e.g. immediately after the startup of AnyQuest for Windows, or after a set of questionnaires has been completed.

If you wish to bring up the navigation window from other parts of the program, select "Navigation" - "Show navigation window".

All buttons other than "Start an assessment..." can be disabled individually by setting the a configuration file option in order to prepare a secure configuration.

Sufficiently recent versions of AnyQuest for Windows can be customized by a range of *.ini file parameters which change the appearance and/or location of the navigation window, the available options, and can even be used to use questionnaire 1 question 1 as a title screen instead of the automatically generated contentent:

•	[Options]

•	TitleSuppressRainbow=True

•	TitleSuppressBitmap=True

•	DontListQDWs=True

•	ConfigTitle=MyProject Questionnaire

•	ConfigTitle=

•	ShowQnr1Qn1AsTitleScreen=True

•	NaviMinimal=True

•	NaviMinimalShowExit=True

•	NaviMinimalAtBottomOfScreen=True

•	NaviMinimalShowExit=True

These options have been added up to version 3.54 - please review the "product history" in this online help to learn more about the capabilities of specific versions of the software.

The option ShowQnrFastInputForm=False, finally, would switch questionnaire administration mode from the usual appearance suitable for direct use patients to a shortened dialog optimized to score paper questionnaires by trained staff (available only for suitable questionnaires).


How the patient handles AnyQuest for Windows

Basicly, a patient answers all questions presented to him by positioning a pointing device over a button or an answer field and clicking the button corresponding to the primary button. In reality, this might mean using a trackball, using the finger ora stylus to point at a touch-screen, or a digitzing tablet, or using the pen of a pen-computer on its screen.

There can be introductory screens within the questionnaires, which might explain the purpose of it all or how to place a check on a LASA-Scale.

Although a transport bar can be displayed, usually it can be switched off, and the patient doesn't have to care much for his way through the questionnaire: One question is presented after another, and he just has to check the answers fields he likes.

AnyQuest for Windows gives the researcher the possibility to allow a patient to explicitely state on special answer fields that he couldn' t or didn't want to answer a question. On a pen-computer or using a keyboard, it is possible to take hand-written notes like explanations or suggestions. Future releases will support conditionally asked questions.

After the last question is completed, all answers are checked for completeness. If answers are missing, AnyQuest will display the affected questions again and ask the patient to provide an answer.

Later versions of AnyQuest for Windows will support keyboard input and so be compatible with GraTaSim for Windows, being able to use technology from the Quality-of-Life-Recorder.


Collecting patient identification data

(Sorry, this has become a complex page. Please review all the subheadings before reading it!)

Available data fields

AnyQuest for Windows has built in facilities to collect a patient's identification number or code (PID), first name, last name, simple name, initials, date of birth, sex, ethnicity, address, and other patient related variables, at the beginning of a questionnaire administration session.

In a similar manner, you may record meta-information about the current questionnaire administration, like: physician number, rater, group, cycle etc.

In version 2.57, options have been added to record most fields of the German Health Insurance Card (Krankenversichertenkarte). Interface modules for KOBIL, IBM and other readers have been prepared.

Configuration

You can check each field which shall be recorded in the current configuration via the "Navigation" menu.

As long as your currently used configuration file *.ini is not write protected (by the respective entry, or by standard filesystem means), any changes made from the menu will be preserved in the configuration file.

If you want to change many options or want to copy the changes to many configurations efficiently, let AnyQuest write out all configuration options by closing it once, then directly edit the respective entries askfor...=True|False in the configuration file(s) using a text editor. Note that there are text editors which can search/replace in multiple files at the same time (TextPad, PSPad, Nedit etc.)

Normal operation

When a questionnaire administration session begins, a screen with large number- or letter-buttons is shown for each confired variable. Using the mouse or a touch-screen, or a pen-computer, you can type on the buttons to enter the PID, name, date of birth etc.

On a pen-computer with handwriting recognition, you may be able to hand-write the required information into the input-field - but this is probably not what I would recommend to untrained patients. Alternatively, you can use a pen-computer's keyboard equivalent (see below).

If asked for the first or last name, at least one character has to be entered. So if you just want to supply initials in these fields, enter one character at each of these questions. (Alternatively, special fields for "simplename" or for "initials", with limited functionality, are also available.)

If asked for the date of birth, it can be entered in a variety of formats. If AnyQuest for Windows can reliably identify a valid date of birth from what the patient entered, it will transform it into the standardized format. Screen dialog format and printout format can be set to "dd.mm.yyyy" or "yyyy-mm-dd" independently; result file storage format is always "dd.mm.yyyy".

In screen dialogs, AnyQuest accepts dfferent formats with or without leading zeros and with or without included separating full stop, as long as the provided information is not ambiguous (e.g.: 01.02.1903, 1.2.3, 1.2.1903, 01.2.3, 01.02.03, 010203 for the German date format, and 1903-02-01, 3-2-1, 1903-2-1, 3-2-01, 03-02-01 for the English date format). If AnyQuest cannot understand your interpret, it will try to give as close a hint on the position of the problem (year, month, day, or just something wrong) as possible.

Going back to previous dialog, Starting over

Since version 2.54, it is possible to interrupt the collection of the patient ID at any time by pressing [ESC] or [Alt]-[F4], and to return to previous screens by clicking on the [<<<] button displayed on the screen, when the cursor is at the leftmost position of the text entry field.

Recommendation: Have staff record PID data

Where proper recording of a patient's identification is crucial, it might be advisable either to have this information entered by a staff member (e.g. a clinical data manager), or to assist a patient who is entering it.

An alternative is obtaining patient-ID-data from another IT system: barcode scanner, card reader, database interface, practice or hospital managment system interface, pre-prepared dummy *.anq files merely containing patient-ID-data (see below).

Automatic Patient ID recognition

Special options control whether the alphanumeric or numeric patient ID is collected, and whether it is collected before or after the patient name. Since version 2.54, you can check "Navigation" - "Patient identification options to ask for" - "Recognize PID in follow up-sessions".

If a patient fills in the first questionnaire at the system, the unique patient ID (numeric or alphanumeric) is recorded in addition to his name, date of birth etc. Please note: If you use multiple IT systems, e.g. a practice management software or a hospital management software, you might use the same PID for the same patient in all systems. See below for possibilities to connect AnyQuest to such systems.

If automatic PID recognition is active, and the patient ID is configured to be collected after the PID, you may still enter an (alphanumeric or numeric) PID in the first screen which asks for the patient's name. If AnyQuest recognizes a number (digit) in your input, it assumes that this is probably not a name, but a PID. Then it checks whether it can recognize the PID from the stored results of previous questionnaire administrations. If yes, it fills in all available details into the other fields configured to be collected.

If automatic PID recognition is active, and the PID is configured to be collected before the patient name, it is also sufficient to supply the PID and the other details can be filled in automatically if the patient is recognized.

After a PID has been recognized, the dialogs for the other variables configured for collection that would normally appear, are skipped. Instead, at least the short version of a confirmation screen asks whether the correct patient was recognized. If you chose "No", it will still leave the values it read from the file in the respective fields and you can change them manually - if you want to start over with all fields empty again, please chose "Abort" or press the "ESC" key.

Finally, additional options determine whether dialog screens are presented for variables like group, subgroup, cycle, subcycle etc. even though the patient was recognized. This allows automatic completion for static data (like name or date of birth), and manual entering of data that change for each assessment (like therapy cycle).

The option to recognize a previously used PID should at the same time simplify PID collection and ensure that collected data from multiple sessions completed by the the same patient are identical. This feature is extremely convenient if you use a barcode scanner to scan the alphanumeric or numeric PID code instead of entering it manually (see below).

Production of cumulative result printouts may use either an alphanumeric or numeric PID to recognize the results of the same patient, or fall back to name and PID if these are not available, depending upon the exact configuration of the system. If errors have been made during PID data recording, it may be possible to correct these later on or to enforce generation of a cumulative result printout from manually selected files with different (or similar, instead of exactly identical) PIDs.

In version 3.45, support for the additional parameter ObserveLeadingCharsForStatsOldResProc in section [*.anq Output File Options] of the *.ini configuration file was added. If set to true, AnyQuest for Windows will only evaluate result files *.anq with a filename whose leading characters match the current anqfilename_leadingchars setting. Effectively, this can be used to store data from multiple configurations that produce *.anq result files with different filenames in the same directory, so that PID recognition works across all of these configurations, while at the same time limit processessing for on-the-fly statistics and cumulative printouts to *.anq result files generated by the current configuration. The new feature works for both standard and fast index based PID recognition.

AnyQuest provides two alternative algorithms for PID recognition: standard, and index based (see below).

Notes on performance of standard Patient ID recognition

The standard algorithm for Patient ID recognition scans the beginnings of all collected *.anq files in the current data directory for a matching PID code, and always uses the first found file with matching numeric or alpha-numeric PID code to provide the data for the remainder of non-empty fields in this file.

The scanning uses some mass storage device bandwith; if your storage is connected through a network, it may also cause some network bandwith. Except for very slow storage devices, the performance limiting factor may quite probably be the many "open-file" requests to be processed by the operating system controlling your mass storage device rather than actual data throughput.

Testing on various machines from Cyrix Media FX (about 486/66 MHz equivalent speed), Pentium 120, Pentium II 233, Pentium II 350 through to Athlon 700 with various file systems on various HDUs, partially accessed via 100 MBit Ethernet showed that you may expect acceptable response time up to a few thousand collected result files. File servers with more modern file systems (NTFS, efs2, efs3...) may outperform even local FAT16 or FAT32 based systems. A disk cache is useful in this context (standard in 2008...). When tenths of thousands of files are searched, you may observe that, on older infrastructure, the first search may take a few minutes while following searches are completed in a few seconds.

If you expect to record thousands of files, or have very slow machines or network, you should nevertheless monitor the performance of automatic PID recognition from time to time to ensure that your staff and patients are not annoyed by long response times of feature intended to be time-saving. For testing in advance, I can provide upon individual request a tool that generates thousands of dummy ANQ files.

If you must use the standard algorithm for PID recognition, and you collected thousands of files, and your response times or network load have become unacceptable, and you absolutely need some instant relief without any time to optimize your configuration: you may also decide to archive away e.g. those *.anq result files which are older than one year (the criterion is actually: with data from patients of whom you can be sure they will not return for a follow up measurement). As long as you leave your usedname.ini file untouched, old *.anq filenames will not be re-used, even if the files themselves have been moved away. However, missing *.anq files can naturally not be used for patient ID recognition neither for cumulative result file generation.

Fast index based automatic Patient ID recognition

If you want to process several thousand measurements with recognition of previously used PID, you may use an alternative index based PID recognition algorithm, by setting respective options IndexBasedRecognPIDPIDcol=True and/or IndexBasedRecognPIDcumprn=True in your configuration file.

This has been implemented and has been usable at least since version 2.73, has been used without any problems in a longterm project, and a single known minor issue was removed in 3.26. Nevertheless, it shows an ALPHA-version reminder, because it relies on several features of the underlying file-system or operating-system.

Specifically, this feature requires that after a findfirst operation, the data field that DOS uses internally for its search mask, can be modified and is still honoured in a subsequend find next operation. It also requires, that newer files are returned after older files by findfirst/findnext, and that this sequence does not change (at least not so much that a file not yet indexed would be reported by findfirst/findnext before the last file already indexed) by deleting a file from the directory and then re-using the same directory "slot" for a new file.

While developing version 3.45 (as of 2010-02-14), I found that the search mask related feature of DOS/Windows which was available at least up to Windows 98 SE, is not supported or usable any more in Windows 2000 or Windows XP. As a result, AnyQuest cannot recognize that newly added result files need to be added to the index on such a system, after the index has been initially made. So I added code to determine the OS version and to inhibit index based PID recognition on systems with major version number above 4, and on systems which do not return 0 when calling int 2Fh function 160A. I do not perform new tests on Windows NT 3.51 or Windows NT 4 for now, so I cannot provide information on whether index based PID recognition will currently be usable on these systems.

If you would like to use fast index based PID recognition on such a system, please send me a message (or monitor future release notes, because rewriting to algorithm to work without the special directory usage (which will however render it slightly less effective and remove some of the AutoMagic functionality) is on my to-do-list already).

Another alternative is the uni- or bi-directional linkage to external database systems as described below.

Pre-prepared dummy *.anq result files.

When you want to be able to enter patient-ID details very quickly during data collection, and you know the PID, names, and dates of births in advance (e.g. during and OSCE or when you administer questionnaires to patients who registered for a clinic before they actually visit you), you may provide this information in a tab-separated table (which can be exported e.g. from MS Excel), and use the program TABIDANQ.EXE to create one dummy *.anq result file for each entry from that table.

Later on, when the questionnaire is truly administered to the patient, you may just enter the PID (manually, or using a barcode scanner), and the system will recognize all other data from one of the dummy *.anq result files.

Inference of the dummy files on future data exports, analyses etc. is minimal. The current version of TABIDANQ.EXE names them NAME????.ANQ, so they can be conveniently excluded from analyses. TABIDANQ.PAS source code is also available, so if you need support for more than 4 digits in the patient ID derived filename, or different table formats, you can easily adopt it to your needs.

You can of course also combine dummy *.anq files with index based PID recognition.

Connection to databases, practice-software, card-readers etc.

Since version 2.39, AnyQuest for Windows can call external programs to check collected patient identification data against an external database or to supply data acquired completely on their own, e.g. from a card reader.

You can link AnyQuest uni- or bi-directionally to your local patient database and replace local PID collection by import of PID data provided from there through an ASCII/ANSI text file. Adaptors are available for several systems, including configurable GDT- and LDT- interfaces.

You can also use this external link to provide AnyQuest with your preferred, home-made, much-more-comfortable, interactive, patient-ID-data collector plugin.

While doing so, please keep in mind that it may not be desirable for patients to be able to enter just about any name (including wildcards) into the system to find out whether their neighbour has also been here (or similar things, or complete a questionnaire and receive a cumulative result printout in his name).

Under this aspect, the selection of the patient at an external system (e.g. practice management software) on another machine, and provision of patient-ID-data via GDT/LDT or similar, or of an interfaced card-reader, or barcode scanner with external interface programs, are possibly the most robust and secure solution.

Using a barcode scanner

Automatic PID recognition is perfectly compatible with a barcode scanner connected to the PS/2 or USB keyboard input: When a patient is first registered, the alphanumeric or numeric patient ID is scanned from the barcode, and the other details are filled in by hand. When the patient returns for a follow up visit, scanning the barcode again enters the PID, which is recognized, and the other details appear automatically.

Confirmation dialog

Some options control whether a dialog appears to confirm the patient name, data of birth, and optionally, additional variables.

This is especially useful after automatic PID recognition, and when PID data are imported from an external source, like a health-insurance-card reader or a practice management software.

Depending upon the answer given, patient data acquisition can start over from scratch, or preserve the values entered up to now as a starting point for further correction.

Historic notes and additional details

Since version 2.60, you can configure whether several fields (physician number, group, subgroup, cycle, subcycle, rater, information source and assessment) are collected through the PID collection screens even though the entered numeric or alphanumeric PID has been recognized to match one used for a previous assessment, and all other fields are filled in automatically from this data source. When using this functionality, you need to check both options, e.g. "ask for cycle" and "ask for cycle though PID was recognized" in order to display the respective data collection window.

Since version 2.63, an option was added to ask for the (recognizeable) alphanumeric PID code first, before asking for any other PID data field like name, date of birth and so on, instead of afterwards. But...

...before version 2.67, when you activated the feature "Ask for PID first" together with "Recognize PID in follow up sessions", AnyQuest would not accept any new PIDs but only such PIDs that it could recognize. This has been corrected in version 2.67.

Actually, the new functionality has been implemented in a way that may be used to give a new PID to an existing patient without having to type all his other data fields manually: First, supply the old PID of the patient which is already known to AnyQuest. When it recognizes this PID and asks you whether the other data (retrieved from previous measurement after recognition of the PID) are correct, select "No". Then enter the new PID. AnyQuest will not recognize this (because it is new), and ask for the remaining PID fields - however, the dialogs will be pre-filled with the values that accompanied the previously recognized old PID.

Please note that, although this is a comfortable way to supply an already registered patient with a new PID while copying other data field values from previous recordings, AnyQuest will normally not produce cumulative output including questionnaire result data collected using both old and new PIDs. If you need that function (e.g. because your patients get a completely or partially new PID every tíme they visit your hospital), please review the functionality provided in the built in "Analysis tools"/"Statistics" on your own (select result files, write filelist, produce cumulative result printout ignoring PID), or contact me directly for guidance.

Handwriting recognition details

Earlier Windows 98 based pen-extensions allowed to write directly into the input field. This was extremely natural so far, but you had to write separate characters.

The recent Windows XP Tablet-PC edition recognizes handwritten words with astonishing precision. However, you cannot simply write into the input field: it merely shows a small icon: the user must click at this icon to make a writing pad or a keyboard replacement appear, and only thereafter can she use the pen for hand-writing. This is definitely nothing that untrained patients will regularly be able to do. This feature is also disabled if you replace the explorer (as shell) completely by AnyQuest for Windows for security reasons, so that other AutoStart/Run/etc. programs are not executed after login. If you require handwriting support on such a system, please contact me and I will carry out further research.

I've seen at least one other earlier handwriting recognition system on the Palmax PD-1000; I felt that it suffered a lot from the far simpler touch-screen, in comparison to the electromagnetic graphic tablet technology that all my Fujitsu Stylistics have had.

Reading and writing PID variables from inside the questionnaire

AnyQuest's built in UPN processing language includes some commands to access the patient-ID-variables from result formulas, conditional formulas, and inline formulas which can be placed inside any text element visible in any question.

This has (at least) these possible uses:

Displaying the patient name, date of birth etc. throughout every page of the questionnaire.

Collecting PID related information through customized free-text-input-fields inside the main questionnaire, but making them appear in the standard fields in generated file output and printouts.

Collecting and exchanging PID related information with external sources or programs (also possible via UPN commands) while in the main questionnaire.

Customizing or abusing variables

The text displayed in the dialog shown to collect each variable, and the texts used as labels in generated result files and in generated printouts, are defined in the *.msg file which is used by the current configuration.

By changing the respective texts in the *.msg file, you can e.g. tweak a display from "Please enter the patient's ID code" to "Please enter your ID code" or to "Please use the barcode scanner".

You could also use this to override the meaning of one variable completely. I do not recommend to do this with some very original system variables, as some of them are used for PID recognition, computation of patient age etc., but you may feel free to try it with secondary things like the address fields etc.

If you get into such tweaking, please do not forget to document what you did (the supplied *.msg files already contain exemplary documentation), and why you did it, and to perform sufficient testing before giving the result to patients.

Relation to Fast-Input-Form mode

Due to space restrictions, only a small selection of patient-ID related variables are available in Fast-Input-Form mode. Operation is naturally different, and explained here.


Temporarily available diagnostic commands

The menus contain a few commands which are there primarily to facilitate program development:

"Dump Tree" gives a partial output of the contents of AnyQuest's mind to a text mode window. It also produces some statistics about memory usage.

"Memory report" gives some information abot memory usage. If you find out that adding an object and removing exactly the same object again causes a permanent change in available memory, please send me some detailed information on that.

Be very careful with these commands: if you close their text output window, this will shutdown AnyQuest for Windows immediately!


Literature reference

This is a selection - incomplete by design and severely outdated - many additional references, thematically sorted, are listed on my WWW site: http://www.ql-recorder.com

i. Regarding the original Quality-of-Life-Recorder with AnyQuest

1. 	Sigle JM: Praktische Aspekte der Lebensqualitätsmessung: Die standardisierte Messung der Lebensqualität bei Ambulanzpatienten mit einem elektronischen Lebensqualitäts-Recorder. Promotionsarbeit, Unversität Ulm, 1997. Available from the author on CD-ROM or on my WWW site.

2. 	Sigle JM, Porzsolt F: Practical aspects of quality-of-life measurement: design and feasibility study of the quality-of-life recorder and the standardized measurement of quality of life in an outpatient clinic. Cancer Treatment Reviews (1996); 22 (Supplement A): 75-89

ii. Regarding the Quality-of-Life-Recorder with AnyQuest for Windows

1. 	Sigle J, Wilhelm HJ: Medizinisches Qualitätsmanagement. In: Lehman T, Meyer zu Bexten E (Hrsg.): Handbuch der medizinischen Informatik. Carl Hanser Verlag, ISBN 3-446-21589-1 (2002)

2. 	Sigle J: Electronically Supported Outcome Measurement. In: Beuth J, Moss RW (Ed.): Complementary Oncology. Thieme Stuttgart, New York, ISBN 3-13-137451-9 (GTV) ISBN 1-58890-323-0 (TNY) (2006)

3. 	Chen T, Li L, Sigle J, Du Y, Wang H, Lei J: Crossover randomized controlled trial of the electronic version of the Chinese SF-36. (Feasibility, acceptance and cross-validation of SF-36 on paper vs. eSF-36 on the QL-Recorder). J Zhejiang Univ Sci B 2007 8(8):604-608. ISSN 1673-1581 (Print), ISSN 1862-783 (Online). PMID: 17657865 (Publication available online, fulltext freely accessible in PubMedCentral)

4. 	Rogausch A, Sigle J, Thüring S, Kochen M, Himmel W: Patientenbefragung per Tablet-PC. Dtsch Arztebl 2007; 104(42): A 2857-60. (Publication available online, fulltext freely accessible.)

5. 	Herschbach, Berg, Pirker, Henrich, Emrich, Sehlen, Dühmke, Geinitz, Molls: Computer based evaluation of a screening procedure for psycho-oncological treatment during radiotherapy. (Feasibility, acceptance, costs and cross-validation of SIRO on paper vs. eSIRO on the QL-Recorder.)In: Abstracts of the 8th World Congress of Psycho-Oncology, 16 th-21 st October 2006, Ferrara-Venice, Italy. Psycho-oncology 2006; 15(iss 2 Suppl): S1-462; PMID: 17338072 (Overall)

6. 	Strong V, Waters R, Hibberd C, Rush R, et al.: Emotional distress in cancer patients: the Edinburgh Cancer Centre symptom study. (Routine-use of 5 QL-Recorders for screening of outpatients using the QLQ-C30, HADS and other questionnaires.)Br J Cancer. 2007 Mar 26;96(6):868-74. Epub 2007 Feb 20. PMID: 17311020

7. 	Storey DJ, Waters RA, Hibberd CJ, Rush RW et al.: Clinically relevant fatigue in cancer outpatients: the Edinburgh Cancer Centre symptom study. (Routine-use of 5 QL-Recorders for screening of outpatients using the QLQ-C30, HADS and other questionnaires.)Ann Oncol. 2007 Nov;18(11):1861-9. Epub 2007 Sep 5. PMID: 17804467

iii. Regarding the Rome II diagnostic criteria for IBS

1. 	Thompson WG: Functional bowel disorders and functional abdominal pain. Gut 1999; 45 (Supplement II): II43-II47

iv. Regarding the IBSQOL questionnaire

1. 	Hahn BA, Kirchdoerfer LJ, Fullerton S, Mayer E: Evaluation of a new quality of life questionnaire for patients with irritable bowel syndrome. Alimentary Pharmacology & Therapeutics 1997; 11: 547-52.

2. 	Hahn BA, Kirchdoerfer LJ, Fullerton S, Mayer E: Patient-perceived severity of irritable bowel syndrome in relation to symptoms, health resource utilisation and quality of life. Alimentary Pharmacology & Therapeutics 1997; 11: 553-9.

3. 	Hahn BA, Saunders WB, Maier WC: Differences between individuals with self-reported irritable bowel syndrome (IBS) and IBS-like symptoms. Digestive Diseases & Sciences 1997; 42: 2585-90.

4. 	Hahn BA, Watson M, Yan S, Gunput D, Heuijerjans J: Irritable bowel syndrome symptom patterns; frequency, duration and severity. Digestive Diseases & Sciences 1998; 43: 2715-8.

5. 	Hahn BA, Yan S, Strassels: Impact of irritable bowel syndrome on the quality of life and resource use in the United States and United Kingdom. Digestion 1999; 60: 77-81.

6. 	Wells NEJ, Hahn BA, Whorwell PJ: Clinical economics review: irritable bowel syndrome. Alimentary Pharmacology & Therapeutics 1997; 11: 1019-30.

7. 	Strassels SA, Hahn BA: Comparison of irritable bowel syndrome quality of life (IBSQOL) scores between patients in the United States and United Kingdom. Gastroenterology 1997; 112: A44.

8. 	Strassels SA, Hahn BA: Work or career changes among patients with irritable bowel syndrome (IBS) in the United States. Gastroenterology 1997; 112: A44.

9. 	Strassels SA, Hahn BA: Resource use among patients with irritable bowel syndrome (IBS) in the United States. Gastroenterology 1997; 112: A832.

10. 	Strassels SA, Hahn BA: Short-form 36 (SF-36) scores in patients with irritable bowel syndrome (IBS) compared with US norms. Gastroenterology 1997; 112: A832.

11. 	Watson MW, Lacey LA, McSorley D, Northcutt A, Mangel AW: Impact of alosetron on health-related quality of life (HRQOL) in female patients with irritable bowel syndrome (IBS). Poster presentation, Wednesday, 10.30am-4pm, 20 October. American College of Gastroenterology (Phoenix, 18-20.10.99).

12. 	Lacey LA, McSorley D, Northcutt A, Mangel AW: Impact of alosetron on health-related quality of life (HRQOL) and productivity in female patients with irritable bowel syndrome (IBS). United European Gastroenterology Week (Rome, 15-17.11.99).

v. Regarding the EORTC Quality-of-Life-Questionnaire

1. 	Aaronson NK, Ahmedzai S, Bergman B, Bullinger M, Cull A, Duez NJ, Filiberti A, Flechtner H, Fleishman SB, de Haes JC, et al: The European Organization for Research and Treatment of Cancer QLQ-C30: a quality-of-life instrument for use in international clinical trials in oncology. J Natl Cancer Inst 85: 5, 365-76, Mar 3, 1993.

2. 	Kaasa S, Bjordal K, Aaronson N, Moum T, Wist E, Hagen S, Kvikstad A: The EORTC core quality of life questionnaire (QLQ-C30): validity and reliability when analysed with patients treated with palliative radiotherapy. J Cancer 31A: 13-14, 2260-3, Dec, 1995.

3. 	Osoba D, Zee B, Pater J, Warr D, Kaizer L, Latreille J: Psychometric properties and responsiveness of the EORTC quality of Life Questionnaire (QLQ-C30) in patients with breast, ovarian and lung cancer. Qual Life Res 3: 5, 353-64, Oct, 1994.

4. 	Bergman B, Aaronson NK, Ahmedzai S, Kaasa S, Sullivan M: The EORTC QLQ-LC13: a modular supplement to the EORTC Core Quality of Life Questionnaire (QLQ-C30) for use in lung cancer clinical trials. EORTC Study Group on Quality of Life. Eur J Cancer 30A: 5, 635-42, 1994.

5. 	Maher EJ, Mackenzie C, Young T, Marks D: The use of the Hospital Anxiety and Depression Scale (HADS) and the EORTC QLQ-C30 questionnaires to screen for treatable unmet needs in patients attending routinely for radiotherapy. Cancer Treat Rev 22 Suppl A: 123-9, Jan, 1996.

6. 	Kaasa S: Using quality of life assessment methods in patients with advanced cancer: a clinical perspective. Eur J Cancer 31A Suppl 6: S15-7, 1995.

7. 	Niezgoda HE, Pater JL: A validation study of the domains of the core EORTC quality of life questionnaire. Qual Life Res 2: 5, 319-25, Oct, 1993.

8. 	Kosmidis P: Quality of life as a new end point. Chest 109: 5 Suppl, 110S-112S, May, 1996.

9. 	Speca M, Robinson JW, Goodey E, Frizzell B: Patients evaluate a quality of life scale: whose life is it anyway? Cancer Pract 2: 5, 365-70, Sep-Oct, 1994.

10. 	Wisloff F, Eika S, Hippe E, Hjorth M, Holmberg E, Kaasa S, Palva I, Westin J: Measurement of health-related quality of life in multiple myeloma. Nordic Myeloma Study Group., Br J Haematol 92: 3, 604-13, Mar, 1996.

11. 	Schaafsma J, Osoba D: The Karnofsky Performance Status Scale re-examined: a cross-validation with the EORTC-C30. Qual Life Res 3: 6, 413-24, Dec, 1994.

12. 	Blazeby JM, Williams MH, Alderson D, Farndon JR: Observer variation in assessment of quality of life in patients with oesophageal cancer. Br J Surg 82: 9, 1200-3, Sep, 1995.

13. 	Bjordal K, Ahlner-Elmqvist M, Tollesson E, Jensen AB, Razavi D, Maher EJ, Kaasa S: Development of a European Organization for Research and Treatment of Cancer (EORTC) questionnaire module to be used in quality of life assessments in head and neck cancer patients. EORTC Quality of Life Study Group. Acta Oncol 33: 8, 879-85, 1994.

14. 	Blazeby JM, Williams MH, Brookes ST, Alderson D, Farndon JR: Quality of life measurement in patients with oesophageal cancer., Gut 37: 4, 505-8, Oct, 1995.

15. 	Hjermstad MJ, Fossa SD, Bjordal K, Kaasa S: Test/retest study of the European Organization for Research and Treatment of Cancer Core Quality-of-Life Questionnaire. J Clin Oncol 13: 5, 1249-54, May, 1995.

16. 	Bjordal K, Freng A, Thorvik J, Kaasa S: Patient self-reported and clinician-rated quality of life in head and neck cancer patients: a cross-sectional study. Eur J Cancer B Oral Oncol 31B: 4, 235-41, Jul, 1995.

17. 	Ringdal GI, Ringdal K: Testing the EORTC Quality of Life Questionnaire on cancer patients with heterogeneous diagnoses. Qual Life Res 2: 2, 129-40, Apr, 1993.

18. 	Sprangers MA, Cull A, Bjordal K, Groenvold M, Aaronson NK: The European Organization for Research and Treatment of Cancer Approach to quality of life assessment: guidelines for developing questionnaire modules. EORTC Study Group on Quality of Life. Qual Life Res 2: 4, 287-95, Aug, 1993.

Further information

Please also review "Help" - "Questionnaire history..." for each *.qdw questionnaire-definition-file to obtain questionnaire specific information, author's addresses, or literature references.

Contact adresses and sources of further information are listed here.


Sources of further information

To get further information about the Quality-of-Life-Recorder, you can consult available literature or contact me.

If you would like to contact people using the Quality-of-Life-Recorder with AnyQuest for MSDOS or AnyQuest for Windows, please feel free to ask me.

If you need general information about the concept of quality of life, about available questionnaires and copyright owners, or if you need practical assistance, you can either contact myself or Prof. Franz Porzsolt from the Arbeitsgruppe Klinische Ökonomik.

If you like, you can have a look at my homepage on the WWW where I'm going to provide further information including a literature reference. From time to time, it will be updated and I will continue to add pages:

http://www.jsigle.com

http://www.ql-recorder.com

My Web-Site also reports on other projects that I completed. Included: Complete routine evaluation of Evidence Based Medicine (EBM) oriented student education using the QL-Recorder. Market survey for Hospital Information Systems. Teleradiology - Costs versus benefit analysis.

If the address above should have changed in the future, please use one of the popular search engines to locate the new address.

To get further information about the EORTC Quality-of-Life-Questionnaire, please contact the EORTC Quality-of-Life-study-group..


EORTC contact addresses

Contact address of the EORTC Quality-of-Life-study-group

Please direct inquiries regarding the EORTC QLQ to:

Ms. Karen West

EORTC

European Organisation for Research and Treatment of Cancer

Data Center

Quality of Life Unit

Avenue E. Mounier 83 - Bte 11

1200 Brussels, Belgium

Tel.:  	+32-2-7741667

Fax: 	+32-2-7726701

e-mail: 	qlu@eortc.be


Glaxo Wellcome plc. contact addresses

IBSQOL contact addresses at Glaxo Wellcome plc.

Please direct inquiries regarding the IBSQOL CD-ROM to:

Ms. Rhoda Luer

Global Health Outcomes

Glaxo Wellcome R&D

Greenford Road

Greenford

Middlesex

UB60HE, UK

Tel.:  	44 (0) 208 966 2206

Fax: 	44 (0) 208 966 2193

e-mail: 	rl30622@glaxowellcome.co.uk

Please direct inquiries regarding the IBSQOL instrument to:

Dr. Beth Hahn

Global Health Outcomes

Glaxo Wellcome

5 Moores Drive

PO Box 13398

Research Triangle Park

North Carolina 27709


Arbeitsgruppe Klinische Ökonomik, University of Ulm

The Arbeitsgruppe Klinische Ökonomik at the University of Ulm, Germany

This group, initiated by Prof. Franz Porzsolt, works in theoretical and practical aspects of quality of life measurement.

The group provides general information about quality of life measurement, as well as special information about instruments currently available for this purpose. Besides their research activities, the group designs and implements integrated concepts for practical application of quality of life measurement. They also offer educational and training services covering quality of life related topics.

In 1993, Prof. Porzsolt was Secretary of the Cancer Centre of the University of Ulm. He asked me for an electronic tool for quality of life measurement: this was where and when I started the development of the original Quality-of-Life-Recorder.

Prof. Franz Porzsolt

AG Klinische Ökonomik

Universität Ulm

Steinhövelstraße 9

89075 Ulm, Germany

Fax +49-731-502-6733

e-mail: franz.porzsolt@medizin.uni-ulm.de


Printer Setup...

Setting up the printer for the single, cumulative and questionnaire-filled-in

This page contains (at least) the following sections:

•	"Printing" - "Printer Setup...": Selecting which output goes to which printer or file printouts

•	"Printing" - "General printout options..."

•	"Printing" - "Single printout options..."

•	"Printing" - "Cumulative printout options..."

•	"Printing" - Special printout options; test and reference printouts

•	How AnyQuest handles various sources of printout control settings, how to statically redirect printouts to a file, and how to use whatever printer is available

•	Printing reference ranges and reference values supplied by external *.val and *.rng files

•	Enhanced printout configurability using *.pdc or *.pds or *.pdq files

•	Automatically archiving printouts in PostScript or PDF format

•	Printjob names

Please note that in more recent versions of AnyQuest for Windows, all printing related configuration settings may be located in central configuration file which is typically named z:\anyquin\project\config\common\printout.ini and accessed from other configuration files *.ini through the cascading configuration files mechanism.

"Printing" - "Printer Setup...": Selecting which output goes to which printer or file

To setup the printer(s) you wish to use for the various types of printouts, you can either directly edit the *.ini configuration file entries, or from the "Printing" menu, select "Printer setup...".

This opens the "Advanced printer setup" dialog. Here you can specify individual printer targets for different types of printouts. These can be real printers, virtual printers, or files, all accessible through all the various printer instances installed on your system.

Additionally, second printers can be specified for several types of printouts. If a second printer is specified for a printout, two copies are generated automatically. This is helpful e.g. if you want to print one copy of a cumulative result printout on a PDF generator (e.g. PDFCreator or FreePDF or Adobe Acrobat Distiller), so that it can be archived or imported into your electronic patient file, and a second copy on a real laser printer, so that it can be handed out to the patient.

To select and configure each printer, use the button that belongs to each printout type. Each printer can be given only one configuration in this dialog, even if it is used for multiple printout types. If you need different configurations for different printout types on the same printer (e.g. portrait single printout and landscape cumulative printout), you can use additional printer configuration definition files explained below.

To remove any specified printer, use the button with the x next to it.

Please note: The "Cancel" button in this dialog cannot undo removal of printers or changes already selected with individual printer configuration buttons; it can only ignore any changes manually entered to the output port text fields, which have not been committed yet.

For each selectable printer, you can also directly specify the output port:

1. 	If you enter reserved names like LPT1: etc. here, the printout will go to the respective interface.

2. 	If you enter the special port FILE: here, printing to this printer will cause a dialog to appear, where you can enter a filename, where the printout data will be stored.

3. 	If you enter a real filename like c:\anyquin\printouts\single.ps here, this filename will be directly used to store the printout data from this printer, without any dialog displayed before. However, each succeeding printout to the same filename will overwrite the previous one, so you can either use the result file only temporarily, or must make sure that it is copied away before the next printout to the same file is made. This method may be especially helpful if you want to view repeated test printouts with GhostScript/GhostView during questionnaire development (the viewer can remain open and will update its display when a new printout is available), or if you have an automated processor like GhostScript/FreePDF that will postprocess your output immediately.

4. 	If you enter a virtual printer port (e.g. eSIRO:) as provided through a dedicated, suitably configured GhostScript/FreePDF printer here, FreePDF can automatically generate individually named PDFs from your printouts. Naming and archiving them into a given directory will be performed by FreePDF in this case, so it is not necessary to supply a directory or filename here for such a configuration. Please review the manuals from the eSIRO project available on my WWW site for further information.

You can select any printer which is available in your Windows environment, including fax-modems. So you can make your printouts appear on a remote network printer or on a fax in any other location.

If there is no printer configured, or if the configured printer is not available any more, when AnyQuest for Windows is going to print, it will try to use a system default printer. If none is available, it will give you the opportunity to select a valid printer.

To customize the appearance of the generated printouts on a basic level, select the different "Printout options..." from the "Printing"-menu.

To customize the appearance of the generated printouts on a very advanced per-printout, or per-questionnaire level for multi-questionnaire configurations, please use so called "Printout definition files" - more information is available further down on this page.

To customize the appearance of reference values and reference ranges - please also read further down on this page.

Advanced printer setup with multiple target support is available since Version 3.15.

If no printers are configured (i.e. the *.ini file contains no usable entries), AnyQuest tries to use the default printer of the system and automatically enters it as target for "Single" result printouts. If no different configuration is entered for "QFI" and "Cumul" results, they use the same printer target. All manually generated printouts, however, will not try to use the target entered for "Single" printouts. Instead, if no targets are specified specifically for them, they will either use the default system printer, or show a printer selection dialog.

All printouts created from the "Analysis tools" dialogs go to the "Statistics" and "Statistics 2" printout targets, even if they are ex post created standard single or standard cumulative result printouts.

Immediate second copies to second printout targets are only automatically generated, if second printout targets are specified in the respective fields. If a specific target is specified e.g. for "Cumul 2", but "Cumul" is empty, then the first copy of the cumulative result printout will appear on the "Single" result (default) target, whereas the second copy will appear where specified by the entry for "Cumul 2". The same applies to "QFI" and "QFI 2".

For any type of automatic printouts to be generated, the respective options in the "Printing" menu must be checked, and - depending upon another option in the "Printing" menu, the questionnaire from which you want to generate a printout must contain any printable data. This may even apply to test printouts, so either uncheck the respective option or enter some data into a questionnaire from which you want to generate a test printout.

Whereas "Single result" and "Cumulative result" printouts can be generated ex post (and even in batch mode) from the "Analysis tools" dialogs, there is no (comfortable) way to generate "Questionnaire filled in" printouts later on. If you need this type of printout, please let AnyQuest generate them automatically immediately after each questionnaire administration - if you want to save paper, have them generated as PDFs. These printouts may be helpful as a detailed recording of the questions and answers a patient gave in a certain session. I feel that being able to retrieve this kind of information is helpful to demonstrate that the physician/interviewee takes notice of all of the information the patient/interviewed has entered into the computer, so I recommend the generation of QFI printouts even though some questionnaire definition files may deliver only limited layout quality here. As an example, if your Quality of Life questionnaire includes questions like "Did you have pain?", and the patient fills in such a questionnaire before a consultation, and the physician asks the same question again during the consultation, instead of being able to look up the recording, the patient may be somewhat bewildered.

If you use the "Configure printer" button from any of the "Analysis tools" dialogs instead, you will not get to the advanced printer setup dialog, but directly to the printer configuration dialog for the first statistics printout target.

"Printing" - "General printout options..."

A dialog box will allow you to define the lines which will be added to the end of your printouts. You might wish to use the name of your institution or of your project as trailer strings.

For all kinds of printouts, you can specify the size of print margins in millimeters. The margins are measured from the printable area of the used printer. AnyQuest does not zoom down all contents of the printout, but primarily rearrange them within the provided space. So specifying extremely large margins can result in undesirable printouts.

Since version 2.64, you can also deactivate the printing of a variety of components (header, trailer and so on), in order to simplify the standard printout.

"Printing" - "Single printout options..."

Here you can select a variety of options to control the appearance of the generated graph for single printouts: e.g. switching from individual cross-marks to a graph conecting individual circles to a profile, or to a bargraph, control x and y axis details, etc.

Since version 3.47, many of these options can overridden per defined printout section by specifying respective parameters in an enhanced printout definition *.pds file (see below). This enables you to use graphs of different type and appearance on the same printout, or in the same configuration including multiple questionnaire definition files.

You can also set the width of the bargraphs on your printouts.

You can chose to add printing of reference values or reference ranges to your cumulative printouts. You can either chose to use "static" or "dynamic" data for this purpose.

If you want to print dynamic reference values or ranges, you can select the statistical parameters which shall be computed for this purpose. You can also select, how many of the most recent measurements shall be evaluated for these computations. Computations are performed on data files from the target data directory after results of the current session have been stored there.

While "dynamic" data are computed by AnyQuest itself whenever a reference value or range shall be printed, "static" data are loaded from external text files (see details below). These text files can be kept really static or supplied dynamically using an external program that may be called from inside AnyQuest for Windows just in time.

"Printing" - "Cumulative printout options..."

Here you can select a variety of options to control the appearance of the generated graph for cumulative printouts: e.g. switching from individual circle marks to a graph connecting individual marks to a profile, or to a bargraph, control x and y axis details, etc.

Since version 3.47, many of these options can overridden per defined printout section by specifying respective parameters in an enhanced printout definition *.pdc file (see below). This enables you to use graphs of different type and appearance on the same printout, or in the same configuration including multiple questionnaire definition files.

You can also set the maximum number of previous sessions whose results will be displayed on one cumulative printout.

If less sessions than the maximum number are available, you can chose whether their bargraphs shall be broadened to use all available space.

You can chose to add printing of reference values or reference ranges to your cumulative printouts. You can either chose to use "static" or "dynamic" data for this purpose.

If you want to print dynamic reference values or ranges, you can select the statistical parameters which shall be computed for this purpose. You can also select, how many of the most recent measurements shall be evaluated for these computations. Computations are performed on data files from the target data directory after results of the current session have been stored there.

While "dynamic" data are computed by AnyQuest itself whenever a reference value or range shall be printed, "static" data are loaded from external text files (see details below). These text files can be kept really static or supplied dynamically using an external program that may be called from inside AnyQuest for Windows just in time.

"Printing" - Special printout options; test and reference printouts

A variety of commands and options in the "Printing"-menu can be used to generate test printouts for several printout types, turn on the printing of some annotated XY coordinates in general printouts, or even to produce a reference printout. All of these options may be very helpful during more advanced printer configuration, and during questionnaire development.

How AnyQuest handles various sources of printout control settings, how to statically redirect printouts to a file, and how to use whatever printer is available

When AnyQuest for Windows starts, it first retrieves the current Windows standard printer and extended device mode settings.

Afterwards, it reads anyquin.ini (or any other *.ini file specified during startup). This may contain a section [Printout] with the options SinglePrnDev, SinglePrnDrv and SinglePrnOut, telling AnyQuest to use another printer or port. It may also contain sections specifying extended device mode options for one or more printers. Such asection might be headed e.g.  [QMS magicolor plus Level 2,winspool,FILE:] (depending upon your printer/s), and provide settings for paper orientation, number of copies and so on. Any entries found in such a configuration file override current Windows standard printer settings.

As long as AnyQuest can get a respective printing device context with the resulting information, it will automatically use the resulting printer and device mode settings (Please note: Versions before 2.63 would always show a printer setup dialog when no printer definition information was found in the *.ini file, namely whenever any shipped configuration file was used for the first questionnaire presentation session).

However, if one or multiple printer settings are invalid, it may be impossible for AnyQuest to get a printing device context. AnyQuest handles this situation as follows:

If the SinglePrnDrv entry in *.ini is invalid, which means that the specified printer driver cannot be used, AnyQuest may show an error message upon startup when trying to contact the non-existing printer driver, and afterwards use the current Windows standard printer.

If the SinglePrnDev entry in *.ini is invalid, AnyQuest may show a printer selection dialog before trying to generate the first printout, and afterwards use the printer you select using this dialog.

The SinglePrnOut entry cannot appear recognizably invalid to AnyQuest at the moment. It may specify either a local printer port, e.g. LPT1: or a network printer service, e.g. \\PrnServer\Laser) or the term FILE: which causes a dialog to appear before printout is generated asking for a filename. It may also specify a filename directly (e.g. printout.ps) which causes printout to be written directly into the specified file without any questions being asked (please note that the file is overwritten each time you generate a new printout). If the target file or output port is write protected or otherwise unaccessible, AnyQuest will not be affected directly, but the Windows printer spooler will generate a notification and show an appropriate dialog.

Please note: I observed that specifying a non-existent network printer device together with the HPPCL5MS driver in Windows 2000 resulted in some versions AnyQuest causing a GPF upon startup. Specifying the same non-existent network printer device with the WINSPOOL driver, or when driver and device where left empty, did not cause a problem. Recent versions of AnyQuest should have been improved to work even in this situation - see "product history" in the on-line-help file and comment below. If you should still observe similar problems, please let me know.

AnyQuest's current settings are written to the current anyquin.ini file when AnyQuest for Windows is closed, as long as this *.ini file is not write protected or otherwise unaccessible.

The printer setup dialog within AnyQuest for Windows can be used to change current AnyQuest for Windows settings with immediate effect at any time. As soon as AnyQuest is closed afterwards, it will try to write the new settings to its current anyquin.ini file when AnyQuest is closed.

Finally, any settings (especially regarding paper orientation) found in a *.pdc or *.pds or *.pd1 file when a cumulative or single or questionnaire-filled-in printout is generated, will override any other settings currently active.

If you experience problems with printing, please close AnyQuest, then try to locate c:\anyquin\anyquin.ini or whatever *.ini file you specify during startup of your current configuration, and remove the above mentioned printer related entries from this file with a text editor. Afterwards restart AnyQuest using the same configuration file.

If you want to use whatever standard printer is available at whatever local workstation connected to a network where all workstations share the same *.ini file, please remove all printer information from the *.ini file and afterwards write protect it to assure that no AnyQuest running on a certain workstation can write its only locally valid printer information into that file.

Please note that printing functionality was significantly enhanced between versions 2.61 and 2.66. It is recommended to use version 2.66 or above to ensure correct handling of various printer configuration sources. Please review the product history for version related details.

Printing reference ranges and reference values supplied by external *.val and *.rng files

If you want to print "static" reference values or ranges, they have to be supplied in text files which have the same base filename and are located in the same directory as the *.qdw file they accompany.

The files *.val and *.rng are used to supply a basic form of reference values and reference ranges. More complex, and even dynamically changeable reference values and reference ranges are also supported; see another section below.

Usually, these text files will only be prepared once and remain unchanged throughout the usage of the questionnaire, so that the same reference values or ranges are printed in all printouts generated by them. An alternative way would be to prepare a variety of reference files e.g. in a subdirectory, and at some time (e.g. after results have been computed, or at any other point during questionnaire presentation) a UPN formula can call an external application to put the preferred reference value file(s) in the place where they will be found when the printout is about to be generated. Thus, you can also include reference values and ranges which can be generated and provided completely by external infrastructure.

The file that supplies data for reference values must be named *.val. It consists of one line for each of: a short label, a long label, and a reference value for each computed result dimension.

This is an example of a reference value definition file *.val for a questionnaire with four result dimensions:

Med

median value found in 1034 measurements in normal population

33

14

50

45

The file that supplies data for reference ranges must be named They or *.rng. It consists of one line for each of: a short label for the upper limit, a short label for the lower limit, a long label for the upper limit, a long label for the lower limit, and for the values for both upper and lower limits for each computed result dimension.

This is an example of a reference range definition file *.rng for a questionnaire with four result dimensions:

Hi

Lo

Highest value of 1034 measurements in normal population

Lowest value of 1034 measurements in normal population

25

40

10

18

30

85

33

50

Any lines which you do not want to use (for definition of labels, or for definition of values) can remain empty.

Enhanced reference values and reference ranges using *.rvs or *.rvc or *.rrs or *.rrc files

These files are generally handled *.val or *.rng files. However, they define complex, and even dynamically changeable reference values and reference ranges. Additional complexity includes:

•	Completely freely definable reference values, reference ranges, and reference labels per graph,

•	multiple references per graph,

•	dotted or solid lines for reference values,

•	freely definable colour per reference value or range,

•	definable y-extension and y-offset per reference value or range,

•	various key (Legende) formats and freely definable key (Legende) content,

•	conditional production of references and keys (legends) based upon multiple variables including result number, sex and age of patient,

•	still relatively comfortable format for reference definition.

Reference definitions from these files are interpreted when each graph is generated. *.rvs and *.rrs files are used when a single printout is produced. *.rvc and *.rrc files are used when a cumulative printout is produced. *.rrs or *.rrc files (recommended for definition of reference ranges) are interpreted before *.rvs or *.rvc (recommended for definition of reference values) files, so if the recommendations are followed, reference value lines will be plotted after (=over) reference range bars. However, any definition can be supplied in any sequence in any file which is evaluated for a given printout.

Advanced reference definition files can be used together with older basic reference definition files; and colours of references from basic definition files as well as colours of references from internal live-statistics functions can be specified from advanced reference definition files.

Statements in an advanced reference defintion file which begin with a ; (semicolon) or # (sharp) are comments, and ignored.

Valid statements generally have a TAG:VALUE format, and statements are separated by tabs or by newlines.

For statements that have an empty value, the : (colon) may be omitted.

All content after a condition statement CND:... which evaluates to false, is ignored.

Multiple statements can be placed into a single line, up to 255 characters per line.

Definitions remain active until they are reset, or until the next graph is drawn (depending upon the item).

For most items that occur in multiple instances, up to 255 instances are supported.

The following statements are supported within advanced reference definition files:

RANLF:         Reserve additional lines in the key (Legende) area,

               in addition to space reserved due to requests from other sources.

LF:            Define text for short key (Legende) portion.

LFL:           Define text for the long key (Legende) portion.

PLFDL:         Print a legend entry at page footer with a dotted line.

               This may result in:

               ..... = LF = LFL   if both LF and LFL are non-empty,

               ..... = LFL        if only LFL is non-empty,

               ..... = LF         if only LF is non-empty.

PLFSL:         Print a key (Legende) entry at page footer with a solid line.

PLFR:          Print a key (Legende) entry at page footer with a solidly filled bar.

PLFC:          Print a key (Legende) entry at page footer as plain comment, i.e. without line or bar.

VLG:           Define text for the key (Legende) printed next to/above a reference value line in a graph.

RLG1:          Define text for the key (Legende) printed next to/below one limit of a reference range bar in a graph.

RLG2:          Define text for the key (Legende)printed next to/below the other limit of a reference range bar in a graph.

PSL:           Print a solid reference value line in a graph.

PDL:           Print a dotted reference value line in a graph.

VY:            Define the y-value for a reference line in a graph.

RY1:           Define the y-value for one limit of a reference range bar in a graph.

RY2:           Define the y-value for the other limit of a reference range bar in a graph.

PR:            Print a solid reference range bar in a graph.

COLLR:         Define the red color value for a reference line (0..255).

COLLG:         Define the green color value for a reference line (0..255).

COLLB:         Define the blue color value for a reference line (0..255).

COLRR:         Define the red color value for a reference bar (0..255).

COLRG:         Define the green color value for a reference bar (0..255).

COLRB:         Define the blue color value for a reference bar (0..255).

COLEXTLR:      Define the red color value for a reference line produced by a *.val file (0..255).

COLEXTLG:      Define the green color value for a reference line produced by a *.val file (0..255).

COLEXTLB:      Define the blue color value for a reference line produced by a *.val file (0..255).

COLEXTRR:      Define the red color value for a reference bar produced by a *.rng file (0..255).

COLEXTRG:      Define the green color value for a reference bar produced by a *.rng file (0..255).

COLEXTRB:      Define the blue color value for a reference bar produced by a *.rng file (0..255).

COLINTLR:      Define the red color value for a reference line produced by internal live-statistics (0..255).

COLINTLG:      Define the green color value for a reference line defined by internal live-statistics (0..255).

COLINTLB:      Define the blue color value for a reference line defined by internal live-statistics (0..255).

COLINTRR:      Define the red color value for a reference bar defined by internal live-statistics (0..255).

COLINTRG:      Define the green color value for a reference bar defined by internal live-statistics (0..255).

COLINTRB:      Define the blue color value for a reference bar defined by internal live-statistics (0..255).

LXTNUP:        Define the upward extension of a reference value line (-xtnmax ... +xtnmax, otherwise ignored).

LXTNDN:        Define the downward extension of a reference value line.

LXTNLT:        Define the left extension of a reference value line.

LXTNRT:        Define the right extension of a reference value line.

RXTNUP:        Define the upward extension of a reference range bar.

RXTNDN:        Define the downward extension of a reference range bar.

RXTNLT:        Define the left extension of a reference range bar.

RXTNRT:        Define the right extension of a reference range bar.

LBLOFS:        Define an offset to shift a reference label.

CND:           Define a condition. If that evaluates to False, the remainder of the current line is ignored.

               Conditions consist of: PARAMETER RELATION REFERENCE, separated by spaces.

               Parameters and references are converted to uppercase before evaluation.

               Supported parameters are:

               RFN       Result formula number of the currently produced graph.

               PIDAGE    Age of patient as currently stored in the PID data section.

               PIDSEX    Sex of patient as currently stored in the PID data section.

               Supported relations are:

               = == EQ             Equality for extended or string variables.

               =I ==I EQI          Equality for integer or string variables.

               != <> NE            Inequality for extended or string variables.

               !=I <>I NEI         Inequality for integer or string variables.

               < LT                Lower than.

               =< <= LE            Lower or equal.

               > GT                Greater than.

               => >= GE            Greater or equal.

               If the reference parameter in a numerical comparison is undefined,

               the result of the evaluation will be false.

Using these commands, you can implement things like lightly shaded background areas for graphs, ranging from green (good) over yellow, orange to red (bad), using the same or individual numerical anchor points for multiple graphs (see TTM example configuration from anypak).

You can also implement the display of a general population reference range and value in light gray, and above that, an age and gender specific reference range and value in light red (for females) or blue (for males), that has smaller y-extension so that the grey reference range and value can always be seen through. This can be combined with a dynamically adopted key (Legende) as well, which will show which reference population was used for this printout (see FLZMseq example configuration from iftpak).

Since version 3.30, the key (Legende) for automatically computed statistical reference values can display both the configured maximum (in brackets, if different from) and the actually processed (usually due to availability or to missing values in individual files) number (or range of numbers) of files.

You can learn more from partially commented examples of advanced reference definition files, which are supplied with several configurations in the anypak.exe package.

Enhanced printout configurability using *.pdc or *.pds or *.pdq files

Since version 2.64, to control the appearance of the cumulative printout beyound AnyQuest's automatic layout generation capabilities, you can provide an additional *.pdc file for each *.qdw file with the same base filename and located in the same directory.

Later versions of AnyQuest adopted this capabaility to support extended configurations for single printout and questionnaire-filled-in-printout. Please review commented examples of these files and example printouts in PDF format available on AnyQuest's WWW site to obtain further information.

A printout definition file is a text file that can supply various configuration parameters, controling:

•	Printout orientation (portrait/landscape)

•	Number of copies

•	Division of graphs into sections (e.g. 15 result graphs can be divided into two sections, one for functions and one for symptoms).

Each defined section currently is given printing space in a horizontal strip on the generated printout page. If not specified otherwise, all sections will receive the same vertical space. For each section, the following parameters can be controlled:

•	Text of a headline or explanation for this section

•	Overriding specification of relative vertical space in proportion to other sections

•	Overriding specification of numbers of rows to allocate for graphs in this section

•	Overriding specification of numbers of columns to allocate for graphs in this section

•	Whether automatically generated y-axis labels shall be displayed or suppressed, for the minimum, 1/4, 1/2, 3/4 and maximum positions (since version 3.40)

•	Whether the numerical result for each graph shall be displayed (left of the graph for the single printout, or inside/above each bar, for the cumulative printout) (since version 3.40)

•	The colours to be used for the strongpen and dottedpen used to draw the x-axis, y-axis, and extreme limits of the graph area (since version 3.40)

•	Number of color definition anchor points in this section

•	Whether defined color anchor points shall be proportionally spread over the complete number of bars defined to be printed in each graph by the cumulative printout option setup.

The color anchor points control how colors are used when bars are printed.

•	Each color anchor point defines a single bar number and a Red/Green/Blue color specification that shall be used to print this bar.

•	Colors are interpolated between defined anchors.

•	When proportional spreading of anchors over bars is not activated, bars with numbers below the lowest bar number that is referenced in any color definition anchor, receive the same color that is specified for this lowest bar number. Similarly, bars with numbers above the highest bar number, that is referenced in any color definition anchor, receive the same color that is specified for this highest bar number.

Depending upon the printout type, additional parameters can be defined to control color changes (hard or soft) at defined cutoff points, combining of graphs into coordinate systems, appearance of labels at graphs, appearance and arrangement type of labels in questionnaire-filled-in-printouts, vertical spacing between individual results, appearance of a frame indicating where to put a patient ID sticker, precise movement of individual printout components on the page, individual header and footer lines (additional or replacing standard headers and footers) e.g. to include a prompt to sign the printout by a responsible colleague and to phone a given number on certain conditions, inclusion of logos in the page header and footer area (additional or replacing standard headers and footers), moving of the standard copyright message for the software to a page margin in vertical fine gray print, and others. The list of controllable options is enhanced whenever new options are required by users.

The following sections and parameters can be used. Regarding the values, "byte" must be replaced by a number from 0 to 255, "integer" must be replaced by a number from 0 to 32767, and "#" in a parameter name shall be replaced by the section number or color anchor number to which the given definition applies. Valid bar numbers and section numbers start with 1. "string" shall be replaced by the character string which you want to be printed.

You might review the "product history" section of this on-line-help file, and also study exemplary configuration files provided, to learn about additional parameters which might not be covered below so far.

[general]

orientation=integer                       (0: don't change. 1: portrait. 2: landscape)

copies=integer                            (0: don't change anything)

fontsize_scaling_single=integer           (in percent, default=100)

fontsize_scaling_small=integer

fontsize_scaling_small_vertical=integer

dyspacerscaling=integer

dygraphscaling=integer

f_move_pid_into_psf=Boolean               (default: False)

f_suppress_results_heading=Boolean

f_suppress_duration_of_assessment=Boolean

f_simple_date_of_assessment=Boolean       (*.pdq, *.pds, *.pdc - with slightly different effects)

pdqxsimpledate=string                     (only for *.pdq, default: "Datum:")

pdsxsimpledate=string                     (only for *.pds, default: "Datum:")

pdcxdatestimesofassessments=string        (only for *.pdc, default: no string and no line used, suitable example: Messzeitpunkte:)

f_align_ydoa_with_pid=Boolean

dydoashift=integer                        (in percent, shifts date of assessment in y direction)

dypidshift=integer

awfwidth=integer                          (only for *.pdq, in percent, default: 40)

f_label_printing_reduced=integer          (only for *.pdq, in percent, default: 80)

f_label_printing_rearrange=boolean        (only for *.pdq, default: False)

numofheaderentries=byte                   (definition of custom header lines)

headerentry#align=L|C|R                   (alignment and text can be specified for each line)

headerentry#text=string

numoffooterentries=byte                   (definition of custom footer lines)

footerentry#align=L|C|R                   (alignment and text can be specified for each line)

footerentry#text=string

[sections]

numofsections=integer

section#numofdytoaddbefore=single         (only for *.pds, default 0, range -100..100, single precision floating point number,

                                                           changes current y position before section is displayed, can be used

                                                           to fine tune y distance between sections or even to completely change

                                                           the order in which sections appear on the printout from top to bottom,

                                                           supported since version 3.43)

The default value for the vertical space proportion is 1, resulting in equal distribution of space if no overriding values are specified.

section#yspaceproportion=integer

section#allocatecolumns=integer           (only for *.pdc)

section#allocaterows=integer              (only for *.pdc)

section#numofquestions=integer            (only for *.qfi)

section#numofresults=integer              (only for *.pds)

section#numofgraphs=integer               (only for *.pdc)

section#explanation=string

section#nominmaxlabels=True|False         (for *.pds and *.pdc, suppression of automatically generated numerical y-axis labels)

section#noq1q3labels=True|False           (for *.pds and *.pdc)

section#noq2labels=True|False             (for *.pds and *.pdc)

section#noqnumvalues=True|False           (for *.pds and *.pdc, suppression of numerical value to be displayed next to (or inside) graph bars)

section#AutoSinglePrintoutCross=True|False                        (only for *.pds, per section override of current graph configuration)

section#AutoSinglePrintoutCircle=True|False                       (only for *.pds, supported since version 3.47)

section#AutoSinglePrintoutConnectingLines=True|False              (only for *.pds)

section#AutoSinglePrintoutStrongHL=True|False                     (only for *.pds)

section#AutoSinglePrintoutDottedHL=True|False                     (only for *.pds)

section#AutoSinglePrintoutHL=True|False                           (only for *.pds)

section#AutoSinglePrintoutCoordsXAxis=True|False                  (only for *.pds)

section#AutoSinglePrintoutCoordsYAxis=True|False                  (only for *.pds)

section#AutoSinglePrintoutBar=True|False                          (only for *.pds)

section#AutoSinglePrintoutBarFilled=True|False                    (only for *.pds)

section#AutoSinglePrintoutDottedMax=True|False                    (only for *.pds)

section#AutoSinglePrintoutDottedTop=True|False                    (only for *.pds)

section#AutoSinglePrintoutValues=True|False                       (only for *.pds)

section#AutoSinglePrintoutYDottedValue2=True|False                (only for *.pds)

section#AutoSinglePrintoutYDottedValue4=True|False                (only for *.pds)

section#AutoSinglePrintoutYaxisLabel2=True|False                  (only for *.pds)

section#AutoSinglePrintoutYaxisLabel4=True|False                  (only for *.pds)

section#AutoSinglePrintoutJoinGraphsWithSameStructure=True|False  (only for *.pds)

section#AutoCumulativePrintoutFixBarWidth=True|False              (only for *.pdc, per section override of current graph configuration)

section#AutoCumulativePrintoutBarFilled=True|False                (only for *.pdc, supported since version 3.47)

section#AutoCumulativePrintoutDottedMax=True|False                (only for *.pdc)

section#AutoCumulativePrintoutDottedRight=True|False              (only for *.pdc)

section#AutoCumulativePrintoutBar=True|False                      (only for *.pdc)

section#AutoCumulativePrintoutCircle=True|False                   (only for *.pdc)

section#AutoCumulativePrintoutConnectingLines=True|False          (only for *.pdc)

section#AutoCumulativePrintoutValues=True|False                   (only for *.pdc)

section#AutoCumulativePrintoutYAxisLabel2=True|False              (only for *.pdc)

section#AutoCumulativePrintoutYAxisLabel4=True|False              (only for *.pdc)

section#AutoCumulativePrintoutYdottedvalue2=True|False            (only for *.pdc)

section#AutoCumulativePrintoutYDottedValue4=True|False            (only for *.pdc)

section#colorstrongpenr=byte              (for *.pds and *.pdc, color of strong pen used to draw x-axis and y-axis)

section#colorstrongpeng=byte              (for *.pds and *.pdc)

section#colorstrongpenb=byte              (for *.pds and *.pdc)

section#colordottedpenr=byte              (for *.pds and *.pdc, color of dotted pen used to draw graph area extremes)

section#colordottedpeng=byte              (for *.pds and *.pdc)

section#colordottedpenb=byte              (for *.pds and *.pdc)

Please note that while a cumulative printout spreads or changes colour over multiple bars from multiple measurements (which is mainly decorative), a single printout can spread or change colour over multiple renderslices within each bar (which allows you to define e.g. limits, up to where the bar appears in green, and above where it appears in red - see the eSIRO printout example on my WWW site).

Default values for red/green/blue colors are 128, resulting in a gray bar if no color is specified.

section#numofcoloranchors=integer

section#coloranchor#bar=integer        (for *.pdc)

section#coloranchor#renderslice=byte   (for *.pds)

section#coloranchor#r=byte

section#coloranchor#g=byte

section#coloranchor#b=byte

For the following parameter, a value of "0" means "no" and anything else means "yes".

section#stretchcoloranchors=byte

The following values can be used to change the bargraphwidth, and successively the position where printed results are left aligned to:

section#bargraphwidth=byte     (for *.pds, default: adopt value defined in *.qdw, since version 3.53)

section#minspacesbetweenlabelandxbargraphleft=integer     (for *.pds, default: -1000 = ignore = about 6 spaces, since version 3.53)

The second parameter of these can be used to reduce the distance between the label and the result. However, I found that 0 does obviously not lead to zero distance. Possibly, the algorithm to break labels, which are too long to fit in the available space into multiple lines, leaves some spare room. In order to allow you nevertheless to put label and result arbitrarily closely together, the second parameter can be either (left away or) set to -1000, so it is completely ignored, and about 6 spaces are retained as minimum distance between label and bargraph, numeric, or text result output. Or, it can be set to some value in the range of -500..500, actually defining the mimnimum reserved distance in sizes of spaces (to be added to the reserve that would automatically be chosen). A value of about -5 might cause label and result to appear very closely together.

The following is an example of a printout definition file *.pdc which can be used for the EORTC QLQ-C30. It separates the 15 dimensions into two sections: one for functions, including 6 graphs, and one for symptoms, including 9 graphs. To accomodate for the different number of graphs in each section, which will fit in 2 rows by 3 columns (section 1) and 3 rows by 3 columns (section 2), vertical space allocation is adjusted from 1:1 to 2:3. The sections receive individual headings and different color shading schemes.

;AnyQuest for Windows optional printer definitions for cumulative printout.

;This file refers to a corresponding *.qdw file in the same directory with the same base filename.

;Comments are identified by preceeding semicolon.

;Sequence of unique lines is unimportant.

;For alternative configurations in one file: first come, first serve.

;Jörg Sigle 2003-07-06

[general]

;It is possible to override the orientation currently chosen in

;AnyQuest's printer setup dialog here. This setting affects only

;the page controlled by this file. 1=portrait, 2=landscape

orientation=1

[sections]

numofsections=2

;------------------

;describe section 1

;------------------

;for portrait orientation:

section1yspaceproportion=2

section1numofgraphs=6

section1explanation=Functions: higher scores are preferred.

-----------------------------------------------------------------

;Make Symptom bars appear in blue, blended into green,

;stretched over all currently configured printable bars per graph

-----------------------------------------------------------------

section1numofcoloranchors=2

section1coloranchor1bar=1

section1coloranchor1r=0

section1coloranchor1g=0

section1coloranchor1b=255

section1coloranchor2bar=2

section1coloranchor2r=0

section1coloranchor2g=255

section1coloranchor2b=0

section1stretchcoloranchors=1

;------------------

;describe section 2

;------------------

;for portrait orientation:

section2yspaceproportion=3

section2numofgraphs=9

section2explanation=Symptoms: lower scores are preferred.

-----------------------------------------------------------------

;Make Symptom bars appear in yellow, blended into red,

;stretched over all currently configured printable bars per graph

-----------------------------------------------------------------

section2numofcoloranchors=2

section2coloranchor1bar=1

section2coloranchor1r=255

section2coloranchor1g=255

section2coloranchor1b=0

section2coloranchor2bar=2

section2coloranchor2r=255

section2coloranchor2g=0

section2coloranchor2b=0

section2stretchcoloranchors=1

The following example provides a printout in landscape format. I keep two sections as before. But this time, I generate two sections of the same height, each section containing 1 row only. Although the first row has only 6 graphs, and the second row 9 graphs, I specify 9 columns for the first row, so that the graphs are printed with the same width in both rows. I also use a different color scheme.

;AnyQuest for Windows optional printer definitions for cumulative printout.

;This file refers to a corresponding *.qdw file in the same directory with the same base filename.

;Comments are identified by preceeding semicolon.

;Sequence of unique lines is unimportant.

;For alternative configurations in one file: first come, first serve.

;Jörg Sigle 2003-07-06

[general]

;It is possible to override the orientation currently chosen in

;AnyQuest's printer setup dialog here. This setting affects only

;the page controlled by this file. 1=portrait, 2=landscape

orientation=2

[sections]

numofsections=2

;------------------

;describe section 1

;------------------

section1allocatecolumns=9

section1numofgraphs=6

section1explanation=Functions: higher scores are preferred.

-------------------------------------------------------------------

;Make Symptom bars appear in green blended from dark to light green

;stretched over all currently configured printable bars per graph

-------------------------------------------------------------------

section1numofcoloranchors=2

section1coloranchor1bar=1

section1coloranchor1r=0

section1coloranchor1g=64

section1coloranchor1b=0

section1coloranchor2bar=2

section1coloranchor2r=0

section1coloranchor2g=255

section1coloranchor2b=0

section1stretchcoloranchors=1

;------------------

;describe section 2

;------------------

section2numofgraphs=9

section2explanation=Symptoms: lower scores are preferred.

-----------------------------------------------------------------

;Make Symptom bars appear in red blended from dark to light red

;stretched over all currently configured printable bars per graph

-----------------------------------------------------------------

section2numofcoloranchors=2

section2coloranchor1bar=1

section2coloranchor1r=64

section2coloranchor1g=0

section2coloranchor1b=0

section2coloranchor2bar=2

section2coloranchor2r=255

section2coloranchor2g=0

section2coloranchor2b=0

section2stretchcoloranchors=1

The following just shows examples of entries for color anchors that can be adopted for your own sections:

-------------------------------------

;Make bars appear in plain bright red

-------------------------------------

section1numofcoloranchors=1

section1coloranchor1bar=1

section1coloranchor1r=255

section1coloranchor1g=0

section1coloranchor1b=0

section1stretchcoloranchors=0

------------------------------------------

;let the first two bars be plainly green,

;then three  bars plainly blue,

;and all others plainly red

;without any color blending

;because adjacent bars have defined colors

------------------------------------------

section1numofcoloranchors=4

section1coloranchor1bar=2

section1coloranchor1r=0

section1coloranchor1g=255

section1coloranchor1b=0

section1coloranchor2bar=3

section1coloranchor2r=0

section1coloranchor2g=0

section1coloranchor2b=255

section1coloranchor3bar=5

section1coloranchor3r=0

section1coloranchor3g=0

section1coloranchor3b=255

section1coloranchor4bar=6

section1coloranchor4r=255

section1coloranchor4g=0

section1coloranchor4b=0

section1stretchcoloranchors=0

Automatically archiving printouts in PostScript or PDF format

Using GhostScript and FreePDF or PDFCreator (all available as freeware), AnyQuest can be configured to redirect printing output to *.PS or *.PDF files. As recent versions of AnyQuest use a unique name for each print jobs, this capability can be used to store all printouts ever generated in an archive directory. If available, you may use your electronic patient management software or practice managment software to record links to these external documents from inside your electronic patient record.

Printjob names

The printjob name supplied by AnyQuest for Windows will typically determine the name of the automatically generated PS, PDF or XPS etc. document.

In order to use the convenient feature introduced with AnyQuest version 3.67, to open previously created *.pdf result printout files from several analysis tools dialogs, printjob names supplied by AnyQuest should be re-used literally, and no other elements (like timestamps, user names, machine names) should be appended upon storage of an automatically created result printout file.

If you use PDFCreator for example, to automatically generate PDF documents with result printouts, you can check the AutoSave option in its configuration dialog and use the simple entry <title> as filename template to achieve this behaviour, and also select a target directory like z:\anyquin\project\printout. PDFCreator will then automatically produce result printout files as PDF document with the printjob name supplied by AnyQuest as filename, plus the extension .PDF.

Prior to AnyQuest for Windows version 3.08, printjob names had the format AQ-YYYYMMDD-HHMMSS-TYP-CONFIGNM.

A custom made version of AnyQuest for Windows 3.08 (dated 29.01.2007) had the CONFIGNM (name of the currently loaded configuration) portion switched off, and replaced by the initials and the group/pid (expanded by leading zeroes to 4 digits, as this is what an xDT/GDT/LDT interface can transport) of the patient which were used for the current questionnaire administration. This resulted in the following printjob name format: AQ-YYYYMMDD-HHMMSS-TYP-VN-NNNN, with VN being the patient initials, and NNNN being filled from the group/PID field and padded with up to 4 leading zeros, or clipped if too long.

Where printouts are automatically converted to files, e.g. PDF documents, and stored in an archive directory, the new format simplified the location of result files from a given patient.

Originally planned only for a single installation, the new algorithm also had better handling of (unexpectedly) empty strings and was left in place for future versions - until a completely configurable solution would be made. The notice "1.0 - PrnJobTitle w/o CFG w PID" in the Properties - Version - File version field of the executable file would denote that this version of the program would used the PID in a portion of the printjob name, rather than the name of the currently active configuration file.

Up to AnyQuest for Windows version 3.63, all printjob names carried a timestamp showing when each printjob was issued.

Since version 3.64, the timestamp for those printjobs that were automatically generated at the end of a questionnaire administration session were changed to use a timestamp showing when the questionnaire administration session started. The same time is recorded in the *.anq result file. This made the timestamps in all three printjob names of automatically created QFI, SNG and CUM printouts (if enabled) identical, deterministic, and completely predictable from the content of the *.anq result file.

The default scheme for printjob names in automatically generated result prinouts has therefore become: AQ-YYYYMMDDhhmmss-TYP-FL-NNNNN, with YYYYMMDD derived from the field date of test and hhmmss from the field start time,   TYP either QFI or SNG or CUM, and FL=initials from the fields first name and last name, and NNNNN=first five digits from the field group/PID.

Since version 3.68, the scheme used to generate printjob names can be configured. For example, you can include time stamps in various resolutions, the type of the printout in shortened or detailed form, and other parameters like the configuration file used, several fields from the patient id, or the name of the associated *.anq result file.

The notice "1.0 - PrnJobTitle w/o CFG w PID" in the Properties - Version - File version field of the executable file, originally introduced after version 3.08 (dated 29.01.2007), was finally reset to a simple "1.0" in version 3.71 (dated 14.12.2011).

The following *.ini configuration file parameters, shown with their default settings are available:

[Printout]

JobName_Header=AQ-

JobName_DoT=True 	(date of test)

JobName_DoTPostDash=True 	(a dash after the date of test)

JobName_StartTime=True

JobName_PrnType=True 	(printout type: QFI, SNG, CUM)

JobName_PrnTypeShort=False 	(switches printout type identifier to Q,S,C)

JobName_ANQfilename=False

JobName_MainINIfilename=False

JobName_Initials=True

JobName_PID=True

JobName_PIDaddZerosUpToNChars=4

JobName_CaseID=False

JobName_CaseIDaddZerosUpToNChars=0

JobName_DoB=False

JobName_City=False

JobName_RemoveAllDashes=False

JobName_UseOriginalTimestampOnRecreate=True 	(Placeholder, not yet implemented.)

The default settings for the new options are chosen to maintain compatibility with previous versions.

Microsoft Windows imposes a 31 character limit onto the length of a printjob name. Characters beyond this limit are simply clipped. So you can only combine several of the available fields, but not all of them with their full length.

The default setting for JobName_PID comes from the German xDT/ADT/BDT/ADT/LDT standard supporting 4 digits for the PID. It will often be too small to reflect all patient numbers in use in typical contemporary patient administration systems.

Please note: It is highly recommended to select the desired printjob name pattern before you use your configuration productively, because later changes will leave the buttons to open previously generated PDF documents unable to find PDF result printout files that were generated before such a change.

Please note: A worthwhile consideration is whether to use simply the printout type, and the *.anq result file name, with or without a preceeding timestamp. This gives a 1:3 bidirectional  deterministic relation between *.anq data files, and *.pdf result printout files. Thereby, the filenames of the *.pdf files can be deducted from the filename (plus maybe content, if the timestamp element is used) of the *.anq file, and - equally importantly - the filename of the originating *.anq file can also be deducted from a given *.pdf file.

As long as the *.anq filename is not used in the printjob name, there is no technically simple and reliable way to go find the corresponding *.anq file given only the result printout files.

Please note that in more recent versions of AnyQuest for Windows, all printing related configuration settings may be located in central configuration file which is typically named z:\anyquin\project\config\common\printout.ini and accessed from other configuration files *.ini through the cascading configuration files mechanism.


Known problems and incompatibilities

If you have observed a problem running AnyQuest for Windows, please look in the document and product history to find out whether this has already been corrected in a more recent version.

The following problems are known and will be addressed in future versions:

"File load"- and "File save"-dialogs use Windows 3.xx functions. They do not support Windows 95 and Windows NT long filenames. (They do however work with similar functions in Wine.)

Adding or deleting questions or questionnaires with open CBFormula definition dialogs may cause inconsistencies under some circumstances. The formula consistency check is not supported for CBFs yet.

Not all messages are translated in international versions yet.

Formula consistency check only works for references within all questionnaires which are loaded into AnyQuest's mind when a respective command is issued. In the future I might even extend it to check all related questionnaire definition files which are available on disk. But this is not a high priority programming task.

Interactions between AnyQuest's main window, the result formula definition dialog and the conditional branch formula definition dialog are not completely smart yet (or even still slightly erroneous...).

AnyQuest only looks for a printer's y-resolution. If you use a printer with different resolutions in x- and y-direction (e.g. a low-res-fax), undesired layout of printouts can result.

In version 2.66, I observed that Specifying a non-existent network printer device together with the HPPCL5MS driver in Windows 2000 in the anyquin.ini file resulted in AnyQuest causing a GPF upon startup. Specifying the same non-existent network printer device with the WINSPOOL driver, or when driver and device where left empty, did not cause a problem. If you observe similar problems, please let me know, so that I may decide to improve AnyQuest's handling of error conditions at this point.

In versions closely before 3.15, Fast-Input-Form mode for delayed processing of paper questionnaires is only available in a German eSIRO version.

In version 3.16, Fast-Input-Form mode has been implemented in a more general version. Still, it supports only basic questionnaires which contain only questions of the discrete-answers/single-check type, and the "can't answer / don't want to answer" strings in the Fast-Input-Form mode as well as button labels etc. are in English and are not included in the *.msg file for translatability yet. Further enhancement of the Fast-Input-Form implementation will be prioritized according to user feedback.

In versions to 3.28, Fast-Input-Form has been opened for questionnaires with a short questionnaire name like kdpzsv, to support a specific in-patient satisfaction with care questionnaire.

In versions to 3.16, the optional patient-ID-sticker-frame on a printout after the first one, may erroneously appear with a filled interior. This will be addressed in one of the next updates.

At least up to version 3.33, possibly changed information from the questionnaire descriptor editing dialog will be saved to memory only, when the "OK" button is pressed, and not when the dialog is closed, or when the current question or questionnaire are being changed. This is behaviour differs from the behaviour of the result formula definition and conditional branching formula definition dialogs can automatically save information in these instances. However, the latter dialogs follow a different concept of operation, they work completely without an "OK" button (low priority issue).

At least up to version 3.33, the result formula definition dialog and the conditional branching formula definition dialog behave differently in so far that, when a questionnaire has no result formula definition, the result formula definition dialog opens up with displayed formula number 0, whereas, when a question has no conditional branching formula definition, the conditional branching formula definition dialog opens up with a displayed (and actually, internally automatically generated afaik) formula 1, which is however, immediately discarded when the dialog has been closed without any changes made (see anyquin.pas 3.33 200905190156).

At least up to version 3.33: Whereas the start up sequence has been optimized so that no questionnaire content nor dialog windows are displayed any more before the navigation dialog appears, they may be briefly visible (if activated) in the program exit sequence (See anyquin.pas 3.33 200905190211).

The following problems arise from limitations of prior Windows versions:

An index based patient recognition option has been implemented and usable at least since AnyQuest Version 2.73. However, it is formally in an alpha development stage, shows a respective notice when used, and currently (through version 3.22) ignores the first result file 00000000.anq when (re-)building its PID index.

Under Windows NT 3.51, hyper-links in the Help file will not appear in green colour automatically (as opposed to Windows 95). However, the pointer will turn into a hand correctly, when positioned over the link. Windows NT 4.xx behaves like Windows 95.

Under some Windows NT 3.51 / Windows 3.1x Help environments, the Smileys contained in this help file might appear as a "J" instead. This makes me very sad...

The driver speaker.drv, a Windows driver available from Microsoft, which allows Wave-files to be played via the usual PC-speaker, only supports 8 Bit files.


Distribution policy and license agreement

Distribution policy and license agreement for this product

 Jörg M. Sigle's Quality-of-Life-Recorder featuring AnyQuest for Windows
© 1989..2008 by Jörg M. Sigle. All rights reserved.

The software package you are looking at was prepared for free evaluation and subsequent continued use after registration.

If it turns out to be feasible, I will keep the following distribution policy:

(1) 	Everybody may distribute an evaluation copy of this software for FREE, provided that it is maintained unchanged and complete including all copyright and license info notes. Nobody may sell it or charge for its distribution beyond the cost which distribution infers to him. Noone may distribute license keys or licenses for this software unless specifically authorized.

(2) 	Everybody may use an evaluation copy of this software for FREE until either the time limited evaluation package expires, or until they decide they want to use the software for production purposes on a regular basis.

(3) 	The time limited evaluation period may be in the range of several months. An unregistered evaluation package may not be used regularly or productively, e.g. in a study or in a project. It is considered unfair to abuse the possibility to download successive evaluation packages for free to sustain productive use of this software without registration.

(4) 	Who wants to continue to use this software after the end of the evaluation period, will be obliged to obtain a software license through registration of this software. This may be available for a registration fee or for free.

(5) 	The registration fee suggested for an individual user is USD 150,- or 150,- EUR per copy + VAT where applicable. It is considered fair to use one registered copy of the software for questionnaire administration on up to two computers at the same time. In addition to that, a registered copy may be used on any number of additional computers for questionnaire definition file development, configuration development, data export or data analysis as desired by the registered user. Usual shipping costs and prices including VAT are listed on the registration form.

(6) 	People or institutions who want to use this software within industry or publicly sponsored projects, will have to pay a registration fee which depends on the benefits they get from the use of this software or on the amount of funding of their project. These benefits shall be estimated and the software shall be registered before the actual data acquisition period of their project begins. Special conditions and service offers can be negotiated.

(7) 	Users who are not able to fund the use of this software according to the above terms may apply for a reduced fee, or even for FREE registration of the software. A free license will be granted upon individual request.

(8) 	I ask every member of the groups defined in (4) through (7) to inform me about the way they want to use this product, independent from the registration fee they wish to pay. Only after registration, will they receive the formal permission to use this product to gain benefits from its use. Users who paid a registration fee will receive a personalized license key. If this is installed, the two shareware notification dialogs displayed after the program start will disappear, and an evaluation version notification in the printout will be replaced by licensed user information or can be disabled, and an evaluation version notification in result files will be replaced by licensed user information. Users who negotiated special conditions may receive technical support regarding study preparation, custom made configurations, or even custom made CDs and documentation adopted to their requirements. Any registered user may participate in two mailing lists focussing on the use of this software.

My policy implies that the costs of measuring quality-of-life inferred by the use of this product can definitely be arranged to fit your budget, even if you need a license for free. However, you are strongly encouraged to register if you're going to use this software for more than evaluation purposes.

(9) 	In addition to the terms set out above, the Quality-of-Life-Recorder software may be available to you under specially designed licenses. These licenses may be supported by third parties and imply that the end user can permanently use the software free of registration fees. As an example, Glaxo Wellcome plc. acquired the right to distribute a substantial number of copies under such a special license in 1999 for the eIBSQOL project, and a number of copies of the eSIRO package is available after special agreement with Prof. Herschbach et al., Munich, as a result of a project supported by the Deutsche Krebshilfe e.V.

Any such special license does not include any additional services or updates or rights. It does not affect other possibilities of acquiring AnyQuest for Windows Software licenses.

If you're interested in sponsoring the continued development and availability of this software - financially, by logistics, or by spreading the word - you're very welcome.

(10) 	I don't charge any fees for the use of any given Quality-of-Life-questionnaire. I don't grant any right to use any given Quality-of-Life-questionnaire, even if a questionnaire definition file with contents similar to such a questionnaire is available. Paper questionnaires may be copyrighted by their respective copyright owners and for some questionnaires you will have to contact the copyright owners to receive a permission to use them. It is your responsibility to make sure that you don't break applicable law. Please consult additional information supplied on the Quality-of-Life-Recorder WWW site, and applicable terms and conditions for the questionnaires you may be interested in. If in doubt, please consult the original authors of the questionnaires you may be interested in.

(11) 	It is mathematically proven, that noone can guarantee the error free function of any piece of software under all circumstances. Because of this, you will find the following sentences in any of your software license agreements, and in mine as well:

(11.1) 	Limited warranty: I warrant, that a copy of this software will perform substantially in accordance with the accompanying user documentation for a period of 90 days from the date of its initial distribution.

(11.2) 	Customer remedies: My entire liability and an end user's exclusive remedy shall be, at my option, either (a) return of the price paid for the optional end user personalisation, or (b) repair or replacement of the product that does not meet my above warranty, if a clear description of the malfunction is provided.

(11.3) 	No other warranties: To the maximum extent permitted by applicable law, I disclaim all other warranties, either express or impied, including but not limited to implied warranties of merchantability and fitness for a particular purpose, with respect to the software, the accompanying documentation, and any possibly accompanying products.

(11.4) 	Use at end user's own risk: Any user uses this software completely at his own discretion and at his own risk.

(11.5) 	No liability for consequential damages: To the maximum extend permitted by applicable law, in no event shall I be liable for any other damages whatsoever (including, without limitation, damage to persons, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use this product, even if I have been advized of the possibility of such damages. In any case, my entire liability under any provision of this agreement shall be limited to the amount actually paid by you for this software.

This agreement is accepted by anyone who uses this software, even if only for the purpose of its evaluation or review.

(end of document)


UPN

German for "Umgekehrte Polnische Notation" which probably translates to "Reverse Polish Notation". It is a style of noting down mathematical formulas that was common with older computers. Its advantage is that it doesn' t need brackets ( the symbols "(" and ")" ), the disadvantage is that it may look confusing (because somehow the wrong way round...) at first sight.

UPN basics

UPN machines use a stack to calculate. A stack of numbers works just like a stack of plates: at any given time, there is only one plate at the top of the stack. If you add one, it becomes the top plate, and if you want to take one away, you can only take the top one. You' ll never fuss with anything that is at the bottom.

Likewise, a UPN machine keeps a stack of numbers. If you give a number to the UPN machine, it puts this number on top of its stack. If you give the next number to it, it puts this number on top of the preceeding one.

If you ask the UPN machine to give a number back to you, it takes it from its stack - the top one.

If you ask it to add, it takes two numbers from the stack (one after the other), adds them, and puts the result to the stack. It's THAT simple, and it never has to fuss with anything that is at the bottom · .

If you are used to UPN already, you may go directly to AnyQuest's UPN implementation. If you are not, here is a detailed example:

Let's consider what the UPN machine makes out of:        10 20 + display!

it puts 10 ontop of the stack

it puts 20 ontop of the stack

it takes two elements from the stack, adds them, and puts the result back to the stack

it takes the top element off the stack and displays it. It is 30, by the way.

Let's consider what the UPN machine makes out of:         10 20 + 5 * display!

it puts 10 ontop of the stack

it puts 20 ontop of the stack

it takes two elements from the stack, adds them, and puts the result back to the stack

it puts 5 ontop of the stack

it takes two elements from the stack, multiplies them, and puts the result back to the stack

it takes the top element off the stack and displays it. It is 150 (and definitely not 250).

So we don't need to write (10+20) * 5, because the UPN machine never has to fuss with...

You can also use the UPN machine to check whether a condition is true or false. This is used in AnyQuest's CBFs, and it might as well be used to compute some questionnaire results which e.g. include comparison against a cutoff value:

Let's consider what the UPN machine makes out of:         83 10 > display!

it puts 83 ontop of the stack

it puts 10 ontop of the stack

it checks whether the top-1 element is > than the top element,

   removes both elements, and because 83 is > 10, it puts 1 ontop of the stack

it takes the top element off the stack and displays it. It is 1.

Let's consider what the UPN machine makes out of:         4 1 = display!

it puts 4 ontop of the stack

it puts 1 ontop of the stack

it checks whether the top-1 element is = the top element,

   removes both elements, and because 4 is not = 1, it puts 0 ontop of the stack

it takes the top element off the stack and displays it. It is 0.

AnyQuest for Windows supports many mathematical and logical functions through the UPN and it has a debug mode that allows you to watch its UPN machine processing formulas step-by-step.

AnyQuest's stack for mathematical operations holds extended precision floating-point numbers. Cave: Please remember common pitfalls when using floating-point arithmetics, especially with exact comparisons: As floating-point numbers stored in the computer are often merely computerized approximations of real world numbers, a few computations in a row might not return the exactly expected number, but a value slighly above or below, so an exact comparison with a given value might not work out as expected. Please look for a document like "what everyone should know about floating-point arithmetics" on the WWW to learn more (and avoid at least untested exact comparisons with results of computations)!

Since version 2.57, UPN formulas may be included in any displayed text element of the questionnaire.

Whereas some pickyness of mathematical functions was removed in version 2.57, since version 3.19, AnyQuest's mathematical UPN functions are much more picky again when they find too few arguments on the stack. Before 3.19, calling a function


UPN implementation in AnyQuest for Windows

UPN functions of AnyQuest for Windows

To make up a UPN formula for AnyQuest, you just add numbers and some of the following keywords together, every two seperated by one blank. You don't need to use a command like "display!": when it has processed the whole formula, AnyQuest's UPN processor automatically takes the result from the stack and returns it to AnyQuest for further use.

You can put the UPN machine into a debug mode from the Edit-Menu, and then watch it processing your formulas step-by-step. This helps you understand how each formula is actually executed and makes it easier for you to find out why a given formula might not work as expected. : Cave: Do not forget to remove this flag once you don't need the debug mode any more. If a UPN debugging window waits for your input behind AnyQuest's main window, you may think the program has stuck - but instead, you might just want to use Alt-Tab to get the debugging window into the foreground, and then press any key in it to make it go on with UPN formula evaluation.

AnyQuest's stack for mathematical operations holds extended precision floating-point numbers. Cave: Please remember common pitfalls when using floating-point arithmetics, especially with exact comparisons: As floating-point numbers stored in the computer are often merely computerized approximations of real world numbers, a few computations in a row might not return the exactly expected number, but a value slighly above or below, so an exact comparison with a given value might not work out as expected. Please look for a document like "what everyone should know about floating-point arithmetics" on the WWW to learn more (and avoid at least untested exact comparisons with results of computations)!

Since version 2.57, UPN formulas may be included in any displayed text element of the questionnaire, to produce dynamically adjusted questionnaire text: the escape text #UPN starts the formula, and another #UPN ends it again. Spaces before and after the escape sequence are not automatically printed - so you can seamlessly join plain text and UPN formula output. You may however use something like X#032 inside the UPN code if you actually want to have a space displayed.

Whereas some pickyness of mathematical functions was removed in version 2.57, since version 3.19, AnyQuest's mathematical UPN functions are much more picky again when they find too few arguments on the stack. Before 3.19, calling a simple mathematical function that needed one argument on a completely empty stack might be gracefully ignored - From 3.19 and onwards, this will return a stack underflow error message displayed in a window and in the UPN formula result. Before 3.19, calling a simple mathematical function that needed two arguments on an empty stack, would cause the program to abort ungracefully (with a Run Time Error 201 at 17:2A45 for versions 3.17 and 3.18). From 3.19 and onwards, this will also return a stack underflow error message in a dialog window and in the UPN formula result, but otherwise let the program continue.

The following keywords instruct AnyQuest's UPN processor to take either one or more numbers from the stack, process them according to what you' d expect from their name and put the result back to the stack:

about ± [3.4e-4932 .. 1.1e4932[ ; 0	AnyQuest's UPN processor operates on extended floating point numbers. So it handles numbers within a considerable range at 19..20 digits precision. Just use a decimal point as decimal separator.

undefined	puts the numeric value which is especially reserved to represent an "undefined" value on top of the stack. In AnyQuest for DOS and early versions of AnyQuest for Windows, this was 3.399999e38 = maxsingle; in version 2.32 it was changed to 1.1e4932 = maxextended. Although the absolute numbers are given here, you should not place one of these onto the stack to get an undefined top element, because the number used might change in the future. Also, you cannot test using "=" for an undefined value, because most functions of the UPN processor will always give an undefined result whenever at least one of their arguments is undefined. Please note that when the UPN processor begins to run, its numerical result starts as "undefined".

testundefined	takes the top element from the stack and looks at it: If it equals the numeric value representing an "undefined" value, puts 1 on top of the stack, otherwise, puts 0 on top of the stack.

Pi    	Another number you can put onto the stack. Before version 3.19, the topmost value on the stack was erroneously converted into Pi (obviously, nobody ever tried to use that because noone ever complained...), but in 3.19 this was corrected so that Pi is now actually put additionally on top of the stack.

+ - * /	These take the two topmost elements from the stack, process them as specified, and put the result back onto the stack. "/" divides the one below by the top element. Example: "12 3 /" returns "4". If at least one of the supplied arguments was undefined, the result will be undefined.

^	raises the one below to the power of the top element. Example: "2 5 ^" returns "32". Since version 2.67, this function can compute the power of a negative base as long as the exponent is an integer with an absolute value up to 2^31. If the base is negative and the exponent is not an integer value in the specified range, it will deliver "undefined" as its result. Before version 2.67, using a negative base with an exponent other than 0 would cause a run time error 207 (invalid floaing point operation). If at least one of the supplied arguments was undefined, the result will be undefined. Please note that you can use x 0.5 ^ to draw a square root of x, or x 1 3 / ^ to draw a third root etc., and x dup * to replace x 2 ^ with a simpler term.

sin cos tan exp log	These take one element from the stack, process it as specified, and put the result back onto the stack. If the supplied argument was undefined, or the requested action somewhat strange (like: "0 log"), undefined would be placed back onto the stack. (If you need anything like ArcTan, ArcSin, ArcCos etc. please send me a note.)

sgn	takes one argument from the stack and returns: undefined, if the argument was undefined; or 1, if the argument was > 0 (positive); or -1, if the argument was <0 (negative); or 0 if the argument was exactly 0. Available since version 3.19. Cave: Please remember common pitfalls when using floating-point arithmetics and exact comparisons: As floating-point numbers stored in the computer are often merely computerized approximations of real world numbers, a few computations in a row might not return the expected zero, but a value slighly above or below, so an exact comparison with zero might not work out as expected. Please look for a document like "what everyone should know about floating-point arithmetics" on the WWW to learn more (and avoid at least untested exact comparisons with results of computations)!

abs	takes one argument from the stack and returns undefined, if the argument was undefined; or the absolute value of the argument (i.e. sign removed). Available since version 3.19.

> >= = <= < <>	Comparison functions. The element below the top is compared against the top element. Both elements are removed, and the result of the comparison (0 or 1) is put onto the stack. Example: "5 1 >" returns "1" (=True). Cave: Please remember common pitfalls when using floating-point arithmetics and exact comparisons: As floating-point numbers stored in the computer are often merely computerized approximations of real world numbers, a few computations in a row might not return the exactly expected number, but a value slighly above or below, so an exact comparison with a given value might not work out as expected. Please look for a document like "what everyone should know about floating-point arithmetics" on the WWW to learn more (and avoid at least untested exact comparisons with results of computations)!

and or xor	Logical functions with two operators.

not    	Bitwise inversion (1's complement) of the top element. If this does not give the desired result (because you simply want to invert one overall logical 1 [which is anything but not 0] to one overall 0), try "0 =" instead. Examples are given in the questionnaire definition file eqneq.qdw, available in a preset demo configuration within anypak.exe from version 2.67 on.

dup    	takes a number from the stack and puts two copies of this number to the stack effectively duplicating the top element.

pop    	takes a number from the stack and puts it into the garbage bin.

exchg	exchanges the two top elements of the stack.

Sn    	copies the element [top-n] onto the top of the stack. "S0" has the same effect as "dup".

Vn Cn	both Vn and Cn do the same in AnyQuest for Windows: They ask the UPN processor to put the numeric result of question nr. n onto the stack. Please note the formula consistency check. Since Version 3.14, before the Vn or Cn is evaluated, if question n is flagged as displayed during the current questionnaire administration session, its numeric- and string-results are (re-)computed. This causes some overly redundant question result computation, but it ensures that the question result is up to date.

Before Version 3.14, questions that received checked answers merely from UPN formulas (CBF or text inline), could remain with a question result of "undefined" even though they had some answers checked, and that would cause undesired results in succeeding "CBF - skip" instructions. This happened e.g. in the SAQLI??.QDW when exactly 5 answers were selected in question 39, and absolutely no changes were made in question 41 afterwards, leaving its numeric result undefined although checked answers had been displayed, and consequently, the CBFs that should skip some of the following questions would not work as intended.

CCAn	"CountCheckedAnswerfields" - Asks the UPN processor to count the number of checked answer fields of question nr. n and to put the result onto the stack. Please note the formula consistency check.

An    	Asks the UPN processor to append the string result of question nr. n to the string result of the formula. First available again in AnyQuest for Windows Version 2.25. Please note the formula consistency check.  Since Version 3.14, before the Vn or Cn is evaluated, if question n is flagged as displayed during the current questionnaire administration session, its numeric- and string-results are (re-)computed. This causes some overly redundant question result computation, but it ensures that the question result is up to date.

Bn:m	Asks the UPN processor to append additional text info or direct text info from question nr. n, answer field nr. m, to the string result of the formula. First available in AnyQuest for Windows Version 2.26. Please note the formula consistency check.

En:m	Asks the UPN processor to interpret additional text info or direct text info from question nr. n, answer field nr. m, as a time given in the format HH:MM or HH:MM:SS, and to compute the matching number of seconds, and to place this number upon the stack. First available in AnyQuest for Windows Version 2.43. Please note the formula consistency check.

Yn    	Adds a string to the string result of the formula, which is built from the answer field labels of all checked answer fields of question nr. n. The string result can grow up to 255 characters. Please note the formula consistency check.

Xabc	Adds the string abc to the string result of the formula. The string result can grow up to 255 characters. First available in AnyQuest for Windows version 2.32. Since version 2.49, characters are not converted to uppercase any more and the string can contain the escape sequence #nnn to specify special characters by their character code. For example, a space can be entered by #032, the # itself by #035 and a line break by #013.

Tabc	Asks the UPN processor to add the string abc to the string result of the formula, if the top element of the stack is true. The string result can grow up to 255 characters. First available in AnyQuest for Windows Version 2.32. Before Version 2.39, the top element was removed from the stack by this command, only when it was true; since Version 2.39 it is not removed by this command. Since version 2.49, characters are not converted to uppercase any more and the string can contain the escape sequence #nnn to specify special characters by their character code. For example, a space can be entered by #032, the # itself by #035 and a line break by #013. Since version 3.19, Tabc does not add abc to the string result anymore if the top element is undefined - what it did before 3.19, but what is typically unwanted. Please use the newly added Uabc (see below) after Tabc if you still need this effect.

Fabc	Asks the UPN processor to add the string abc to the string result of the formula, if the top element of the stack is false. The string result can grow up to 255 characters. First available in AnyQuest for Windows Version 2.32. Before Version 2.39, the top element was removed from the stack by this command, only when it was false; since Version 2.39 it is not removed by this command. Since version 2.49, characters are not converted to uppercase any more and the string can contain the escape sequence #nnn to specify special characters by their character code. For example, a space can be entered by #032, the # itself by #035 and a line break by #013. If you want to put a single "n" onto the stack, the necessary command "Fn" could not be distinguished from the command described further below to reference a result of an earlier formula. So in this case, please use "F#078" (upper case N) or "F#110" (lower case n) instead.

Uabc	Asks the UPN processor to add the string abc to the string result of the formula, if the top element of the stack is undefined. Newly available since version 3.19. Please use the newly added Uabc directly after Tabc if you need the (rather unspecific) behaviour of Tabc from versions before 3.19.

n FN	Asks the UPN processor take the numerical result from result formula n of the local questionnaire, and to put this onto the stack. There is no formula consistency check for this command so far. So be careful, when you delete formulas after using it.

CLRS	Asks the UPN processor to clear the current string result.

LENS	Asks the UPN processor to put the length (in characters) of the current string result onto the stack.

VALS	Asks the UPN processor to try to convert the current string result into a number. If the conversion is successful, the number is put onto the stack, followed by a zero indicating the successful conversion. If the conversion fails, undefined is put onto the stack followed by the number of the character in the text string which caused the conversion to fail. After the command has been executed, neither n nor m do remain on the stack. Introduced in Version 2.57, this function can only recognize a dot (full stop, point), not a comma as decimal separator.

w p STRS	Asks the UPN processor to take a number p for precision from the stack, take another number w for width from the stack, then take a number x from the stack, convert it into a text string using the specified width and precision, and add this text string to the string result of the formula. The string result must, however, stay below 255 characters, otherwise, it is not extended. p and w are rounded before processing, and at the moment, maximum values are p=20 and w=22. If x is undefined, nothing is added to the string result. Introduced in Version 2.57, this function can only place a dot (full stop, point), not a comma as decimal separator.

n GETQS	Asks the UPN processor to retrieve the text of question number n of the current questionnaire and add it to the string result. This function works, if the resulting length of the string result remains below 255 characters. After the command has been executed, n does not remain on the stack.

n SETQS	Asks the UPN processor to copy the current string result to the text of question number n of the current questionnaire. After the command has been executed, n does not remain on the stack.

n m GETLS	Asks the UPN processor to retrieve the text of the label of answer field m from question number n of the current questionnaire and add it to the string result. This function works, if the resulting length of the string result remains below 255 characters. After the command has been executed, neither n nor m do remain on the stack.

n m GETLSC	Asks the UPN processor to check whether answer field m from question number n of the current questionnaire is checked, and if this is the case, to retrieve the text of the label of this answer field and add it to the string result. This function works, if the resulting length of the string result remains below 255 characters. After the command has been executed, neither n nor m do remain on the stack.

n m GETLSNC	Asks the UPN processor to check whether answer field m from question number n of the current questionnaire is NOT checked, and if this is the case, to retrieve the text of the label of this answer field and add it to the string result. This function works, if the resulting length of the string result remains below 255 characters. After the command has been executed, neither n nor m do remain on the stack.

n mstart mend GETMCSSLSC	Asks the UPN processor to check whether answer fields mstart to mend from question number n of the current questionnaire are checked, and to retrieve the text of the label of each answer field that is checked and add it to the string result. If the string result was not empty before, a comma and a space are added before the answer field label. This function works, if the resulting length of the string result remains below 255 characters. After the command has been executed, neither n nor m do remain on the stack. By specifying mstart and mend accordingly, you can process answer fields counting up or down.

n mstart mend GETMCSSLSNC	Asks the UPN processor to check whether answer fields mstart to mend from question number n of the current questionnaire are NOT checked, and to retrieve the text of the label of each answer field that is NOT checked and add it to the string result. If the string result was not empty before, a comma and a space are added before the answer field label. This function works, if the resulting length of the string result remains below 255 characters. After the command has been executed, neither n nor m do remain on the stack. By specifying mstart and mend accordingly, you can process answer fields counting up or down.

n m SETLS	Asks the UPN processor to copy the current string result to the text the label of answer field m from question number n of the current questionnaire. After the command has been executed, neither n nor m do remain on the stack.

n m GETNS	Asks the UPN processor to retrieve the text of the notes (or the direct text) of answer field m from question number n of the current questionnaire and add it to the string result. This function works, if the resulting length of the string result remains below 255 characters. After the command has been executed, neither n nor m do remain on the stack.

n m SETNS	Asks the UPN processor to copy the current string result to the text the notes (or the direct text) of answer field m from question number n of the current questionnaire. After the command has been executed, neither n nor m do remain on the stack.

n m GETC	Asks the UPN processor to retrieve the checked state of answer field m from question number n and put it onto the stack. After the command has been executed, neither n nor m do remain on the stack, but until version 2.56, instead of n, this function left an undefined value on the stack before its result; this has been corrected in 2.57.

n m SETC	Asks the UPN processor to take a number from the stack and to set the checked state of answer field m from question number n of the current questionnaire according to the value of this number. Until version 2.56: If it is undefined or false (zero), the target field will remain unchecked. Otherwise, it will be checked. Since version 2.57: If it is undefined, nothing will be done. Otherwise, If it is false (zero), the target field will be unchecked. If it is true, it will be checked. After the command has been executed, neither n nor m do remain on the stack.

n m COPYC	Asks the UPN processor to copy the checked states from all answer fields of question n of the current questionnaire to respective answer fields of question m of the current questionnaire. If a source answer field has notes which are not empty, the respective target answer field will become checked. After the command has been executed, neither n nor m do remain on the stack.

Very important notice: It may be helpful to use the command sequence "FRSOUAQMODE CSTOP" before COPYC. Please see the explanation of that command for further information. (That explanation may appear complicated, but if you use COPYC, please take your time to comprehend it...)

FRSOUAQMODE	Asks the UPN processor to put a flag (with a value of either 0 = False or 1 = True) on the stack, which indicates whether AnyQuest is in the "Show only unanswered questions" mode. When AnyQuest checks whether a questionnaire was completely filled in at the end of a session, and encounters any questions that were displayed but not answered, it goes into this mode, and then starts at the first question and goes forward through all questions till it reaches the next one which was displayed but not answered. Not before then does it stop going forward, and repaint its display.

In this process, it also evaluates all eligible CBFs of questions on the way. If any of these should contain a COPYC used to initialize a question with a set of answers the patient gave at a preceeding question, that question will be initialized again, even though you would probably not want that to happen at this moment. This may unwantedly change the set of answers from what the patient chose before in this particular question, to what was copied from somewhere else for the initialization. Even worse: If after the initialization, the patient was meant to select some of the answers from those preset during this initialization, or select additional ones, and the succeeding questions will check that exactly the right number of answers were checked and otherwise jump back to that question, and if the number of answers automatically set during initialization would deviate from the required number of answers, that alltogether would result in AnyQuest cycling through this group of questions endlessly.

Actually, this is exactly what happened in the SAQLI example, when any one  question was intentionally skipped (using the transport bar or the page down key for testing or during demonstration), in questions 39 and 41..43, and in questions 69 and 71..73, before AnyQuest version 3.09 received the FRSOUAQMODE command and the before mentioned sequence was added to the CBFs of questions 39 and 69.

If you still should experience the effect of programming such a surprising and unwanted endless loop (which you may suspect if AnyQuest apparently does not move on and seems not to react anymore), you can enforce a display repaint by first minimizing, and then maximizing again AnyQuest's main window. Even when AnyQuest is in such an endless loop, it may accept question answering input, so that you may be able to display the question truly causing the problem and changing the checked answer fields as needed to get out again.

Of course, you can not only use the FRSOUAQMODE command to abort individual UPN formulas in "Show only unanswered questions" mode, but you can also use it to control "Jump to ..." commands, in order to completely skip parts of your questionnaire while AnyQuest does its questionnaire completeness check, or to alter the sequence which AnyQuest uses to go through the questionnaire during that check.

TOSOUAQMODE	Asks the UPN processor to take a value from the stack, and write it to AnyQuest's internal flag that controls whether it is in the "Show only unanswered questions" mode. This should be useful whenever you think that missing answers to displayed questions should put the user completely back into the normal questionnaire administration mode. Using it the other way round, is similar to, but still slightly different from the CBF command: "Stop asking questions and compute results." A value of 0 will result in False, a value of undefined will result in no change, and any other value will result in True.

n m GETVAL	Asks the UPN processor to read the direct text or notes of answer field m of question n and try to convert it into a number. If the conversion is successful, the number is put onto the stack, followed by a zero indicating the successful conversion. If the conversion fails, undefined is put onto the stack followed by the number of the character in the text string which caused the conversion to fail. After the command has been executed, neither n nor m do remain on the stack. Introduced in Version 2.57, this function can only recognize a dot (full stop, point), not a comma as decimal separator.

GETCURQN	Asks the UPN processor to put the number of the currently displayed question onto the stack. The first question of the currently displayed questionnaire is question number 1.

GETCURQNR	Asks the UPN processor to put the number of the currently displayed questionnaire onto the stack.

GETLDQN	Asks the UPN processor to put the number of all currently loaded questions onto the stack. The first question of the currently displayed questionnaire is question number 1.

GETLDQNR	Asks the UPN processor to put the number of all currently loaded questionnaires onto the stack.

RECALCNUMRES	Asks the UPN processor to ask AnyQuest to recalculate the numeric value of the currently displayed question immediately. This maybe useful for UPN formulas which are integrated in displayed text elements.

CSTOP	Asks the UPN processor to take a number from the stack and if this is neither undefined nor false, to abort the further processing of the current formula. Before version 3.19, applying this command to an empty stack would gracefully ignore the command. From 3.19 and onward, this will instead produce a stack underflow error message both in a screen dialog and in the result of the affected UPN formula.

TOPIDfirstname, TOPIDlastname, TOPIDgrouppid (this only for compatibility to pre 2.57 versions, please use the next one instead), TOPIDpid, TOPIDdob, TOPIDcompany, TOPIDposition, TOPIDname, TOPIDinitials, TOPIDaddress, TOPIDzip, TOPIDcity, TOPIDphone, TOPIDfax, TOPIDinsurancename, TOPIDinsurancenumber, TOPIDinsurednumber, TOPIDphysiciannumber, TOPIDvknr, TOPIDinsuredstatus, TOPIDstatusextension, TOPIDcardvalid, TOPIDinsurancetype, TOPIDsex, TOPIDethnicity, TOPIDgroup, TOPIDsubgroup, TOPIDcycle, TOPIDsubcycle, TOPIDrater, TOPIDinfosource, TOPIDassessment - These commands ask the UPN processor to copy the current contents of the string result of the formula to the respective internal variable, which will would usually be collected through the initial uneditable screens which are controlled via "Navigation" - "Patient identification options". These commands allow you to design individual screens to collect patient data. To be used with care! First available in AnyQuest for Windows Version 2.26. - AnyQuest for Windows 3.20 added these commands and the respective patient ID data fields: TOPIDplaceofbirth, TOPIDphonework, TOPIDphonemobile, TOPIDphonerelative, TOPIDemail, TOPIDnationality.

FRPIDfirstname, FRPIDlastname, FRPIDgrouppid (this only for compatibility to pre 2.57 versions, please use the next one instead), FRPIDpid, FRPIDdob, FRPIDcompany, FRPIDposition, FRPIDname, FRPIDinitials, FRPIDaddress, FRPIDzip, FRPIDcity, FRPIDphone, FRPIDfax, FRPIDinsurancename, FRPIDinsurancenumber, FRPIDinsurednumber, FRPIDphysiciannumber, FRPIDvknr, FRPIDinsuredstatus, FRPIDstatusextension, FRPIDcardvalid, FRPIDinsurancetype, FRPIDsex, FRPIDethnicity, FRPIDgroup, FRPIDsubgroup, FRPIDcycle, FRPIDsubcycle, FRPIDrater, FRPIDinfosource, FRPIDassessment - These commands ask the UPN processor to append the current contents of the respective internal variable to the of the string result. This enables you for example to show some parameters of the PID on every page of a QDW serving as a form using one of the explanation fields. Available since Version 2.57. - AnyQuest for Windows 3.20 added these commands and the respective patient ID data fields: FRPIDplaceofbirth, FRPIDphonework, FRPIDphonemobile, FRPIDphonerelative, FRPIDemail, FRPIDnationality.

GETAGE	Asks the UPN processor to put the current age of the patient in years (one year being equal to 365.25 days) on top of the stack. If you want to display the computed result within a questionnaire text element for debugging purposes, you may for example use the sequence: #UPN GETAGE 0 3 STRS within this text element. Available since Version 2.59.

n Threshold	Asks the UPN processor to set the threshold level in % for missing (or undefined) values to the value n. (integer, 0..100). This treshold level temporarily overrides the one specified in the formula definition dialog. (Originally supported as "Treshold", due to a typo. Support for "Threshold", with an additional "h", was added in version 3.37. For compatibility with older questionnaire definition files, both spellings are allowed.)

n Sum	Asks the UPN processor to take n elements from the stack and to compute their sum. It puts the sum on the stack if at least [treshold level in %] of the processed values are not missing or undefined. Else, it puts "undefined" on the stack.

n Avg	Asks the UPN processor to take n elements from the stack and to compute their average. It puts the avg on the stack if at least [treshold level in %] of the processed values are not missing or undefined. Else, it puts "undefined" on the stack.

n Min	Asks the UPN processor to take n elements from the stack and to find their minimum. It puts the minimum on the stack if at least treshold level in % values are not missing or undefined. Else, it puts "undefined" on the stack. First available in AnyQuest for Windows Version 2.36.

n Max	Asks the UPN processor to take n elements from the stack and to find their maximum. It puts the maximum on the stack if at least treshold level in % values are not missing or undefined. Else, it puts "undefined" on the stack. First available in AnyQuest for Windows Version 2.36.

?n:m	supported for compatibility with AnyQuest for MS-DOS and special purposes. Can be omitted. Takes top element from the stack and moves it to the numeric result and adds it to string result of the formula. If n, n:m or :m are specified, formatting overrides the values specified in the formula dialog box, with n specifiing total digits and m number of decimals. In contrast to AnyQuest for MS-DOS and pre 2.25 releases of AnyQuest for Windows, does NO MORE END processing of the UPN formula.

extassign	reserves a name for an external communication file and assigns the name to a file-handle. The external communication file is a plain text file.

extrewrite	prepares the external communication file for writing to it, starting at the beginning of the file.

extappend	prepares the external communication file for appending to it, starting at the end of the file.

n extwriteln	Asks the UPN processor to write n elements from the stack into the communication file one by one.

extclose	closes an external communication file, usually, before an external program is called to process its contents.

extcall=c:\anyquin\extscore\mycalc.exe	calls an external program c:\anyquin\extscore\mycalc.exe with the name of the external communication file supplied as a parameter.

extreset	resets an external communication file, usually after the external program has changed its contents, setting the reading pointer to the beginning of the file.

n extreadln	Asks the UPN processor to read n numeric elements from the external communication file and to put them onto the UPN stack one by one. Most of the time, you will only read one value from outside at a time and use it as result for one result formula, because the UPN stack is not preserved when the computation of a single formula ends. You would read the next value from the external communication file for the next result formula by a new command included in that formula.

n extreadlnstring	Asks the UPN processor to read n string elements from the external communication file and append them to the string result of the current formula.

extclosedel	closes and deletes an external communication file, thereby freeing the reserved filename.

When using external communication files, please review my additional notes regarding communication with external software.

Vn and Cn are important keywods, because they give you access to your numeric questionnaire data.

An, Bn:m, Yn give you access to text questionnaire data.

FN gives you access to results of formulas of the same questionnaire, Please note that its notation is different from Vn, Cn, An, Bn:m, Yn.

Please note, that numeric data go to the stack first and may go from there to the numeric result of the formula, then further to the string result of the formula. The transition from the numeric result to the string result will occur automatically if the UPN formula ends and there is no string result so far. Text data, however, will go to the string result of the formula directly. The string result is ultimately stored in printouts and in the output file.

When defining a UPN formula for a given questionnaire, using the V, C, A, B, Y commands, you have to take into account every single question in that questionnaire, even if it is declared to be an "Infoscreen". You can directly display the correct question number by activating the corresponding option in the "Display" menu.

When adding or deleting questions, the formula consistency check is a useful feature.

Currently, the UPN machine's working stack can hold 6552 numeric values of extended precision at a time (255 before version 2.26).

Currently, the UPN machine can process UPN formulas of up to 32384 characters length (255 before version 2.26).

Result formulas with that length can be stored from version 2.27 on, while prior versions can only handle result formulas of up to 255 characters.

Conditional branch formulas and branch destinations cannot be longer than 255 characters, yet.

String results of formulas can only be up to 255 characters long, the UPN machine cannot generate string results longer than 255 characters either.

Additional text input or direct text input to individual answer fields can be up to 32384 characters long.

Please note that the stack currently cannot hold string elements. (If anyone needs more string manipulation functionality, this may be changed.)

At the beginning of the computation of each formula, the stack is empty and the numeric result of the computation starts as "undefined value".

Since version 2.57, the stack counter may be decreased to 0 (=empty stack) in the course of the computation. In earlier versions, a stack underflow error would have occured after many commands that removed the last value from the stack instead. Moreover, stack[0] is now set to undefined before each formula is processed, it had been set to 0 before version 2.56.

Since version 2.57, UPN formulas may be included in any displayed text element of the questionnaire. Within the text, the start and end of parts which shall be processed as UPN formulas rather than displayed, are marked by the four character sequence #UPN. They are processed just before the text element is displayed, and the string result of each processed UPN formula replaces its original #UPN....#UPN section in the text. If #UPN occurs only once within a text string, all remaining characters are interpreted as UPN formula. You may use leading and trailing spaces between the UPN formula and its enclosing #UPN....#UPN tags, but they are completely optional. If you want to display the numeric results of a UPN formula in the text, you must use the ? or STRS command at the end of a formula. If your formula ends with an empty stack and/or an undefined numeric result, and you do not want the word "undefined" to appear in the text, you can either put a final 0 (or another valid number) onto the stack as the last command of your formula which will produce a valid numeric result, or use X#032 to put a space into the string result.


Conditional branching: general information

General information about conditionally asked questions or modules

Sometimes you may want to ask a question or a number of questions only to selected patients.

A common example may be the question "Did you enjoy sex?", which should only be asked, if the patient had sex at all. So you would like to ask "Did you have sex?" first, and ask "Did you enjoy sex?" only, if the patient answered the first question with "Yes".

A more complex example might be a list of modules from which a patient (or researcher) would select the modules to be actually asked.

AnyQuest for Windows can complete these tasks, as it allows you to add Conditional Branch Formulas to any question.

Some examples are given in the supplied questionnaire definition files "modules.qdw" and "extmod.qdw".


Conditional Branch Formulas

Conditional Branch Formulas (CBF) are definitions which modify AnyQuest for Windows's way through a loaded set of questionnaires. Please click here to find out about examples where this is useful.

All CBFs are ignored in the edit layout mode.

Each CBF includes three elements:

•	UPN condition for execution of command

•	Conditional Branch Command

•	Destination or offset for Jump or Call Command

You can add more than one CBF to any question, allowing e.g. for sequential check of any answer field and conditional execution of different modules linked with each answer field.

Before each question is displayed (except for the first question of the first loaded questionnaire), all CBFs added to this question are searched. If among those whose UPN Condition Formula yields "true", there is one with a "Skip" command, the question is skipped.

After a question has been answered, all CBFs added to this question are searched again. If there are any whose UPN Condition Formula yield "true", their associated branching commands are executed one after another. Should there be "Call" commands among them, the specified destination would be called, and after having returned, checking of the remaining commands would be resumed. After a "Jump", "Return" or "Stop asking" command has been executed, remaining CBFs of a question are ignored.

You can also use Conditional Branch Formulas to implement dynamically morphing questionnaires.

When adding or deleting questions, after formulas have been defined, the formula consistency check is a useful feature.


Definition of CBFs

Definition of Conditional Branch Formulas

If you select "Edit conditional branch formulas" from the "Edit" menu, a new window appears. It coexists with AnyQuest's main window and if you switch to another question in the main window, this question's last CBF will automatically diffuse into the CBF definition dialog window.

To change any of the parts of the CBF, just enter new values in the corresponding places or select the command you like. To add another CBF to a question, just use your mouse to increase the number of the CBF displayed by one. To delete a formula, simply press the "Delete" button in the dialog window.

The numbers of displayed formulas start with 1 for each question.

When adding or deleting questions, the formula consistency check is a useful feature.


CBF: UPN condition for execution of command

The UPN condition formula, which is part of a CBF definition, is used to define when the command shall be executed:

If the formula returns "0" or "undefined" (what computer nerds call "false"), the command will not be executed.

If the formula returns a value<>0, e.g. "1" or "-1" (what computer nerds call "true") , the command will be executed.

Read here about UPN basics,, and here about the UPN commands supported by AnyQuest for Windows.


CBF: Conditional Branch Commands

The command, which is part of a CBF definition, is used to define what AnyQuest for Windows shall do, if the UPN condition returned "true". Remember, that all commands are ignored in the edit layout mode.

The following command is of interest before a question is displayed:

•	Skip this question

AnyQuest for Windows checks all CBFs of a question for a "Skip"-command before the question is displayed, and if it finds one to have a "true" UPN condition, the question is skipped.

Of course, any other CBFs of this question are ignored. AnyQuest for Windows will proceed with the question directly following the omitted one.

The following commands are of interest after a question has been answered or the "Continue"-button has been pressed:

•	Jump and don't return

This will cause AnyQuest for Windows to proceed with the questionnaire and question given in the field "Destination or offset for Jump or Call Command".

Any succeeding CBFs of the question will be ignored.

•	Call and return from called module's end

This will cause AnyQuest for Windows to proceed with the questionnaire and question given in the field "Destination or offset for Jump or Call Command".

The current questionnaire, question and CBF are noted down, however, and as soon as the end of the questionnaire definition to which the destination belongs will be reached, AnyQuest will return to the current position.

The execution of any succeeding CBFs of the question will be resumed then.

This command is useful if you want to execute modules or sub-forms which are stored as whole questionnaire definition files, or if you want to include complete questionnaires as modules.

•	Call and return on 'Return'-command

This will cause AnyQuest for Windows to proceed with the questionnaire and question given in the field "Destination or offset for Jump or Call Command".

The current questionnaire, question and CBF are noted down, however, and as soon as a CBF of any succeeding question whose UPN condition returns "true" will contain a "Return"-command, AnyQuest will return to the current position.

The execution of any succeeding CBFs of the question will be resumed then.

This command is useful if you want to execute modules or sub-forms of which more than one are stored in one questionnaire definition file.

•	Return

This command will cause AnyQuest for Windows to return to the point from where the last "Call and return on 'Return'"-command was issued.

The execution of any succeeding CBFs of that question will be resumed then. The execution of any succeeding CBFs of the question containing the "Return"-command, however, will be ignored.

•	Stop asking questions & compute results

This command will cause AnyQuest for Windows to check for completeness of all questions asked, to compute, to store and to print the results if configured.

This process will be started immediately, and any other CBFs of the same question and any unasked questions will be ignored.

This command is useful, if you have loaded sub-forms or modules after your main questionnaire, which have already been called from the main questionnaire, and which you don't want to be executed again after the main questionnaire has been completed.

Important notice:

CallReturn and CallModule are not to be mixed. Both share a single stack for return addresses. With each return address, AnyQuest for Windows stores the type of its Call command. At any time, AnyQuest only checks for return conditions which match the requirements of the return address which is on top of the return address stack.

This means, that if you issued a Call/Module and then a Call/Return command, the occurance of the end of a questionnaire definition file will not cause a return, until the Call/Return has been processed - which means, until a real Return command has been executed. The other way round, with a pending Call/Module, AnyQuest will ignore any occuring Returns, until the end of a questionnaire definition file has occured.

To avoid confusion: Handle with care!


CBF: Branch Destination

CBF: Destination or offset for Jump and Call commands

The Jump and Call commands need a destination which tells AnyQuest for Windows where to proceed.

A destination can be defined in the following formats:

•	Absolute global:	short_name!questionnr 	Example: NewQuireX!10

This causes AnyQuest for Windows to proceed with questionnaire "short_name", question nr. "questionnr".

"short_name" refers to the short questionnaire name which is defined in a questionnaire definition file. Question number refers to the question number within that questionnaire, with the first question of the questionnaire having the number 1.

•	Absolute global:	short_name.language_descriptor!questionnr 	Example: NewQuireX.en!10

This causes AnyQuest for Windows to proceed with questionnaire "short_name", which has its language descriptor set to "en", question nr. "questionnr".

"short_name" refers to the short questionnaire name which is defined in a questionnaire definition file. "language_descriptor" refers to the content of the field "language" in the dialog "Edit" - "Edit questionnaire descriptors...". Question number refers to the question number within that questionnaire, with the first question of the questionnaire having the number 1.

This new option, added in version 3.08, should be backwards compatible as long as your short questionnaire names and short questionnaire names plus language identifiers of different questionnaires cannot be mixed up.

•	Absolute global:	filename!questionnr 	Example: NEQUIXEN.QDW!10

This causes AnyQuest for Windows to proceed with questionnaire "filename", question nr. "questionnr".

"filename" refers to the filename of a questionnaire that AnyQuest has put in its appropriate memory field after the filename is loaded; including an extension - if you are unsure, you may use AnyQuest's built in debugging options or save the questionnaire definition file in text format and review this output. AnyQuest knows and stores the complete path to the file after it has been loaded, but as the comparison of filename and destination is performed with right alignment, and limited to the length of the destination string, you may leave out as many leading characters of the complete filename path as you like. Question number refers to the question number within that questionnaire, with the first question of the questionnaire having the number 1.

This new option, added in version 3.08, should be backwards compatible as long as your short questionnaire names and filenames of different questionnaires cannot be mixed up.

As target variables from all loaded questionnaires are compared in all variations to the destination string, the last loaded questionnaire that has a valid match is actually used as branch destination.

•	Absolute local:	questionnr 	Example: 10

This causes AnyQuest for Windows to proceed with question nr. "questionnr" in the current questionnaire.

Question number refers to the question number within that questionnaire, with the first question of the questionnaire having the number 1.

•	Relative local:	+questionnr 	Example: +10

•	Relative local:	-questionnr 	Example: -10

This causes AnyQuest for Windows to proceed with the question whose nr. is computed from adding the given offset to the current question nr..

Theoretically, you can use the offset format together with specification of a questionnaire name, but this is of rather academical interest...

Important notice:

The referenced questionnaire has to be in AnyQuest's memory, and the specified question number has to be available when the command is issued. Otherwise, an error message will appear. No questionnaires will be loaded automatically.

When adding or deleting questions, the formula consistency check is a useful feature.

Be very careful when you change a short questionnaire name of any questionnaire: Especially, if you did not design it on your own, this might be referenced in a CBF in any other questionnaire definition file somewhere in the world...


Defining result formulas

Within each questionnaire definition file, formulas for computation of results (i.e., scoring of a questionnaire) can be defined.

Result formulas can process data derived from answers of questions of the same questionnaire, as well as results from preceeding formulas.

Result formulas can also include statements which call external applications, and exchange data with these - either to communicate with external data sources or targets (databases), to have complicated computations performed externally, or to use external cryptographic signature services or the like.

Computed numeric results and computed string results can be written to the result file generated after each questionnaire session, or used in automatically generated printouts on paper or e.g. in PDF or PostScript files.

Complete result files (with meta information, raw data and computed numeric and string results) can automatically be handed over to external applications e.g. to automatically insert results into databases, practice information systems, hospital information systems, to compute cryptographic signatures etc.

Result formulas usually render a numeric result with an additional string representation. The string representation can, however, be manipulated seperately from the numerical result and it may well be the only result of a formula, if required.

Each result formula includes defined labels and other meta and control information for file output and generated printouts of various types.

Showing the result formula definition dialog

If you select "Edit Result Formulas" from the "Edit" menu, the result formula definition dialog window appears.

When it appears, the result formula definition dialog automatically shows the last defined result formula (the one with the highest sequence number) of the currently displayed questionnaire. The number of this formula is displayed in the field "Formula#". If the currently displayed questionnaire has no defined result formulas at all, "0" is displayed as result formula number.

You can continue to navigate through loaded questions or questionnaires in the main window while the result formula editing dialog window is shown. If you go to another questionnaire in the main window, the last formula of that questionnaire will automatically appear in the the formula definition dialog window.

Adding, inserting, deleting, and moving result formulas

To add a new result formula to a questionnaire, you may either use your mouse to increase the number of the currently displayed formula by one beyond the last result formula that was defined for this questionnaire by clicking on the upwards pointing arrow next to the current result formula number. In order to add the first result formula to a questionnaire definition file, just click once to make the result formula number "0" change into a "1". A new formula is automatically generated, and all other fields of the result formula definition dialog are filled in with default values.

Since version 3.36, formulas can also be inserted before the currently displayed formula (in contrast to being added after the last one), by clicking on the "Ins" button.

To delete a formula, simply press the "Del" button while it is being displayed. The numbers of succeeding formulas are automatically decremented by one.

Since version 3.36, you can also use the two buttons with upwards and downwards pointing arrows next to the "Ins" and "Del" buttons, to move a formula upwards or downwards in the sequence of defined formulas for the current questionnaire. This is particularly useful to change the order in which results appear in the produced result file or result printouts.

If you command an operation that changes result formula sequence numbers (or deletes result formulas) for the first time after opening the formula definition dialog, a warning message is displayed that reminds you to review all of your formulas, checking all references to other formulas by formula number. Typically, such references use a statement like "n FN": e.g. "2 FN" re-uses the result of formula number 2. As the argument of such a reference may be any computable expression, and is not restricted to simple numbers, the currently implemented formula consistency check does not cover references to formula numbers. (In the future, an added formula consistency check functionality guarding such changes might add/remove 1 +  or 1 - statements as needed in the future - but that would affect clarity and comprehensibility of formula definitions.)

When you add or insert a new formula, the content of any preceeding result formula (if available) or otherwise succeeding (if available) will be considered for usage as a templeate and mostly copied.

The UPN and label fields receive special handling in this process:

Only for the three label definition fields: If the old formula used as template has a label beginning with "Result No. ", then the new label will be generated as "Result No. n", where "n" is the number of the new formula.

For the three label definition fields and the UPN definition field: If the old formula used as template as field content ending with anything numeric (from the digits 0..9), the last numeric part will be incremented by one. A leading 1 may be inserted as required, given that sufficient space is available. If the old formula has content that ends with something non-numeric, it will be preserved unchanged.

This behaviour supports you quite effectively when creating sequences of similar result formulas, with similar UPN statements, and/or similar labels, be they numbered or not (see examples below).

Pending edits are transferred from the dialog to memory when the dialog is closed, when the currently displayed formula is changed, and when the currently active questionnaire is changed.

Editing result formulas, and the meaning of certain fields in the result formula definition

To change a the UPN statements defining the computation instructions for a result formula just type a new UPN collection of functions and numbers into the corresponding window of the formula definition dialog while that formula is being displayed. Any other components can be edited in a similar manner.

You can enter different result labels and output formats for file storage, single printout and cumulative printout. Note that the file storage routine will always add the short questionnaire name (subheading) before and a colon after the result label. It will insert a space between a computed result and the unit of measurement as well. This has been defined as a standard format for the *.anq file and is not meant to be changeable.

Please note that your labels must not contain any colon (":"), because this is reserved as separator between label and value within the *.anq file.

If you leave the fields for single or cumulative printout labels empty in any result formula definition, the result will not be printed in the respective printout. This can be useful to compute intermediate results which are referenced in other formulas or which are only required for scientific, not for practical purposes. Thereby you can at the same time generate a concise output to inform individual patient management, and at the same time, more comprehensive result files to provied intermediate (or custom labelled raw) data for scientific analysis.

The pre-set value "Units" in the Suffix field should either be replaced by something meaningful (like "%", "cm", "kg", "points" or similar), or removed. Removing it simplifies the structure of the result file that will later be generated after each questionnaire completion. As content from all fields of a preceeding formula is copied when new formulas are added, it is advisable to make sure that all fields have reasonable content (worth copying to all formulas) before adding a large number of formulas.

If a questionnaire definition file has no result formulas at all, no printout will be generated for this qdw, unless you set the option "Printout even for QDWs without printable Result formulas" in the "Printing" menu.

If a questionnaire definition file has result formulas, but no cumulative printout labels at all, or no valid cumulative printout data at all at printing time, no cumulative printout will be generated for this qdw, unless you set the option "Printout even for QDWs without printable Result formulas" in the "Printing" menu.

If a questionnaire definition file has result formulas, but no single printout labels at all (since version 2.61), or no valid single printout data at all at printing time, no single printout will be generated for this qdw, unless you set the option "Printout even for QDWs without printable Result formulas" in the "Printing" menu.

For each formula, you can add minimum and maximum values of the bargraph generated within the single and cumulative printout. If you specify the same value for minimum and maximum, no bargraph will be printed and only the string result (which may be a string representation of a numeric result, however) will appear instead. The range and polarity of bargraphs can be chosen as required quite deliberately - AnyQuest will automatically adjust any labels, arrangement of y=0 midlines etc. It correctly handles positive and negative values, graphs in either direction, and graph ranges below or exceeding the true result range.

Advanced printout definition possibilities beyond the result formula definition dialog are explained otherwere in this on-line-help and demonstrated in supplied examples and on the WWW site of AnyQuest for Windows and the QL-Recorder.

The numbers of displayed formulas start with 1 for each loaded questionnaire.

When adding or deleting questions, the formula consistency check is a useful feature.

From version 2.27 on, result formulas (not Conditional branch formulas!) can be up to 32384 characters long.

Examples: Common questionnaire scoring tasks and corresponding result formulas in AnyQuest's UPN formula definition language

Please note: Basic information about AnyQuest's UPN formula definition language is available here. The detailed meaning and mode of operation for each statement used in the examples below is explained  here.

Please also note that whenever a scoring task is too complex (or established questionnaire scoring instructions imply some uncommon handling for missing values due to whatever reason), UPN statements can be used to instruct AnyQuest to supply data to an external application, call that application to process that data, and receive computed results back from that external application. This is possible either at any position within a given formula, or stretched across multiple formulas, e.g. initiating the external data processing in the first one and afterwards reading the externally computed results into multiple successive formulas in one go. The newer SF-36 adoption for AnyQuest e.g. makes use of that mechanism.

The following examples illustrate these tasks:

Creation of a series of similar result formulas

Counting the number of missing values, and re-use of this result to control provision of computed results or "undefined" depending upon how many questions were unanswered

Combining multiple answers using the SUM or the AVG functions

Example: Creating a series of similar result formulas

If you have a questionnaire with an introduction screen, and want to copy the individual result of each succeding question (identified in AnyQuest's UPN formula definition language by "v2", "v2" etc.) through to named output only in the "computed results" section of the result file, you may need a large number of formulas like these:

Formula 1:	UPN: v2 	File output label: YSR1 (leave printout labels empty, because no printout is needed for the individual items)

Formula 2:	UPN: v3 	File output label: YSR2

Formula 3:	UPN: v4 	File output label: YSR3

...

Formula 55:	UPN: v101 	File output label: YSR55

To define such a sequence of formulas, it is sufficient to create the first result formula, make sure all fields contain the desired settings, and repeatedly click onto the upward counting arrow next to the formula number to create new formulas. The numeric part at the end of both the "UPN" text an the "File output label" text will be incremented by one for each formula automatically when it is created.

In the case of the YSR questionnaire, the series becomes irregular when YSR56a through YSR56h are used as the names for questions 56 etc. (in AnyQuest's UPN speak: "v57" etc.) so you need to define these formulas semi-manually:

Formula 56:	UPN: v57 	File output label: YSR56a

Formula 55:	UPN: v58 	File output label: YSR56b

...

Formula 55:	UPN: v64 	File output label: YSR56h

Once you changed the automatically generated YSR56 to YSR56a, AnyQuest's formula definition dialog will continue to increment v57 to v58 when you add the next formula, but will leave YSR56a unchanged (because it doesn't end with a number). So all you need to do is change the last character for the label in this formula, and add the next formula.

As soon as you have arrived at v65 / YSR56h, you remove the "h". From there on, it is just clicking "upwards" = adding new formulas one after another again, and AnyQuest will continue to generate this regular series:

Formula 64:	UPN: v65 	File output label: YSR57

Formula 65:	UPN: v66 	File output label: YSR58

Formula 66:	UPN: v67 	File output label: YSR59

...

Formula 121:	UPN: v122 	File output label: YSR121

Rather difficult formulas resembling those suggested to score the YSR:

Please note: The result formula numbers for the following examples apply when they are added to a questionniare definition file right after the sequence of result formulas demonstrated above. The result formula numbers are important in UPN statements which re-use previously computed results via their result formula number, i.e. "122 FN".

Formula 122: 	Compute the number of missing values (this example applies if 118 values are expected):

UPN: 	v2 testundefined v3 testundefined v4 testundefined v5 ... v120 testundefined 118 sum

File output label: 	NMISSING

Single printout label: 	Number of missing items (8 max. allowed)

This formula takes each value from each question (this value is the sum of all checked regular answer fields or "undefined", if a special "can't answer" or "don't want to answer" field was checked; and in this questionnaire, all answer fields of one question are usually mutually exclusive), and tests if it's undefined. Each of these tests results in 0 or 1, and all of these 118 results are finally summed up. Please note that the actual UPN formula is shortened here. You must write the complete formula, replacing "..." above with the references to the desired questions and corresponding "testundefined" statements. Fortunately, most formulas don't refer to hundreds of questions - and with some computer experience, you can use a spreadsheet an/or a good text editor with search and replace capability that also handles newlines, to synthesize the required UPN formula text very fast.

Formula 123: 	If NMISSING (i.e., the numeric result computed by formula 122 above) is below or equal to 8, then compute and report the sum of the answers of 103 questions. Otherwise, report "undefined".

UPN: 	undefined 122 FN 8 > cstop pop v2 v3 v4 v5 v6 v8 v9 v10 ... v120 103 sum

File output label: 	YS_TOT

Single printout label: 	YSR total problem score

Required quota...: 	0 (This effectively bypasses AnyQuest's automatic built in quota control, see below.)

Formula 124: 	If NMISSING is below or equal to eight, then, depending upon the sex (1 or 2) provided during PID collection, compute a certain measure using two different sets of questions:

UPN: 	undefined 122 FN 8 > cstop pop v9 v10 v13 v14 ... v111 v120 44 sum CLRS FRPIDsex VALS POP 1 = * v2 v10 v12 v13 v14 ... v111 v120 37 sum CLRS FRPIDsex VALS POP 2 = * +

File output label: 	YS_INT

Single printout label: 	YSR internalisation

Required quota...: 	0 (This effectively bypasses AnyQuest's automatic built in quota control, see below.)

Please note that for the above examples, NMISSING is computed first (across [almost, for the YSR] all questions of the whole questionnaire), and further results are afterwards computed or merely reported as "undefined" depending upon NMISSING. This approach is apparently recommended by CBCL and YSR scoring guidelines. However, some of the CBCL scales are combined from merely 7, 8, or 9 answers. Given bad luck, an NMISSING of 8 could occur while (almost) all answers of such a scale are "undefined", but according to the recommended approach, such an extremely affected scale would still have to be computed.

Maybe this has never happened in real life. And maybe the recommended approach for YSR and CBCL scoring is well justified and considered appropriate, being a result of analysis done in the validation stage, or honouring the fact that additional work would be required to compute separate NMISSINGs for each of the scales.

Nevertheless, the next section demonstrates AnyQuest's built in capabilities to do just that completely automatically. AnyQuest can thereby decide about whether either scale should be computed considering just the answers that would contribute to this scale - without requiring any additional formula definition work.

AnyQuest's built in capabilities to guard against unintentionally missing answers, and to handle intentionally missing answers:

Please note that AnyQuest does not allow accidentally missing answers, but provides special answer field types to enable patients to denote that they cannot or don't want to answer a given question.

AnyQuest also offers a built in, simply deployable, and possibly more suitable approach to take thereby intentinally unanswered questions into account for questionnaire scoring: You can specify an individual (default) threshold (required quota) value for each result formula to be used for SUM and AVG statements. When a SUM or AVG statement appears, AnyQuest automatically computes the percentage of missing values among its arguments - and when the required quota is not met, the statement returns "undefined". There is also a special UPN statement that lets you set a new quotas anywhere you like in a UPN formula. So this approach is quite straightforward to understand and very easy to use.

Examples:

Formula 1: 	Compute the sum of the individual results from 5 questions. If more than 50% of answers are missing (for example, "can't answer" or "don't want to answer"), then the result shall be undefined. Supposedly, each individual question returns a result out of 0, 1, 2 or undefined, and the sum is in the range of 0..10, and we want a graphical representation to appear in the result printout:

UPN: 	v2 v3 v5 v7 v11 5 sum

Required quota...: 	50

Single printout label: 	Sum of 5 answers (or 2 answers at least)

Bar min: 	 0

Bar max: 	 10

If you use the SUM statement, and an answer is missing, the resuting sum cannot reach the maximum possible value. If you want to "extrapolate" a result that covers the range that could have been covered from 5 answers, when fewer answers are given, it is possible to use the AVG statement instead. It will compute the arithmetic average of its arguments, and automatically adjust the denominator for the number of arguments if any argument is "undefined". Using AVG, will of course return a result in the range of the results of individual questions, so you may need to scale the result to achieve the same range as you would by SUMming up all results.

Formula 2: 	Compute the average of the individual results from 5 questions. If more than 50% of answers are missing (for example, "can't answer" or "don't want to answer"), then the result shall be undefined. Supposedly, each question had an answer out of 0, 1, 2 or undefined, and we want to get a result in the range of 0..10 to remain compatible with what Formula 1 above would have produced. So please finally scale the result by 5. And, produce a graphical printout.

UPN: 	v2 v3 v5 v7 v11 5 avg 5 *

Required quota...: 	50

Single printout label: 	Scaled average of 5 answers (or 2 answers at least)

Bar min: 	 0

Bar max: 	 10

Please note, that either summing up, or averaging (and extrapolating from whatever information snipplet is available) may be appropriate. You would sum up, if you collected hints for something unpleasant, and would NOT want to overrate the problem when any question was left unanswered (i.e., the patient couldn't or didn't want to answer, and either special answer field was checked). You would average, when you would want to cover the complete possible range of results no matter if complete, or less complete information were available.

Now, a different, much simpler scenario:

We have a questionnaire with one (dummy) Infoscreen and 3 true question screens. Each question has 5 regular fields with numeric values of 1, 2, 3, 4, 5 and two special answer fields for "can't answer" or "don't answer". If one regular answer field is checked, it returns the value of that answer field, and if a special answer field is checked, it returns "undefined". All answer fields are mutually exclusive, i.e. only one answer field can be checked.

Formula 3: 	To warm up, let's compute the sum of the answers from all 3 questions, without any scaling, at least 50% of all answers required:

UPN: 	v2 v3 v4 3 sum

Required quota...: 	50

Single printout label: 	Sum of 3 answers (or 1 at least)

Bar min: 	 3

Bar max: 	 15

Please note: We expect the result to range from 3 to 15, but if one question has not been answered, the result may as well drop below 3 and never be able to reach 15! AnyQuest will indicate an out of range result in its printout. The lower end problem comes from the fact, that the questionnaire author decided to give the lowest answer a 1 (instead of a 0) as numerical value, and the upper end problem comes from the fact, that he instructed us to sum up the values instead of averaging (and thereby extrapolating) whatever would be available.

Formula 4: 	In order to avoid the upper end problem, let's average the result instead of summing. First, let's be satisfied with a result range changed from 3..15 over to 1..5 as well:

UPN: 	v2 v3 v4 3 avg

Required quota...: 	50

Single printout label: 	Avg of 3 answers (or 1 at least)

Bar min: 	 1

Bar max: 	 5

Please note: Now, the result will be from 1 to 5 no matter if 3 or 2 questions have been answered. It would be useful to specify a number of digits ("precision") after the decimal point above 0 as well (e.g.: digits: 6, precision: 2), because we expect decimal fractions from the averaging process here.

Formula 5: 	Now, we want to remove the +1 offset, i.e. shift the result range from 1..5 to 0..4:

UPN: 	v2 v3 v4 3 avg 1 -

Required quota...: 	50

Single printout label: 	Avg of 3 answers (or 1 at least)

Bar min: 	 0

Bar max: 	 4

Please note: Now, the result will be from 0 to 4 no matter if 3 or 2 questions have been answered. We subtracted 1 from the computed average; alternatively, we could have subtracted 1 from either answer as well: "v2 1 - v3 1 - v4 1 - 3 avg". Please also note that we updated the "Bar min" and "Bar max" values to match the new expected result range.

Formula 6: 	Now, we want to scale the result from a 0..4 range onto a 0..100 range:

UPN: 	v2 v3 v4 3 avg 1 - 4 / 100 *

Required quota...: 	50

Single printout label: 	Avg of 3 answers (or 1 at least)

Bar min: 	 0

Bar max: 	 100

Please note: Now, the result will be from 0 to 100 no matter if 3 or 2 questions have been answered. We divided the result by 4, then multiplied by 100 - alternatively, we could just have multiplied by 25, of course: "v2 v3 v4 3 avg 1 - 25 *". The division and multiplication sequence may simplify comprehensibility of a formula, and also allow for more precise computation when scaling factors like 100/3 etc. are involved. (Internally, AnyQuest's built in UPN machine is still limited to extended precision floating point operations - but usually, this not relevant in the context of patient questionnaire processing.) Please also note that we updated the "Bar min" and "Bar max" values to match the new expected result range.

Formula 7: 	Finally, let's invert that result by subtracting it all from 100:

UPN: 	100 v2 v3 v4 3 avg 1 - 4 / 100 * -

Required quota...: 	50

Single printout label: 	Avg of 3 answers (or 1 at least)

Bar min: 	 0

Bar max: 	 100

Please note: Now, the result will be from 0 to 100. We could also have inverted the computed average before scaling by subtracting it from 4: "4 v2 v3 v4 3 avg 1 - - 4 / 100 *". We are free to exchange "Bar min" and "Bar max" as well.


Formula consistency check

When this feature from the "Edit"-menu is activated, AnyQuest for Windows helps you to maintain the consistency of references from formulas to questions.

When you add a question to a questionnaire, which causes the numbers of succeeding questions in a questionnaire to increase, references in formulas are updated automatically.

When you delete a question from a questionnaire, which causes the numbers of succeeding questions in a questionnaire to decrease, references in formulas are updated automatically. Further, references to the deleted question are marked, and affected formulas can be displayed for editing automatically.

When you import questions and formulas from a *.qdw questionnaire definition file into a currently displayed questionnaire, formula consistency check will try to adjust all global and local references in both involved questionnaires, for both result formulas and conditional branching formulas, adequately. For this purpose, result formulas and conditional branching formulas of the questionnaire that was already there are checked whenever a question is generated during the import, and formulas of the newly imported questionnaire are checked immediately after the import has taken place.

When you execute a *.qdt questionnaire definition file, formula consistency check will only cover loaded formulas whenever new answer fields are generated, but it will not automatically perform any additional checking of formulas after the *.qdt file has been executed.

The feature can be deactivated to allow the redesign of (portions of) a questionnaire without affecting associated formula definitions. In this case, however, be sure to check the links between your formulas and your questions afterwards. Otherwise even a single inserted "Infoscreen" can demolish result computation completely.

Formula consistency check only works for references within all questionnaires which are loaded into AnyQuest's mind when a respective command is issued. In the future I might even extend it to check all related questionnaire definition files which are available on disk. But this is not a high priority programming task.

Although formula consistency check seems to work rather well and can save you a lot of work, I would recommend you to test the results of all formulas in any case before you present a massively edited questionnaire to a patient.

Please note: Activated formula consistency check can slow down the loading of questionnaires substantially, when complex formulas are used. To avoid this effect, since AnyQuest Version 2.48, if the edit layout mode is not active, it is not performed during adding (loading) or deleting of questions, but only after importing questionnaires.


Communication with external software

To allow you to integrate AnyQuest for Windows better in your existing IT environments, it offers some ways to communicate with external software:

•	Calling of a program to provide access to the configured data directory (e.g. by establishing a network connection).

•	Calling external programs to verify, confirm or complete collected patient identification information or supply it completely on their own.

•	Calling external programs to initiate or perform further processing of collected questionnaire data or generated printouts.

•	Calling external programs to process data externally as part of any result formula or conditional branching formula calculation in order to extend AnyQuest's built in UPN command functionality.

AnyQuest defines some protocols for communication with these external programs. Generally, AnyQuest writes its own information into a file, supplies the external program with the filename when calling it, and if applicable, reads the same file to receive any information returning from that program. For the first two cases, AnyQuest can be configured to wait for the completion of the external program if required; in the third case, it definitely waits until the external program has completed. External programs' names, locations and optional user-interfaces are completely free.

Integrating external programs in UPN formulas gives you an extremely versatile instrument: Not only can you use external scoring algorithms, but before presentation and completion of each individual question can you initiate external communication as part of the conditional branching UPN formulas. So you may control e.g. which questions are presented through an outside application which receives the answers a patient has given immediately, or you can integrate your own interactive elements based upon your own software within an AnyQuest questionnaire. Within result formulas and conditional branching formulas, you may mix internal UPN commands and external computation resources as you like.

If AnyQuest waits for the finishing of an external program, this external program must open a window and close it again (for MS-DOS programs, this will occur automatically) to enable AnyQuest to detect its finishing. If this window shall not be visible to the user, it can be positioned outside the visible screen, e.g. using negative coordinates for its origin.

Very important note:  When I tested the mechanism of calling external programs on a Windows 98 system, I found that the notepad.exe which comes with Windows, when closed, closed its window but did not stop to remain a task in the system. So AnyQuest for Windows would wait forever for it to "complete". Please try out whether called programs behave correctly, before you start to do real work with your configuration. If you want to call an editor and notepad.exe does not function as expected, you can try \windows\command\edit.com. If you observe a similar problem, you may reconsider whether AnyQuest actually needs to "wait" for the external task to end.

Very important note:  When I tested the mechanism of calling external programs on a Windows 2000 system, I found that after calling \winnt\system32\edit.com AnyQuest for Windows would wait forever for it to "complete". Please try out whether called programs behave correctly, before you start to do real work with your configuration. If you observe a similar problem, you may reconsider whether AnyQuest actually needs to "wait" for the external task to end.

Calling of a program to provide access to the configured data directory (e.g. by establishing a network connection)

•	When you press "Go" in the navigation window to begin a questionnaire administration, and when AnyQuest is about to save results to an *.anq file, AnyQuest checks whether it can access the configured data directory.

•	Since version 2.99, you can specify in the *.ini file the path of a program to be called, if this test fails, i.e. in order to set-up or restore a temporarily missing network connection.

•	You can also specify whether AnyQuest will wait for the called program to complete before it continues to run itself.

•	The parameters are (with usable example entries):
[External applications]
provide_access_to_data_directory=net use Z: \\MYSERVER\C$
provide_access_to_data_directory_wait=False
provide_access_to_data_directory_showcmd=1

•	The last parameter controls the appearance of the window of the called external application.
The meaning of its numeric value is:
sw_Hide=0
sw_ShowNormal=1
sw_ShowMinimized=2
sw_ShowMaximized=3
sw_ShowNoActivate=4
sw_Show=5
sw_Minimize=6
sw_ShowMinNoActive=7
sw_ShowNA=8
sw_Restore=9.
The default value is 1. Some values may affect the functionality of the corresponding parameter external_..._wait=True because the respective function monitors the existence of the window opened for the called application. This functionality is available since version 3.58.

•	After calling the external program, AnyQuest will wait for about 2 seconds, then try to access the configured data directory again. Only if that still fails, it will notify the user and ask him to browse to a valid data directory.

•	If the users says "Cancel" in that browsing dialog, AnyQuest will retry the complete sequence up to 3 times before questionnaire administration starts, and finally return to the navigation dialog. It will try for an unlimited number of times, when it is about to save collected data.

Notification of a newly available *.anq file through an external program

•	After an *.anq file has been written, AnyQuest for Windows can call an external program to give notification of the newly available file.

•	You can specify the path of the program to be called in the *.ini file.

•	You can also specify whether AnyQuest will wait for the called program to complete before it continues to run itself.

•	The parameters are:
[External applications]
notify_after_anq_completely_written=anq2gdt.exe
notify_after_anq_completely_written_wait=True
notify_after_anq_completely_written_showcmd=1

•	The last parameter controls the appearance of the window of the called external application.
The meaning of its numeric value is:
sw_Hide=0
sw_ShowNormal=1
sw_ShowMinimized=2
sw_ShowMaximized=3
sw_ShowNoActivate=4
sw_Show=5
sw_Minimize=6
sw_ShowMinNoActive=7
sw_ShowNA=8
sw_Restore=9.
The default value is 1. Some values may affect the functionality of the corresponding parameter external_..._wait=True because the respective function monitors the existence of the window opened for the called application. This functionality is available since version 3.58.

 •	AnyQuest calls the specified program providing the filename of the last written *.anq file as command line parameter.

The external notification program is called after the Thank-You-Box has been shown and after printouts have been generated, if configured.

The mechanism can e.g. be used to interface with electronic patient file or practice management software e.g. via the GDT / LDT / xDT interface. A reference application and reference configurations for a setup where AnyQuest is seamlessly integrated with such an environment is available in the software library in AnyQuest's WWW site, this includes further documentation, and (on the information CD) a video showing such a setup in operation.

The mechanism can also be used to automatically upload results into an SQL data base by calling an external SQL data base client software, or just a batch file calling an (s)FTP client that takes care of uploading a copy of AnyQuest's result file into a remote server directory. An example setup of AnyQuest on a client, calling such a batch file for FTP upload, and scripts on a server monitoring an incoming directory, and automatically calling a script to write incoming data into a Borland Interbase SQL data base, and then archiving incoming data files, and web based retrieval of patient related QoL data, for all kinds of QoL questionnaires available as AnyQuest questionnaire definition files, is available upon request.

Checking or acquiring patient identification data by an external program

•	After patient identification data have been collected, AnyQuest for Windows can call an external program to check whether collected data are valid.

•	This external program is given the collected data. It can reject or modify the received data, or it can leave them unaltered.

•	If you deactivate all of AnyQuest's own patient identification collection screens, the external program can completely supply all patient identification data.

•	You can specify the path of the program to be called in the *.ini file.

•	You can also specify whether AnyQuest will wait for the called program to complete before it continues to run itself.

•	If you specified that AnyQuest needs not wait, only a notification without any confirmation or alteration of the collected data can be performed.

•	The parameters are (with usable example values):
[External applications]
check_after_PID_collected=gdt2pid.exe
check_after_PID_collected_wait=True
check_after_PID_collected_showcmd=1

•	Since version 3.66, the following parameters control an optional conversion between UTF8 multibyte and ANSI single byte characters (details given below):
check_after_PID_collected_out_tx_ANSI_to_UTF8=False|True
check_after_PID_collected_in_tx_UTF8_to_ANSI=False|True

•	The last parameter controls the appearance of the window of the called external application.
The meaning of its numeric value is:
sw_Hide=0
sw_ShowNormal=1
sw_ShowMinimized=2
sw_ShowMaximized=3
sw_ShowNoActivate=4
sw_Show=5
sw_Minimize=6
sw_ShowMinNoActive=7
sw_ShowNA=8
sw_Restore=9.
The default value is 1. Some values may affect the functionality of the corresponding parameter external_..._wait=True because the respective function monitors the existence of the window opened for the called application. This functionality is available since version 3.58.

•	AnyQuest calls the specified program providing the filename of the *.pid file which contains the last collected patient identification data set.

•	The file is located in the currently used data storage directory, and its filename is generated by AnyQuest and may be re-used later.

•	The file contains data in the same format as AnyQuest will write it into the resulting *.anq file, including the file header giving the used version of AnyQuest for Windows and the section header [patient identification].

•	The parameters group/pid, name, date of birth and computed age are always included in the file, optional parameters are only included if they are not empty.

•	If AnyQuest is not instructed to wait for the completion of the external program, the external program should remove the *.pid file when it does not need it anymore.

•	If AnyQuest is instructed to wait for the completion of the external program, the external program must never remove the file to prevent its name from being used by possible other instances of AnyQuest with write access to the same directory.

•	If the external program wants to write to the file, it must open it, reset the file pointer to the start of the file and then write. After the external program has completed, AnyQuest will re-read the file and afterwards delete it.

•	All parameters which can be checked in AnyQuest's navigation menu can be approved, changed or rejected by the external application by looking at the file and changing its contents, if required: If a parameter is approved and needs no change, the external application doesn't need to (but of course may) write it again to the returned file. If a parameter shall be changed, the external application just needs to write it into the returned file with the changed value. If any parameter cannot be accepted, and the external application does not know a reasonable value either (e.g. when an a patient ID code could not be found in an external database), it must write this parameter to the returned file with its value set to (rejected). The external application does not need to write any headers to the returned file, they are ignored when AnyQuest re-reads it.

•	If any single parameter is returned as (rejected) by the external application, AnyQuest will restart the collection of patient identification data, presenting all screens activated in the "Navigation" menu, pre-filled with the values previously entered or changed through the external application. Screens belonging to rejected parameters will not show any pre-filled values, however.

•	If any single parameter is returned as (abort) by the external application, AnyQuest will cancel the current questionnaire session. It will return to the "Navigation" dialog, or if the kiosk mode has been activated by setting "Navigation" - "Endless question asking", will start another session immediately.

This mechanism can e.g. be used to collect patient identification data from a card reader (in Germany, most patients use an ID-card issued from their health insurance company): You'd deactivate AnyQuest's internal screens for patient ID collection, and configure it to call an external program instead. This program would ask the patient to use the card reader, optionally verify collected data against an external database, and provide the patient ID data back in the file the name of which was given by AnyQuest when the external program was called. MS-DOS and MS-Windows based reference implementations of external applications to acquire card reader data and reference configurations are available upon request.

The mechanism can also be used to interface with electronic patient file or practice management software e.g. via the GDT / LDT / xDT interface. A reference application and reference configurations for a setup where AnyQuest is seamlessly integrated with such an environment is available in the software library in AnyQuest's WWW site, this includes further documentation, and (on the information CD) a video showing such a setup in operation.

Since version 2.82, you can also set the desired date format for dialogs and printouts to either DD.MM.YYYY or YYYY-MM-DD like in this *.ini file example.

Conversion between UTF8 multibyte and ANSI single byte characters, e.g. for interfacing with Microsoft .net applications

Since version 3.66, there is support for basic ANSI single byte to UTF8 multibyte character, and UTF8 multibyte to ANSI single byte character conversion for writing and reading of the temporary *.pid data exchange file.

As of version 3.66, the current implementation will convert code points from 128 to 255 between ANSI single byte and UTF8 multibyte representations. The actual code point will not be changed or further transcoded in any way. As Microsoft "Code Page 1252 Windows Latin 1 (ANSI)" (IANA "windows-1252") differs from the UTF8, ISO 8859-1 or ANSI IANA Latin-1 character sets for code points 0x80 to 0x9F (128 to 159), the conversion may return undesired characters in this range. Actual results may depend upon your system environment. Few of these characters should however occur in patient ID data.

Greek or other Windows character sets are currently not supported by the conversion algorithm in any way. UTF8 code points beyond 255, or invalid UTF8 code points, will be passed through unchanged. A debug message will appear in a non-blocking separate window (currently positioned by default to appear on a second monitor placed at the upper left of the primary monitor) to inform you about the limitation.

The converter should especially suffice to support German Umlauts: äöüÄÖÜ, sz: ß, and common vowels with accents etc. Due to its limitation to characters below code point 256 and the peculiarities of the Microsoft code page 1252, however, please test and review the suitability of the conversion algorithm in your own environment before using it in a production setting.

If enabled, the conversion will be applied to the content of the header line, and to the content of all data lines of the file, in either direction. Empty lines will be written directly without any transcoding applied.

The converter can currently be enabled only for the *.pid file. It is always automatically disabled when the [patient identification] section of the *.anq result file is written.

When the converter is disabled while a PID containing UTF8 characters is being acquired from a *.pid file, or when UTF8 characters are encountered beyond the working range of the converter, the incoming UTF8 multibyte characters are left unchanged and passed through to the *.anq result file. This will be perfect for any postprocessing application which correctly handles UTF8 multibyte characters. But when AnyQuest should display the same content on the screen (e.g. to confirm a patient ID), or put it into a printout, multibyte UTF8 characters will usually appear as multiple non-sensical ANSI characters, unreadable for humans.

Transcoding between UTF8 and ANSI characters was added specifically for communication with the Microsoft .net based meQ/TSS software prototypes developed in co-operation with Stefan Heckel Medizintechnik, Esslingen.

Newly supported configuration file parameters to control the transcoding are:

[External applications]

check_after_PID_collected_out_tx_ANSI_to_UTF8=False|True

check_after_PID_collected_in_tx_UTF8_to_ANSI=False|True.

Using an external program within AnyQuest's UPN formulas, e.g. an external scoring algorithm

There are specialised UPN commands to perform the following tasks:

•	reserve a name for an external communication file,

•	rewrite or append to the external communication file,

•	write data values into the external communication file from the UPN stack,

•	close the external communication file,

•	call an external program with the name of the external communication file supplied as a parameter,

•	reset the external communication file,

•	read data values from the external communication file to the UPN stack,

•	read strings from the external communication file to the string result of a formula,

•	close and delete the external communication file, thereby freeing the reserved filename.

To use an external program to perform some computations for AnyQuest, you would use these commands in the above order. You can distribute them across several formulas, but you should ensure that each opened communication file is finally closed and deleted. You can use only one communication file at the same time.

After calling the external program, AnyQuest waits until the external program has completed.

The following example...

first puts the reserved value for undefined values, then the numeric values resulting from answers to questions no. 2 and 1 on the UPN stack - the value from question 1 will be located at the top of the stack. It then prepares and opens an external communication file. Then it writes out 3 values from the stack - note that the top value will be written first. Afterwards, it closes the communication file.

Then, it calls the external program (automatically supplying the name of the external communication file name as parameter). It waits for this program to complete. The external program reads the numeric values from the communication file, rewrites the file, and puts computed results into it, together with a written text comment, e.g., information about the version of the external program.

When AnyQuest notices the external program has finished, it resets the communication file. It reads one numeric parameter for result formulas one and two, respectively, places each one on the stack and uses it as result for the respective formula. The final result formula sets its own numerical value to undefined and reads a string from the external communication file which it uses as a string result.

•	Result Formula 1, "Result 1": undefined v2 v1 extassign extrewrite 3 extwriteln extclose extcall=c:\anyquin\extscore\mycalc.exe extreset 1 extreadln

•	Result Formula 2: "Result 2": 1 extreadln

•	Result Formula 3: "Comments": undefined 1 extreadlnstring extclosedel

The detailed information regarding the commands is given in the description of UPN functions of AnyQuest for Windows.

Please note that the collection of all result formulas is currently executed at two occations after each completion of the questionnaire for internal purposes.

A real-life application example can be found in the questionnaire definition files for the SF-36 questionnaire using an external program that implements the standard scoring algorithms.

If you experience delays from loading external programs, please try using a disk cache.


Text Item Inline Formulas

Text Item Inline Formulas: #UPN ... #UPN

You can include one or multiple UPN formulas (started or enclosed by the escape #UPN) into any text of any displayable object, like question text, answer field labels and so on. Each text item inline UPN formula is evaluated just before (and whenever!) this text is (re-)displayed.

The detailed result of this approach depends upon what makes the result change, and whether the resulting text is completely cleared before being redisplayed.

One typical application is to display current patient ID data in the top left corner of each question, or to compute the sum from a number of text input fields and automatically display the computed sum into another text input field when all fields for summands have been filled in. Examples for these and other #UPN uses are available in various questionnaire definition files.

Thus, these functions further enhance the possible level of interactivity in AnyQuest's questionnaires.

However, please note: The original morphing questionnaire capability of AnyQuest for Windows was initially conceived to be used from CBFs (conditional branching formulas) with special UPN commands that could truly modify the content of text items from a loaded questionnaire definition.

The more recently added Text Item Inline Formulas can also be used to realize dynamically changing questionnaire content, computed on the fly - with or without usage of these special commands.

In contrast to CBFs, however, Text Item Inline Formulas are evaluated and replaced by the result of the evaluation every time a text item is re-displayed. Consequently, they cannot be controlled as precisely as conditional branching formulas. As of version 3.36, the background of direct text input fields is cleared before the content is redisplayed, but the background of many other text items needs not necessarily be cleared (in order to reduce flicker upon redrawing questionnaire content). Thus, changing the content between redraws of such text object without additional precautions may lead to illegible overlays.

Moreover, as long as they do not use the special "Questio-Morph-o-Matic" commands, Text Item Inline Formulas do not infer true changes to any text held in memory for the definition of a given text item. As a consequence, as of version 3.36, Text Item Inline Formulas cannot produce text that appears "correctly" e.g. in a Questionnaire-Filled-In-Printout. Neither will an answer field label which contains any Text Item Inline Formula appear in a computed string result as (probably) expected: In both cases, the Text Item Inline Formula itself would be visible instead.


Morphing questionnaires

More details about the Quality-of-Life-Recorder

iv. Dynamically morphing questionnaires - Jörg's magic Questio-Morph-o-Matic!

UPN commands can morph questionnaires during a session

There are some UPN commands which allow you to access question text, answer field notes and answer field label text during questionnaire presentation, e.g. CLRS, GETQS, SETQS, GETNS, SETNS, GETLS, SETLS, LENS. There are also commands to access check states of answer fields: GETC, SETC, COPYC. Finally, there is a command that allows for conditional execution of UPN commands: CSTOP.

These features can be used to generate morphing questionnaires, e.g. to allow a patient to enter an additional symptom in a direct text edit field, and later to ask how strong this symptom was in a separate question, or to load question texts or answer field labels during questionnaire presentation from an external application.

Please note: The above UPN commands were originally conceived to be used from CBFs (conditional branching formulas). Purpose, preferred application mode, and achievable possibilities differ substantially from the more recently added Text Item Inline Formulas. Differences are further explained on that help page.

Provided application example

An application of this technology is used in my questionnaire definition file implementing the interviewer version of the Calgary SAQLI, you can review it in the file SAQLIEN.QDW.

Try it yourself

To obtain a simplified example, you may create a questionnaire including one question (question number 1) that displays a list of symptoms to a patient. There are 8 symptoms in total. Each of the first seven symptoms is represented by one answer field that can be checked (question type: discrete answer fields, multiple check); its label text is set to describe the symptom (e.g.: "Headache"). In addition to these 7 fixed symptoms, you include another answer field: this is a direct text edit field with the label "Other symptom:". Each answer field (including the direct text edit field) has a numeric value reflecting a power of two: 1, 2, 4, 8, ... 128.

After this screen, you add an individual question for each available symptom to assess how problematic this symptom has been. Its explanation text reads: "How problematic has the following symptom been?", and each question text gives one of the symptoms from the list. Each of these questions gets a Conditional Branch Formula which skips it, if the numeric result of question number 1 (showing the list of all symptoms) does not include the power of two which corresponds to the respective symptom: "v1 1 and 0 =":"skip"; "v1 2 and 0 =":"skip"; "v1 4 and 0 =":"skip"...

The last of these individual questions, question number 9, has the first conditional branching formula: "v1 128 and 0 =":"skip". Additionally, it has a second conditional branching formula: "0 xOther#032symptom 9 setqs clrs 1 8 getns lens 0 = cstop 9 setqs":"skip". What does this second formula do?

•	The resulting action of this formula is "skip". This action has been selected, because all conditional branching formulas with this resulting action are processed before a question is displayed.

•	When the formula is processed, the UPN machine first puts a 0 onto the stack. This remains there till the end of the formula; it is only required because we abuse conditional branching formulas to manipulate questionnaire contents: After a conditional branching formula has been processed, it must leave one parameter on the stack that decides whether its resulting action (in this case, "skip") is performed. Actually, we don't want this action to be performed, so we make sure that the result of the formula is 0.

•	Next, "xOther#032symptom" causes the string "Other symptom" to be added to the current string result of the UPN machine. Because the string result was empty when the processing started, it is now exactly equal to "Other symptom". The included space has to be coded as #032, because otherwise the UPN machine treats spaces in an UPN formula as command delimiters.

•	"9 setqs" causes the question text of question number 9 of the current questionnaire to receive the contents of the current string result. Which means, that this question text reads "Other symptom" as soon as this part of the UPN formula has been processed.

•	"clrs" just clears the string result. And "1 8 getns" receives the direct edit text from answer field number 8 of question number 1: this was the space provided for the patient to enter his own symptom. The text which the patient entered here, is added to the (empty) string result.

•	"lens" measures the length of the current string result and puts the resulting number onto the stack. If a patient did not supply a symptom of his own, the length equals zero - and "0 =" tests, whether this is the case. If yes, "cstop" stops further processing of this formula. The question text of question number 9 will remain set to "Other symptom".

•	Otherwise, if a patient actually supplied a symptom of his own, the length of the current string result is above 0. "cstop" will be ignored, and "9 setqs" will copy the text from the current string result to the question text of question number 9. Afterwards, the question text of question number 9 will match whatever the patient originally typed into the direct text edit area of answer field number 8 from question 1.

The above example is, however, slightly unprecise: actually, question number 9 is skipped immediately by its first conditional branching formula, if a patient does not enter any symptom in the respective direct text edit field. In this case, the second conditional branching formula will never be executed, and the question will not be displayed at all. Thus, providing functionality to set the question text to a default text for this case, is rather pointless (apart from illustrating how such a default text can be implemented).

Providing a default text is more useful when you use two independent questions with symptom lists: one, to specify all symptoms which were problematic (including a direct text edit field to supply patient defined symptoms), and a second one, where the most important symptoms can be selected for later rating, no matter, whether a text describing a symptom has been entered by the patient, or not. This is actually what has been implemented in SAQLIEN.QDW. There, default texts can be set for question 41 depending upon entries in question 39, and for questions 65 and 66, as well. A similar construction is used for questions 69, 71, 100 and 101. Moreover, when question 39 is left, check states of its answer fields are copied to question 41, to allow the patient to comfortably remove checks from all symptoms but his 5 most important ones.

You can also use the questionnaire morphing functions together with other UPN functions for communication with external software. This can allow you to prepare a questionnaire frame, and to fill in the actually presented questions just in time, after having received them from an external application during questionnaire presentation.

I'm still looking for a name for this functionality: Morph-o-matic? Questio-Morph? Or Questi-morph-o-matic? - Questio-Morph-o-Matic! :-)


Undo functionality

If something goes wrong during questionnaire design or preparation of a set of questionnaires, you can use the function "Edit" - "Undo ...".

It allows you to go back up to 10 steps. This includes simple editing operations as well as adding or removing one or more questionnaires to or from the currently loaded set.

The number of operations, that can be undone (if any), and the type of the last one, are displayed in the "Edit" - "Undo ..." menu.

This functionality was (finally...) added in AnyQuest for Windows, Version 2.25 · .

Technical notes

Please note, that the undo-function saves temporary data to *.tmp files. To store them, AnyQuest for Windows tries to generate a directory "temp" under the directory, from which it was invoked. If it cannot create such a directory, it will use the directory, from which it was invoked.

The amount of drive space required by the undo function may depend on the size and number of contemporarily loaded questionnaires.

Because of this, I would recommend to run AnyQuest for Windows from a reasonably fast (or cached) drive rather than from a floppy disk.

Currently, files named "~*dir.tmp" contain directories of multiple temporary questionnaire definition files, while all other temporary files contain complete questionnaire definitions.

Crash recovery

Should your PC crash while working with AnyQuest for Windows or should some of your work get lost due to other reasons, you can copy available temporary files anywhere else, rename them, and try to load them as questionnaire definition files. If you are lucky, you will be able to recover your work up to the state just before the latest editing operation.

Be warned however, that all temporary files generated in one session are removed when AnyQuest for Windows is closed regularly, and that temporary files which survived a system crash may be overwritten during further editing sessions.


AnyQuery for Windows

Marc-André Sigle's AnyQuery for Windows

My brother Marc has contributed to the project by programming an application to view and print the contents of generated *.anq files.

The utility, AnyQuery for Windows, is currently available as free download from my WWW-site. It comes with its own help file.

Please review this help file to learn about its functionality and its current limitations.


Questionnaire copyright and history

Questionnaire definition file copyright and history documentation

What's this?

There is a possibility to add text information to any questionnaire definition file.

You would normally use this feature to add information like a copyright notice, the author's address or a literature reference for the original questionnaire or for the electronic questionnaire definition file itself to a questionnaire definition file.

You can also add information concerning the history of the file. This means, that everyone who changed or enhanced it, can add a small notice about the changes they performed.

Finally, you can add information about how to use the file. However, if these instructions are large, you should rather provide them as a seperate file and include a short reference in the history documentation only.

How does it work?

Displaying the current documentation of a questionnaire definition file: From the "Help"-menu, chose the option "Questionnaire copyright & history". This will bring up a dialog with the complete documentation of the currently displayed questionnaire. Using the scroll bars, you can view portions that don't fit in the window.

Adding to the documentation of a questionnaire definition file: Choose the button "Add information" in the dialog displaying the current documentation. A new dialog will open up, where you can just input or edit the text you wish to add. After you like the contents of the edit window, just push the button "Add information permanently...". Your information will be added permanently to the questionnaire definition file copyright and history documentation.

If you want to add special characters, use the MS-Windows program charmap.exe to learn how to enter them. E.g., to enter a © symbol, you would have to press the [Alt]-key, keep it pressed, type [0] [1] [6] [9] on the numeric keypad and release the [Alt]-key.

Each added block of information will start in a new line. If you wish to have separating empty lines, you can add them as well.

The total size of the documentation added to a single questionnaire may not exceed 65535 characters. You can add 1021 characters each time you invoke "Add information".

The information entered into this documentation, is protected against accidental change. If there is some definite need to change it, please contact me.

Important notice

Information that you added, can not be removed or changed any more after you saved the respective questionnaire definition file. So please be sure to review your additions before you save after adding information.


Questionnaire descriptors: language and version

Questionnaire descriptors: documentation of language and version

There is a possibility to add documentation regarding its language and its version to any questionnaire definition file.

This information will appear in the section reserved for meta-information in *.anq files and generated export files.

This is useful if you wish to implement international sets of questionnaires: Instead of including the language information into the short or long questionnaire name itself, it is documented seperately. When exporting data from sessions with questionnaires prepared like this, numeric results from all languages will be exported with identical variable names for raw data and results, but within the section [... meta information], the variable [... language] can be used to identify the language of a questionnaire that was used for each individual session.

While a questionnaire or a questionnaire definition file are under development, the feature can be used in a similar way to document the version that was used to collect data in an individual session. Data from sessions with different versions shall be collected with similar variable names for raw data and computed results, but within the but within the section [... meta information], the variable [... version] can be used to identify the language of a questionnaire that was used for each individual session.

Both descriptors can contain any text made up from usual characters, except for the colon (":"). Because the output file may be interpreted as ASCII file, extended characters may appear in an unexpected way in any target application. It is recommended to keep both strings short.

For the language descriptor, it is recommended to either use two-character codes like: en, fr, de, ce, cf, au, se, da... or native language names with a beginning upper-case letter like: English, Francais, Deutsch, Canadian-English, Canadien-Francais, Australian...

For the version descriptor, it is recommended to use a unique code for each version. The descriptor might consist of a major an a minor version number like: 1.0, 1.1, 1.2, 2.0..., or it might e.g. include a revision date like: 1.0 19991103 or like: 1.0 1999.11.03.

Both strings are additionally displayed in the directory of loaded questionnaires behind the AnyQuest navigation window.

Since version 3.52, a button Apply can be used to transfer the content of both text windows from the dialog to the internal variables of the currently displayed questionnaire definition. This function is useful to change the fields for the currently displayed questionnaire, and then go to another questionnaire while keeping this dialog window open for additional use.

Since version 3.52, additional buttons in the dialog window enable you to conveniently copy the entries for either field either from the preceding or succeding questionnaire, or to all preceding, all, or all succeeding questionnaires in memory. These functions are useful when you need to edit a whole set of questionnaires in a similar way and want to keep their questionnaire descriptor fields in sync.


Translation utilities - copying and distributing text and positions

Translation utilities - copying and distributing text

Sometimes you will face tasks like e.g. having to change the wording of the first answer field of each question. This occurs most often, when you translate a questionnaire definition file into another language.

You could use the Windows clipboard which would at least save the time for re-typing. But still this can be quite annoying: e.g. if you have to step through 4 answer field labels for each of 20 questions, and then have to change 20 explanations and another 20 second explanations afterwards...

To simplify tasks like this, AnyQuest for Windows Version 2.18 received added functions for comfortable copying of text to one or multiple items. These can be found in the context menu of several text objects through the option "Translation utilities".

Copying positions

More regularly, you will want to copy the new position of a moved object to all of its corresponding objects in other questions.

The necessary set of functions which operate on the position of objects can be found in the context menu of all objects through the option "Position".

They work for positions exactly like the translation utilities described above work for text.

To process or not to process...

Some options of the translation utilities and the corresponding functions to copy objects' positions refer to multiple "similar" objects.

•	Generally, a "similar" object is one of the same type in preceeding or succeeding questions or questionnaires.

•	Generally, if answer fields or their labels are processed, the destination question must also have the same number of answer fields.

•	If the source object, from whose context menu the command is issued, is not selected, selection will be ignored.

•	If the source object, from whose context menu the command is issued, is selected, only those destination objects which are also selected, will be processed.

•	If the command is issued from a selected answer field or its selected label, all selected answer fields of the currently displayed question will be processed together with all corresponding AND selected answer fields from questions with the same number of answer fields.

Example:

You might wish to change the label of the first answer field of each question from "Not at all" to "Überhaupt nicht". This can be done quite efficiently:

•	Move to the first eligible question.

•	Change the text of the label of the first answer field to "Überhaupt nicht" using its context menu.

•	From the context menu of this label, select "Translation utilities" - "Copy text to all succeeding similar items".

•	If required, change the size of this label to accomodate all the text you entered.

•	From the context menu of this label, select "Position" - "Copy to all succeeding similar items".

That's it!


General editing tools - search and replace text, layout editing and more

This dialog offers some tools to make changes throughout a question or a questionnaire very efficiently. It is available since version 3.35.

It provides an extension of the tools which have been offered through the context menus before, specifically for the functions for comfortable copying of text to one or multiple items. The newly provided tools are a lot more versatile and powerful.

Search and replace text

Sometimes you may want to search and replace text strings in all elements of a question or formula, or of a questionnaire, or even in all questions or formulas of all loaded questionnaires.

In versions of AnyQuest before 3.35, repeated similar changes affecting the complete text string of a series of given elements could be performed using the option "Translation utilities" in the context menus of the respective objects.

The new search and replace text in the General editing tools" dialog, however, is more flexible:

•	It can search and replace portions of texts within strings without affecting the remainder.

•	It can execute the same search and replace operation on different elements of a question or a questionnaire.

•	It can automatically operate upon elements that were out of reach for the previous Translation utilities option, like the pathnames of bitmap- or waveform-files.

The newline character is treated like any other character; it can be typed into the search/replace text input fields using Ctrl-Enter.

Text can also be copied from any text item related editing dialog using the system clipboard.

After the search/replace operation has completed, the number of replacements made is displayed.

To process or not to process...

A selection of checkboxes can be used to exactly determine which texts will be affected by a search and replace operation:

•	In the first column, you can select affected objects types on the questionnaire level. Accessible objects include questionnaire names, questions, explanations, answer fields, filenames, and even formulas.

•	In the second column, you can select affected text items of objhects that may include multiple text items, e.g. "value" or "label" of an answer field - or both.

•	The third column provides additional criteria, to limit the action only to regular answer fields, to selected objects, or to objects that belong to the currently displayed question.

Example

You might wish to change (or remove) the drive letter for all bitmap file pathnames (which might contain various smileys) associated to answer fields in a given questionnaire, because you want to move an AnyQuest for Windows setup from local drive C: to network drive F:

•	If desired, make a backup copy of the original configuration.

•	Make sure the questionnaire definition file to be edited is loaded.

•	In the field "Old text", enter: C:

•	In the field "New text", enter: F:

•	Click on the button: "Replace in pathnames in complete questionnaire definition file."

The ability to search and replace text across multiple concurrently loaded questionnaire definitions, as well as complete undo support has been added in version 3.60.

Future additions

Please note: Several new entries to manipulate object size have been added to the new context menu "Size" of various objects, including entries to paste size from a previously copied position, to adjust size to the text of a text item, or to adjust size to exactly match the size of a bitmap linked to an item..

The "General Editing Tools" dialog already contains several controls which shall support the convenient arrangement of answer fields in two dimensions. As of AnyQuest version 3.37, the actual functionality for this task has, however, only partially been implemented, so these controls are disabled.


Command line parameters

AnyQuest for Windows understands some command line parameters which you can either specify when you call the program from the DOS-box, or which you can use with a PIF-File (Program Information File, see Windows manual) or in the Display-Options-Filetype dialog of the program manager or Windows 95 Explorer or its pendant in the program manager.

In the command line, you can specify up to 255 file names, which may include one initialization file (*.ini), one message file (*.msg) and some questionnaire definition files (*.qdw).

If you specify a *.ini, this file will be used as configuration file. You can use this feature to support multiple contemporary configurations on one machine.

If you specify a *.msg file, this file will be used to supply international or modified versions of several messages and captions within AnyQuest for Windows.

If you do not specify drive and directory for *.msg and *.ini files, AnyQuin will try to load them from the current directory. This implies that it would be useful to specify a default directory in shortcuts or *.pif files which you wish to use to start AnyQuest for Windows.

If you specify one or multiple *.qdw file(s), each of these questionnaire definition files will be loaded in addition to those specified in the currently used *.ini file.


Interrupting and resuming a session

Interrupting, saving and resuming a session

Sometimes, a patient may not be able to complete a session. He might be too tired, too ill or he might be interrupted by something important (i.e., have to go to see somebody immediately).

Interrupting a session

In this case, from Version 2.26 on, you can interrupt a session and save it exactly as it is. Later, when the patient returns, you can continue the session just from the point where it was interrupted.

To interrupt a session,...

•	...in Windows 95 or Windows NT 4.0: click on the "Close"-button at the top right corner of AnyQuest's main window.

•	...in Windows 3.x: double click on the system menu at the top left corner of AnyQuest's main window (or click there once, and select: "Close".)

•	...press the keys [Alt]-[F4], which usually issue the "Close the active window" command.)

A new window will appear that lets you choose to "Continue", "Save" or "Abort" the current session.

If you wish to continue the session immediately, or to completely abort it without anything being saved, just press the appropriate button.

Please note: If you chose "Abort", all data entered in the session until then will be lost without further questioning! This is the default setting. However, the *.anq output file options dialog offers an option that will write an output file with the currently available data when a session is aborted.

Saving an interrupted session

If you wish to save the session, you can enter a short comment. This is for your comfort only: it will help you and your colleagues to identify an individual session, or it can inform your colleagues, why that session was interrupted.

Automatically, AnyQuest will store the name, patient identification code, date of birth and date of the session to help you identify a saved session later.

Selecting and resuming a saved session

If any saved sessions are available, the "AnyQuest Navigation" window will show an additional button labeled "Resume".

If you press this button, a list of all available saved sessions appears. You can select any session from that list and continue it immediately. As soon as you do this, the saved session is, of course, removed from the supply of saved sessions, and turned into the currently running one.

Logging session event information

In the *.anq output file options dialog, you can control whether session event information shall be logged in a separate section of each generated output file.

Background information

AnyQuest for Windows can handle up to 99 saved sessions at a time.

When it saves a session, AnyQuest stores all related information including used questionnaires, all selected options for displaying and reacting to input, options concerning printing and data storage and so on. These settings are restored for the duration of the resumed session, but they do not interfere with the settings that were active when AnyQuest is started.

This means, that you need not take any care for your settings, even if you use multiple configurations. You can comfortably resume saved sessions from any of your prepared configurations.

When the flag disable_write_ini_file, introduced in 2.68, is set to true, the current configuration just before a saved session is resumed cannot be stored in the currently used *.ini file. So after the resumed session has been completed, the original settings from the currently used *.ini file will be restored, which might be different from the settings that were active just before the resumption of the saved session was begun. This is the behaviour that you would expect after setting disable_write_ini_file=true.


Keyboard support

Keyboard support, keyboardless operation

Sometimes, it will be faster to use a keyboard than a mouse or another pointing device to issue a command.

AnyQuest for Windows supports the following keys:

General keys available in many dialogs

[Alt]-[F4] 	close a Window, interrupt a session or close the program.

[Alt]-[F4], [ESC] 	exit any PID collection screen immediately, aborting the session.

[Tab] 	cycle through several controls clockwise.

[Shift]-[Tab] 	cycle through several controls anti-clockwise.

[Space] 	press the currently selected button.

[Enter] 	press the default button.

[Ctrl]-[C], [Ctrl]-[Del] 	Copy selected text.

[Ctrl]-[X], [Shift]-[Del] 	Cut out selected text.

[Ctrl]-[V], [Shift]-[Ins] 	Paste selected text.

[Alt]-[Tab] 	Cycle through several running programs.

[Shift]-[Alt]-[Tab] 	Cycle through several running programs.

[Alt]-[Shift] 	Depending upon your machine setup: toggle keyboard layouts for different languages.

[Ctrl]-[Esc] 	Display the MS Windows Start Menu - same function as the Windows key.

[Alt] 	Preselect the first available option from the main menu - afterwards you can use the cursor keys and [Enter] to select menu options.

[Alt]+[A..Z] 	Select the single or next menu option with the hilighted character matching the character of the key you pressed together with [Alt].

Navigation within questionnaires, Transport bar replacement

[Home] 	go to the first question of the current questionnaire.

[End] 	go to the last question of the current questionnaire.

[Page Up] 	go to the preceeding question.

[Page Down] 	go to the succeeding question.

[Enter] 	continue, when an InfoScreen is being displayed.

Please note: Should your system direct keyboard focus to the transport bar, so that neither navigation via [Page Up]/[Page Down] the keyboard nor the keyboard shortcut commands below (e.g. [q][t][e]) have an effect, e.g. klick-right on "Question" - "Text" brings the keyboard input focus back to the main window, and afterwards, keyboard navigation and keyboard shortcut commands will work again.

Please note that in "Setup" mode, browsing through questionnaires may be blocked by an option from the "Navigation" menu.

Mouse replacement

[Up], [Down], [Left], [Right] 	Move the mouse pointer in AnyQuest's main window.

[Space] 	Click-left (currently not allways available and not really suitable to move around objects).

[Tab] 	Move the mouse-pointer to the next available answer field or text edit field, or move to the succeeding question.

[Shift]-[Tab] 	Move the mouse-pointer to the previous available answer field or text edit field, or move to the preceeding question.

Please note that in "Setup" mode, answering questions may be blocked by an option from the "Navigation" menu.

Controls

The following key combinations will allow to toggle several options even in the middle of a session, when there is no menu available

[Ctrl]-[F1] 	Display long questionnaire name toggle on/off.

[Ctrl]-[F2] 	Display short questionnaire name toggle on/off.

[Ctrl]-[F3] 	Display explanation name toggle on/off.

[Ctrl]-[F4] 	Display explanation2 name toggle on/off.

[Ctrl]-[F5] 	Display "can't answer " / "don't want to answer" fields + get extended text toggle on/off.

[Ctrl]-[F6] 	Display questionnaire number toggle on/off.

[Ctrl]-[F7] 	Display question number toggle on/off.

[Ctrl]-[F8] 	Display question results toggle on/off.

[Ctrl]-[F9] 	Display graphical progress indicator toggle on/off.

[Ctrl]-[F11] 	Reset pointer position upon next question display toggle on/off. This option is useful on touch-screens or pen-computers.

All control keys are available when a questionnaire is being displayed and when AnyQuest's main window has the input focus.

Especially helpful and important is [Ctrl]-[F5]: It allows you to have the "can't/don't want to answer" options turned of regularly. Only when a patient actually needs them, you can switch them on, check them, record reasons and switch them off again. This provides a clear, simple screen with more space available to regular answer fields while preserving the capacity to record the two special answers.

Please note: the modifier key [Ctrl] is labeled [Strg] on German keyboards.

Be careful not to use a set of options that depends on a keyboard when you use a pen-computer or touch-screen system without a physical keyboard or a sufficient keyboard emulation - and please read about the keyboard-less operation support below.

Special mouse click control for keyboard-less configurations

During questionnaire presentation, you can click into certain screen areas four times in sequence, avoiding any answer field, to control some options without a menu or a keyboard:

Lower left: 	Display "can't answer " / "don't want to answer" fields + get extended text toggle on/off.

Lower middle: 	Display transport bar toggle on/off.

Lower right: 	Play PC speaker sound toggle on/off.

Keyboard command sequences in layout edit mode

Instead of using the mouse to select a command from a context menu, you can type the following sequences to issue commands:

[ESC] 	clear the started keyboard command sequence

[Space] 	clear the started keyboard command sequence (and Click-left)

ra 	questionnaire add

ri 	questionnaire insert

rd 	questionnaire delete

rcg 	qestionnaire coordinates round to grid resolution (affects all elements of a single questionnaire)

qa 	question add

qi 	question insert

qd 	question delete

qte 	question text edit

qtx 	question text x clear

qtal 	question text align left

qtac 	question text align center

qtar 	question text align right

qtc 	question text copy

qtp 	question text paste

qttn 	question text copy to next

qttp 	question text copy to preceeding

qtfn 	question text copy from next

qtfp 	question text copy from preceeding

qpc 	question position copy

qpp 	question position paste

qptn 	question position copy to next

qptp 	question position copy to previous

qpfn 	question position copy from next

qpfp 	question position copy from previous

qsp 	question size paste (with fixed center)

qsat 	question size adjust to text size (with fixed center)

qsab 	question size adjust to bitmap size (with fixed center)

qcg 	qestion coordinates round to grid resolution (affects all elements of a single the question)

ete 	explanation text edit

etx 	explanation text x clear

etal 	explanation text align left

etac 	explanation text align center

etar 	explanation text align right

etc 	explanation text copy

etp 	explanation text paste

ettn 	explanation text copy to next

ettp 	explanation text copy to previous

etfn 	explanation text copy from next

etfp 	explanation text copy from previous

epc 	explanation position copy

epp 	explanation position paste

eptn 	explanation position copy to next

eptp 	explanation position copy to previous

epfn 	explanation position copy from next

epfp 	explanation position copy from previous

esp 	explanation size paste (with fixed center)

esat 	explanation size adjust to text size (with fixed center)

esab 	explanation size adjust to bitmap size (with fixed center)

2te 	explanation 2 text edit

2tx 	explanation 2 text x clear

2tal 	explanation 2 text align left

2tac 	explanation 2 text align center

2tar 	explanation 2 text align right

2tc 	explanation 2 text copy

2tp 	explanation 2 text paste

2ttn 	explanation 2 text copy to next

2ttp 	explanation 2 text copy to previous

2tfn 	explanation 2 text copy from next

2tfp 	explanation 2 text copy from previous

2pc 	explanation 2 position copy

2pp 	explanation 2 position paste

2ptn 	explanation 2 position copy to next

2ptp 	explanation 2 position copy to previous

2pfn 	explanation 2 position copy from next

2pfp 	explanation 2 position copy from previous

2sp 	explanation 2 size paste (with fixed center)

2sat 	explanation 2 size adjust to text size (with fixed center)

2sab 	explanation 2 size adjust to bitmap size (with fixed center)

aa 	answer field add

ad 	answer field delete

an 	answer field numeric or coded value

lte 	answer field label text edit

ltx 	answer field label text x clear

ltal 	answer field label text align left

ltac 	answer field label text align center

ltar 	answer field label text align right

lth 	answer field label text box height auto adjust

laa 	answer field label align above answer field

lab 	answer field label align below answer field

lal 	answer field label align to the left of the answer field

laf 	answer field label align to the right of the answer field

If you want to manipulate an answer field or an answer field label, you must identify it by placing the cursor over it before issuing one of the following commands:

tc 	answer field or answer field label (or any item under the cursor) text copy

tp 	answer field or answer field label (or any item under the cursor) text paste

ttn 	answer field or answer field label (or any item under the cursor) text copy to next

ttp 	answer field or answer field label (or any item under the cursor) text copy to previous

tfn 	answer field or answer field label (or any item under the cursor) text copy from next

tfp 	answer field or answer field label (or any item under the cursor) text copy from previous

pc 	answer field or answer field label (or any item under the cursor) position copy

pp 	answer field or answer field label (or any item under the cursor) position paste

ptn 	answer field or answer field label (or any item under the cursor) position copy to next

ptp 	answer field or answer field label (or any item under the cursor) position copy to previous

pfn 	answer field or answer field label (or any item under the cursor) position copy from next

pfp 	answer field or answer field label (or any item under the cursor) position copy from previous

sp 	answer field or answer field label (or any item under the cursor) size paste (with fixed center)

sat 	answer field or answer field label (or any item under the cursor) size adjust to text size (with fixed center)

sab 	answer field or answer field label (or any item under the cursor) size adjust to bitmap size (with fixed center)

Here are some commands to control the grid to which elements can be automatically aligned using qcg and rcg:

g1 	grid resolution 10 pixels

g2 	grid resolution 20 pixels

g3 	grid resolution 30 pixels

g4 	grid resolution 40 pixels

g5 	grid resolution 50 pixels

g6 	grid resolution 60 pixels

g7 	grid resolution 70 pixels

g8 	grid resolution 80 pixels

g9 	grid resolution 90 pixels

g0 	grid resolution 100 pixels

gs 	grid show on/off

go 	grid origin screen center/top left

gl 	grid lock on/off

After each key you type, you will hear a short beep. If four keys have been typed and no command has been recognised, or if the [ESC] key or the [Space] key is typed, the started keyboard command sequence will be cleared and the simple error signal will sound.


Printing simple cumulative statistics

Using "Analysis tools" - "Print cumulative statistics", you can generate a simple statistical evaluation derived from the last 16383 sessions stored in the defined target directory.

You can also configure the cumulative printout functionality to print reference values or reference ranges computed from locally collected data into cumulative printouts.

Built in functionality is also available to select individual result files from questionnaire administrations into groups, and to export or analyze them per group, including generation of tables with descriptive statistics and box plots.

To perform more sophisticated, well-designed and pre-planned scientific evaluation of collected data you should use third party software like Xplore (freeware), SPIDA, Excel, SPSS, SAS...


Selecting results from earlier sessions, generating printouts and lists

This dialog provides facilities to identify and select data files from earlier questionnaire administrations. Deferred printouts and lists of result file names can be generated. These lists can be processed using more advanced tools. Generated printouts can be re-directed to the screen or to files (PDF or other formats) for re-use in your own published material. An explanation on how to achieve this is provided further below.

Preparations

If you want to use the integrated printing facilities, please make sure that all *.qdw questionnaire definition files have been loaded which were originally used to build the data files you are going to process. The *.qdw files are used to provide data processing space and to achieve a printout quality identical to what would have been produced by the automatic immediate printout function of AnyQuest for Windows. For example, the printout labels are used instead of the file output labels for questionnaire results. If you are unsure, you can load the most recent versions of all questionnaire definition files which you have available. If you do not have appropriate *.qdw files available, you may prefer to use AnyQuery for Windows which does not rely upon *.qdw files at all.

Please note: If you receive empty printouts, you have most probably not loaded any *.qdw questionnaire definition files matching the data files you are processing.

If not all of your *.anq result files contain data collected with all loaded *.qdw questionnaire definition files, please make sure that the menu option "Printing" - "Printout even for QDWs without Result formulas or Results" is cleared.

Three different versions of the result selection dialog

Since version 3.67, you can use three different versions of the dialog to select questionnaire administration results.

If you want to easily review old results from a given patient whose name and/or date of birth you know, then please use the first or second version.

For more advanced selection tasks, you can use the third version of the dialog.

All three are available via the following entries in the Analysis tools menu:

Select and review results, generate printouts and file lists...

•	By predefined filters on certain joined fields...

This version allows you to search for patient name, patient ID, case ID, date of birth or date of test all in just one search field.

This is the simplest of the available dialogs.

•	By predefined filters on certain individual fields...

This version offers separate search fields for each of these items.

This is probably the most intuitive dialog to use.

•	By freely defineable filters on any fields...

This version offers the most versatile filtering options: here you can freely define the field names to be searched.

These may include other fields from the patient ID set as well as raw data, computed results etc. from the collected questionnaire data.

Selecting *.anq result files

This section describes the process for the third (most versatile) variant of the dialog with freely selectable fields to be searched.

The simpler variants of the dialog work along the same principles of operations, but offer a reduced option set.

The tool operates in the currently selected data file folder. You can use it to build lists of *.anq result files matching a number of criteria you can define.

First, make sure that the currently selected data folder is the one you want to work with. The current folder is displayed in the top left area of the dialog, and you can use the button Data dir to change it, if required.

Second, use the checkboxes to define which sections of *.anq result files you want to have processed for file selection. The fewer sections you check, the faster the resulting processing speed.

Third, construct conditions upon which files shall be selected. There are four condition construction lines, thus you can store up to four conditions at the same time. However, after a condition has been applied, it can be replaced by another condition without any change in the existing list of matching files.

Each valid condition must have an entry in its parameter field and another entry in its value field. For both fields, AnyQuest provides list boxes showing entries which actually occur in the existing result files. These lists are constructed (or re-constructed) from the existing files when either the button with a questionmark located left of the respective list box is pressed, or when an empty listbox is opened by clicking at the arrow-down button located to its right. While list box entries are constructed, you can see which file is currently being processed in the top right area of the dialog.

However, you need not select existing entries from these list boxes, but you can actually type into the provided boxes, e.g. if you know that you want to use group as parameter, and post as INCluded value. Parameters which generally exist in all result files, although some may have empty values, are:

•	AQ license 1

•	group/pid

•	name

•	date of birth

•	computed age

•	date of test

•	start time

•	end time

•	delta time

Only the leading characters entered into a condition definition box need to match the parameter label read from the file to achieve a positive match. This ensures that the above example using group and post will actually identify all files which have the string post somewhere in the group/pid field.

Before the INC condition is tested, both the value defining the condition and the value read from the file are converted to upper case letters. You can also use the = condition to compare strings: to meet this condition, they must be exactly equal. This condition also works when the reference value is an empty string. To search for result files in which the reference parameter has any value at all, you can use the conditions NOT and = together with an empty string as reference value.

Any of the conditions < <= = => > works for numeric values and for dates and times. Reference values for dates must be entered in the format dd.mm.yyyy; and reference values for times must be entered in the format hh:mm or hh:mm:ss.

Forth, execute the actual condition based file selection by pressing one of the buttons with an exclamation mark located right to each condition. If the button below OR is pressed, all files which are not in the list of matching files yet are checked, and if they match the given condition, they are added to the list of matching files. If the button below AND is pressed, all files which are currently in the list of matching files are checked, and only if they match the given condition, they remain in the list of matching files. Conditions can be constructed and their execution buttons pressed as often as you like to select files according to simple or more complicated selection algorithms. After you have pressed both buttons for a single condition, the list of matching files will contain exactly and only all files matching this condition, no matter what it contained before.

The list of matching files can be cleared by pressing the button Clear.

Examples:

•	To select all files: parameter=date, INC, value=., OR

•	To select all files from the pre-test group: parameter=group/pid, INC, value=pre, OR

•	To select all files including QLQ-C30 data: activate processing of the meta info section; parameter=C30V3, INC, value=., OR

•	To select all files with QLQ-C30 Physical function scores above 50 and Social function scores below 30: activate processing of the numeric results section; parameter=C30V3 Physical function, >, value=50, OR, parameter=C30V3 Social function, <, value=30, AND. For this example, it is usefull to press the leftmost button with a questionmark first, and then to chose the parameter for each condition from the respective listbox.

The list of matching files does not only show you the filenames, but also some patient and session identification data.

As soon as you have constructed your list of matching result files, you can click into it, scroll up and down using the cursor control keys, and select or de-select individual entries by pressing [Space] or using the mouse. You can also press one of the provided buttons to change the selection to include All entries, No entry at all, or to Invert the current selection.

Opening previously automatically generated PDF printouts corresponding to selected questionnaire administration (-result files)

If you run a setup that automatically generates and stores PDF printout files after each questionnaire administration, you can open the printout file(s) corresponding to your selected questionnaire administration (or rather: selected result files).

This functionality is included since AnyQuest versions 3.66/3.67.

In order to use it, you must make sure that you have set the folder, where the automatically generated PDF printout files are stored. This may usually be something like z:\anyquin\project\printout. The appropriate path can either be specified via the currently used configuration file *.ini, or you can interactively select it using the button "PDF dir".

AnyQuest supports a variety of ways to generate printjob names for automatically produced printouts. The tool used in your setup to automatically create a PDF printout files (like PDFCreator, FreePDF, or the Adobe Acrobat Distiller etc.) may also support several ways to automatically convert printjob names into filenames. This dialog can only locate and open the automatically created printjob names, if your PDF printout file creation tool will use the printjob name as supplied by AnyQuest without any changes, and if the settings for AnyQuest's printjob name generation are identical during generation of the printjob, and your attempt to open a previously automatically generated PDF printout file.

If these preconditions are met, and the respective files are actually available, it is sufficient to just press one of the buttons "Open qfi", "Open sng" or "Open cum", in order to open the Questionnaire-Filled-In, Single-Result or Cumulative-Result printouts which have been automatically created before. These buttons will not create any additional file, they will just try to open it.

The mechanism should use the default PDF viewer available on the current system through the start command. Thus it may not work for Windows 3.x based systems, but those systems would probably not support the long filenames of the printout result *.pdf files anyway.

If you observe that these buttons do not work on newer systems, then please consult either myself or your local IT support to adjust the configuration of your system (or to provide similar functionality by external means).

Generating printouts from selected result files

As soon as you have selected at least one entry from the list of matching *.anq result files, you can produce printouts. Printouts can be re-directed to the screen or to files (PDF or other formats) for re-use in your own published material. An explanation on how to achieve this is provided further below.

First, please select the appropriate printer using the button "Configure prn".

Afterwards, by pressing the respective buttons, you may:

•	Produce single printouts for all selected result files.

•	Produce cumulative printouts for patient identifications derived from all selected result files.

Writing lists of selected filenames into *.lst files

As soon as you have selected at least one entry from the list of matching result files, you can also write the list of selected result file names into a *.lst list file by pressing the button Wr filelist.

You will be asked to provide a filename for this *.lst list file. By default, it will be written into the current data directory. Currently, it remains your own task to keep track of which *.anq result file names you selected into which *.lst list file, you might use notepad.exe for this purpose and save your notes e.g. in lstinfo.txt in the same data directory.

As soon as you have available at least one *.lst list file in your current data directory, you can:

•	Press the Stats button to open a dialog from which you can generate statistics printouts using a variety of provided analysis functions.

To delete *.lst or *.dvi files, please consult your notes from e.g. lstinfo.txt first, and then use the provided functionality of your operating system. Handle with care!

Re-directing printout to the screen or to files (PDF or other formats) for later re-use and configuration of printjob names

To re-direct printouts to the screen instead of the printer, you may:

•	Print to a tool like FinePrint (available as shareware from Single Track Software, http://www.singletrack.com) which offers an on-screen printing preview facility. Its main purpose is to collate multiple printout pages onto a single sheet of paper, however. If you have obtained an AnyQuest for Windows information CD-ROM, you may find this tool provided on the CD in its shareware version for your convenience.

•	Print to a PostScript printer driver, the printer port of which has been set to FILE:, thus re-directing the printout in PostScript format to a PostScript file, which in turn can be displayed on-screen by other software (look below for further details). In this case, you may also use a tool like NoNag to automatically fill in the printout filename, or try to find out whether the system registry can be changed accordingly.

•	Use a tool like the PDFCreator, or FreePDF (both implicitly use GhostScript) or the Acrobat Distiller, to prepare a setup where printouts are automatically turned into PDF files, and automatically stored in a predefined target directory without any need for user interaction. So you can o automatically generate *.PDF files readable e.g. by Adobe Acrobat Reader in a convenient and comfortable way.

•	Use a tool like the Microsoft Journal Writer to create files in the XPS format with similar functionality. These are less widely readable, but the functionality is included in modern versions of Microsoft Windows.

Please review details regarding printjob name configuration here.

Further processing of printouts from AnyQuest, e.g. for inclusion of tables or graphics in scientific publications

If you want to further process the printout from AnyQuest, e.g. to customize it and re-use it for direct inclusion into your published material, you may:

•	Print to the Universal/Text-only printer driver, the printer port of which has been set to FILE:, thus re-directing the printout in ASCII text format to a file, which in turn can be read by any text editor and other software. The Universal/Text-only printer driver is provided with your MS Windows operating system; please refer to your MS Windows on-line help or manual about how to install a new printer driver.

•	Print to a PDF or PostScript files with one of the tools mentioned above, and then go on using the text and vector format graphics contained in these files. Specifically, the pstools available for many Linux and Unix distributions, and also within e.g. CygWin for Microsoft Windows, include programs like pstopdf, pdftops, pstoedit etc. to convert PostScript and PDF documents e.g. into the *.fig format which can be edited with programs like xfig. More recently, a variety other tools besides the Adobe Acrobat have also become available that can directly manipulate the content of PostScript and PDF documents.

Detailed setup information is included in the eSIRO, KombiDox or HELPS documentations available from the QL-Recorder WWW site.

PostScript is an industry standard page description language. PostScript files can be printed on PostScript printers, or displayed on PostScript displays. They also can be viewed on-screen using tools like Ghostscript (available as shareware or freeware from Aladdin Enterprises, http://www.ghostscript.com) and Ghostview (available as freeware from Ghostgum Software Pty Ltd, and FreePDF (automatically calling GhostScript to convert results into PortableDocumentFormat *.PDF files readable by Adobe Acrobat Reader), or in distributions together with Ghostscript). Ghostscript can also convert a PostScript file into a text file or into a PDF document, or into a variety of other graphic bitmap and vector formats like BMP, TIFF,... which can be processed with common editors. The MS Windows version of Ghostview can directly extract text contents into a text file and copy graphical page contents to the clipboard at any resolution; vector format export is also available. If you have obtained an AnyQuest for Windows information CD-ROM, you may find Ghostscript and Ghostview provided on this CD in their shareware/freeware versions for your convenience. Some other software for graphic editing, layouting or word processing can also import and process PostScript files directly, and an abundance of other tools is available to manipulate PostScript content, e.g. to re-arrange or re-position it on printed pages.

I have produced simple scripts (available upon request or maybe from my WWW site already) which after a questionnaire session has been completed, automatically upload PostScript printout files from AnyQuest for Windows directly onto a Linux server, where they are queued, and displayed on-screen one after another, to obtain a paperless printer replacement. A similar thing can easily be done in a local environment.

• Data storage, export, printing, statistics...

• Statistics for lists of selected files

• Printer setup

• Printing simple cumulative statistics

• Exporting the results to mathematical, statistical or database applications

• Marc-André Sigle's AnyQuery for Windows

• Detailed description of the output file format of AnyQuest for Windows *.anq files

• Hints for writing import routines into third party applications

• Communication with external software


Statistical analysis of selected questionnaire administration results

This dialog provides tools to generate printouts, a tool to generate export files, and several basic statistical analysis tools. All included tools process previously generated lists of selected result file names. Generated printouts can be re-directed to the screen or to files (PDF or other formats)for re-use in your own published material. An explanation on how to achieve this is provided further below.

Preparations

Please make sure that all *.qdw questionnaire definition files have been loaded which were originally used to build the data files you are going to process. The *.qdw files are used to provide data processing space and to achieve a printout quality identical to what would have been produced by the automatic immediate printout function of AnyQuest for Windows. For example, the printout labels are used instead of the file output labels for questionnaire results. If you are unsure, you can load the most recent versions of all questionnaire definition files which you have available. If you do not have appropriate *.qdw files available, you may prefer to use AnyQuery for Windows which does not rely upon *.qdw files at all.

Please note: If you receive empty printouts, you have most probably not loaded any *.qdw questionnaire definition files matching the data files you are processing.

If not all of your *.anq result files contain data collected with all loaded *.qdw questionnaire definition files, please make sure that the menu option "Printing" - "Printout even for QDWs without Result formulas or Results" is cleared.

General operation

The tool operates in the currently selected data file folder.

First, select all *.lst files you want to process in the list box. *.lst list files contain grouped filenames from individual questionnaire administrations and can be prepared in a comfortable way using this dialog.

The list of available *.lst list files is initially generated as soon as the dialog appears. You can have it rebuilt by pressing the ? button. To select one or multiple entries, you can click into the list, scroll up and down using the cursor control keys, and select or de-select individual entries by pressing [Space] or using the mouse. You can also press one of the provided buttons to change the selection to include All entries, No entry at all, or to Invert the current selection.

Second, press one of the buttons to use the desired analysis tool.

Description of available processing and analysis tools

Single printouts for each *.anq file (Cave!)

Generates a single printout for each *.anq result file referenced from any of the selected *.lst files.

The tool generates one page per referenced *.anq file and per *.qdw questionnaire definition file if it is currently loaded and was used in the questionnaire administration and - if the appropriate configuration option is set - has at least one valid result.

Please note: This tool can create a huge number of printed pages or dialogs asking for the printout redirection file name. Handle with care!

The tool has an options button labeled ..., which you can use to configure all single printout parameters.

Cumulative printouts for each *.anq file (Cave!)

Generates a cumulative printout for each patient identification found in any *.anq result file referenced from any of the selected *.lst files.

The tool generates one page per referenced *.anq file and per *.qdw questionnaire definition file if it is currently loaded and was used in the questionnaire administration and - if the appropriate configuration option is set - has at least one valid result.

The tool has an options button labeled ..., which you can use to configure all cumulative printout parameters. Some of the options configured there do also apply to the course-over-time-plot.

Please note: This tool can create a huge number of printed pages or dialogs asking for the printout redirection file name. Handle with care!

Cumulative printouts combining all *.anq files

Generates a cumulative printout, combining data found in any *.anq result file referenced from any of the selected *.lst files, ignoring the group and patient identification data from these files. This function can be used to get a cumulative printout of sessions filled in by one patient using different IDs.

The tool generates one page per processed *.lst file and per *.qdw questionnaire definition file if it is currently loaded and was used in the questionnaire administration and - if the appropriate configuration option is set - has at least one valid result.

The tool shares its configurable option with the general cumulative printout tool.

Export file

For each selected *.lst list file, generates one data export file named *.dvi including data from all *.anq result files referenced by this particular *.lst list file. The filename of the *.dvi data export file is chosen to match the respective *.lst list file automatically. The export options set in the "File" - "Generate data export file..." dialog are used.

The tool has an options button labeled ..., which you can use to configure the format of the produced data export file and which sections from available *.anq result files are exported.

Basic statistics table

Generates a basic statistic analysis of data from all *.anq result files referenced from each of the selected *.lst files. In tabular form, this shows the questionnaire, *.lst file, and for each result dimension of the questionnaire: number of measurements, minimal observed value, first quartile, median, third quartile, maximal observed value, arithmetic mean, variance, standard deviation, and standard error of the mean.

Please note that arithmetic mean, standard deviation and standard error of the mean make some assumptions regarding the nature of your data which are usually not formally met by data collected with quality of life questionnaires. Following a conservative approach, you might want to restrict yourself to looking at the simpler measures only.

The tool generates one page per processed *.lst file and per *.qdw questionnaire definition file if it is currently loaded and was used in the questionnaire administration and - if the appropriate configuration option is set - has at least one valid result.

The tool has an options button labeled ..., which you can use to configure which parameters are actually included in the printed table.

Box and whiskers plot

Generates a box-and-whiskers-plot for data from all *.anq result files referenced from each of the selected *.lst files. This shows the questionnaire, *.lst file, and for each result dimension of the questionnaire the number of measurements, and in graphic form, the minimal observed value, first quartile, median, third quartile, maximal observed value.

The tool generates one page per processed *.lst file and per *.qdw questionnaire definition file if it is currently loaded and was used in the questionnaire administration and - if the appropriate configuration option is set - has at least one valid result.

The tool has an options button labeled ..., which you can use to configure which elements are actually included in the printed table.

Course over time plot

Generates a course-over-time-plot for data from all *.anq result files referenced from each of the selected *.lst files. This shows the questionnaire, *.lst file, and for each result dimension of the questionnaire a graphic representation of the data collected over time.

In the resulting graph, the tool shows how often a certain result value was collected at a certain point in time by colouring the area belonging to the respective point in time and to the respective result value using a certain level of blackness (a "bin"). The more often a result value appears at the given point in time (collection of similar results within a given bin), the darker the resulting colour of the respective area in the graph (colour coding of the result probability by a level of blackness) will be.

The resulting plot can also be described as a colour coded, two-dimensional histogram derived from the available data.

The x-axis serves as time scale, with the oldest included measurement plotted at the leftmost area, and the youngest included measurement plotted at the rightmost area. The tool only evaluates the date of test for this purpose and ignores the exact time of measurement within the day. The dates and times of test of included measurements are printed at the top of the page, and optionally, below each graph.

The tool has an options button labeled [...]. Here you can configure how many recent measurements can be evaluated at maximum for the generation of the plot, the resolution of the resulting plot in both x- and y- direction, the approach used to calculate the colors in the plots, the time range used to generate the display etc.

The nnumber of tests to be included into the evaluation will typically be set to a number above the number of collected results. However, you can reduce this limit in order to base the evaluation upon a number of more recent results only.

The resolution settings control, how many different points in time the tool handles separately, and how many different result values the tool handles separately for each graph. You can set resolutions between 1 and 32767, independently for each axis. If the configured x-axis resolution exceeds the number of different days in your data, another option controls whether the x-axis resolution matching the number of different days is used instead. Note that specifying too high resolutions can make the displayed bins become invisibly fine on your output. The actually achievable resolution in y direction is limited by the actual resolution of your questionnaire results - which is usually rather low, except for LASA or VAS scales.

If you set both resolution controls to rather high values (e.g. 500), only a few number of measurements will cluster (those that delivered identical results on the same day), and thus you will get fine, possibly uniformly dark dots.If on the other hand, you set both resolution controls to rather low values, several measurements delivering similar result values at similar points in time are very probable to fall together within the pre-set resolution, and thus, you will probably receive a graph with a number of coarse fields in different grey levels. It is specifically possible to set either the x or the y resolution to 1, and the other resolution to a rather high setting (e.g. 100). This will generate a fine rendering of the distribution of all results over the whole range of result values, or days of test, respectively.

If you use very high bin resolutions, resulting coloured areas of the size of a single pixel may not be visible any more on high resolution printers. This effect may depend upon the printout quality setting of the printer driver. You can also use a tool like Ghostscript (see below) which effectively allows you to vary the rastering device resolution and other properties.

You should probably try out several resolution settings to find out which setting is appropriate for presentation of your data. Depending upon the resolution setting, you may either get a complete and detailed overview of the data collection process within a single glance, or you may get a highly integrated graph showing you the tendency of changes within your collected data.

It is possible to have the output colour range calculated independently for each displayed graph (or questionnaire dimension): In this case, typically, each graph will include the whole range from white to black coloured boxes. This maximizes information transferred from each individual graph, but similar colour levels from different graphs may encode different numbers. Alternatively, it is possible to have the output colour range calculated to fit the bin containing the highest number of measurements of all bins from the same questionnaire. This may lead to some of the graphs not covering the whole available color range, but same colors from different graphs (of the same questionnaire, on the same page) do now mean the same number. Third, it is possible to define user specified parameters for an offset and a contrast value controlling the mapping of the number of entries in bins to color.

With regard to the date of the display, either limit can either be automatically computed from analysed data, or set manually. This would be useful e.g. if you want to directly compare recruitment rates from different sources over a predefined period of time, e.g. one complete year.

If you use the "select measurements" dialog to select the results of an individual patient, you can use the course over time plot for this single patient as well. In comparison to the simple cumulative printout, the course over time plot aligns results on the x-axis proportional to the date of test, rather than simply to the number of measurement.

The tool can process up to 16382 result files. It can produce 255 different grey levels, and it can handle up to 16383 different bins containing more than zero measurements at the same time within each result dimension. The coding of probabilities into grey levels is generated for each dimension independently from all other dimensions.

The more general options of the the course-over-time-plot tool are shared with the cumulative printout tool and are actually controlled by the cumulative printout option dialog. This means, that you can e.g. any static reference values, or the automatically computed interquartile range, or the average result values, generated as background information behind the course over time plots for all dimensions.

The course over time plot generation also honours any information provided in *.pdc files, so any advanced layout control (like paper orientation, header and footer overrides, division into sections, labeling of sections, alignment of individual graphs) prepared for the standard patient centered cumulative printout can be re-used.

The tool generates one page per processed *.lst file and per *.qdw questionnaire definition file if it is currently loaded and was used in the questionnaire administration and - if the appropriate configuration option is set - has at least one valid result.

Re-directing printout to the screen or to files (PDF or other formats) for later re-use

To re-direct printouts to the screen instead of the printer, you may:

•	Print to a tool like FinePrint (available as shareware from Single Track Software, http://www.singletrack.com) which offers an on-screen printing preview facility. Its main purpose is to collate multiple printout pages onto a single sheet of paper, however. If you have obtained an AnyQuest for Windows information CD-ROM, you may find this tool provided on the CD in its shareware version for your convenience.

•	Print to a PostScript printer driver, the printer port of which has been set to FILE:, thus re-directing the printout in PostScript format to a PostScript file, which in turn can be displayed on-screen by other software (look below for further details). In this case, you may also use a tool like NoNag to automatically fill in the printout filename, or try to find out whether the system registry can be changed accordingly.

•	Use GhostScript and FreePDF together, to simplify setup for the above, and to automatically generating *.PDF files readable e.g. by Adobe Acrobat Reader in a convenient and comfortable way (very detailed setup information is included in the eSIRO documentation available from the QL-Recorder WWW site).

If you want to further process the printout from AnyQuest, e.g. to customize it and re-use it for direct inclusion into your published material, you may:

•	Print to the Universal/Text-only printer driver, the printer port of which has been set to FILE:, thus re-directing the printout in ASCII text format to a file, which in turn can be read by any text editor and other software. The Universal/Text-only printer driver is provided with your MS Windows operating system; please refer to your MS Windows on-line help or manual about how to install a new printer driver.

•	Print to a PostScript printer driver, the printer port of which has been set to FILE:, thus re-directing the printout in PostScript format to a PostScript file, A variety of PostScript printer drivers are provided with your MS Windows operating system; please refer to your MS Windows on-line help or manual about how to install a new printer driver. Currently, I'm using the driver for the QME Magicolour plus Level 2 to obtain 600 dpi colour PostScript files, or the driver for the HP LaserJet III with PostScript cartridge to obtain black and white 300 dpi PostScript files.

PostScript is an industry standard page description language. PostScript files can be printed on PostScript printers, or displayed on PostScript displays. They also can be viewed on-screen using tools like Ghostscript (available as shareware or freeware from Aladdin Enterprises, http://www.ghostscript.com) and Ghostview (available as freeware from Ghostgum Software Pty Ltd, or in distributions together with Ghostscript). Ghostscript can also convert a PostScript file into a text file or into a PDF document, or into a variety of other graphic bitmap and vector formats like BMP, TIFF,... which can be processed with common editors. The MS Windows version of Ghostview can directly extract text contents into a text file and copy graphical page contents to the clipboard at any resolution; vector format export is also available. If you have obtained an AnyQuest for Windows information CD-ROM, you may find Ghostscript and Ghostview provided on this CD in their shareware/freeware versions for your convenience. Some other software for graphic editing, layouting or word processing can also import and process PostScript files directly, and an abundance of other tools is available to manipulate PostScript content, e.g. to re-arrange or re-position it on printed pages.

I have produced simple scripts (available upon request or maybe from my WWW site already) which after a questionnaire session has been completed, automatically upload PostScript printout files from AnyQuest for Windows directly onto a Linux server, where they are queued, and displayed on-screen one after another, to obtain a paperless printer replacement. A similar thing can easily be done in a local environment.

• Data storage, export, printing, statistics...

• Selecting results from earlier sessions, generating printouts and lists

• Printer setup

• Printing simple cumulative statistics

• Exporting the results to mathematical, statistical or database applications

• Marc-André Sigle's AnyQuery for Windows

• Detailed description of the output file format of AnyQuest for Windows *.anq files

• Hints for writing import routines into third party applications

• Communication with external software


Password check

This dialog asks for a password before you can continue. It protects the functionality to access previously recorded data and to generate printouts or statistical analysis.

How to use the dialog

If you want to enter a password, just write it in the upper text input field.

If you want to change a password, additionally write a new password in the lower text input field.

To continue, press [Enter] or click on the OK button.

The default password is anq. You are expected to change this password before allowing your patients to use the system in an unsupervised way in order to protect other patients' data. Alternatively, you can prepare a configuration for your patients where the Setup button in the "AnyQuest Navigation" window has been disabled or which runs in the unattended kiosk mode.

The password is stored in a dedicated file in the AnyQuest for Windows config directory. Only one password is used for all AnyQuest for Windows configurations using the same directory.

• Selecting results from earlier sessions, generating printouts and lists

• Printing simple cumulative statistics


Fast-Input-Form for paper questionnaires

Delayed processing of paper questionnaires

Fast-Input-Form mode, e.g. for delayed processing and scoring of paper questionnaires

General information

Sometimes it may not be feasible to give an electronic questionnaire to a patient that she will fill in directly at the computer.

For example, you might not have a computer available (yet), or you might conduct a validation study that compares results collected via paper forms with results directly collected with electronic questionnaires.

You may still be able to use AnyQuest for Windows to process your paper forms:This provides you with recorded data in the same format as if the electronic questionnaire would have been used, and it also provides computed test results, printout generation, data analysis and data export facilities.

Naturally, you can score paper forms by simply transferring the patient's answers from the paper questionnaire into AnyQuest's electronic questionnaire. However, this may feel slow because you need to wait for each succeeding question to appear.

As better alternative, AnyQuest offers a Fast-Input-Form mode of operation. Here, all questions and answer fields of a questionnaire (or at least: as many as will fit onto one screen) appear in abbreviated form in a single dialog. So you can score paper forms faster than using the standard question-by-question display mode.

The Fast-Input-Form mode may also be an effective tool to be used by basically trained people for some data recording tasks: e.g. when you want to score an OSCE (Objective Standardized Clinical Examination) conveniently, making sure that no answer for any question is forgotten, and making sure that recorded data are available for statistical analysis or other processing immediately after the examination.

In this scenario, it is helpful to see all questions on a single screen or on a small number of screens at the same time, and to be able to check of any item whenever the observed student successfully performs the necessary activity.

AnyQuest's Fast-Input-Form mode lets you record answers fast, yet conveniently in random order, and just alike the standard mode, for documentation or immediate feedback, it can produce result printouts as PDF, MS Journal Writer file, or on paper.

Availability and limitations

Fast-Input-Form mode was first introduced and specifically programmed for the eSIRO questionnaire. A more generic version was introduced in version 3.16; version 3.26 allows Fast-Input-Form mode for the eSIRO, eSF-36, eQLQ-C30 and FLZMseq Quality-of-Life questionnaires; and the eOSCE scoring tool.

In version 3.48, support was added for questionnaire definition files with adaptations of the eSF-12, eEQ/eEQ2/eEQ5D, eEpworth, eHADS, eMLHFQ, eTTM, eBBPatSat, eOCT, eMFI20, eHN35, eBR23, and eLC13 (the latter only preliminarily for development use).

Technically, all questionnaires that include only questions of "multiple-answer-fields - single-answer-required" type are supported. They are automatically translated into Fast-Input-Form layout.

I will probably extend the Fast-Input-Form mode dialog form layouter capabilities over time to support other question types, and at some time remove the restriction that limits it to the named questionnaire definition files. If you need this mode for your questionnaire definition file, please contact me and I'll open it for your questionnaire as well.

To switch an AnyQuest configuration over to Fast-Input-Form mode, please add the term: ShowQnrFastInputForm=True in the [Options] section of the respective configuration file.

Note that currently, conditional branching, conditionally displayed questions, morphing questionnaires, images and sounds and other advanced features of the AnyQuest's standard display mode are not supported in the Fast-Input-Form mode.

The Fast-Input-Form will require a screen of at least 1024x768 pixels resolution, and the size and position of the automatically generated dialog window are currently (as of version 3.26) fixed and not configurable at all.

Specific features

The first field in the Fast-Input-Form asks you to manually enter the date of test. This is the date when the paper form was filled in - not the date when you transferred data into AnyQuest. However, this field is currently pre-set with the current date, and initially highlighted, so if you do not use the Tab-key or the mouse to advance to another field, most characters you type will automatically replace the pre-set value by what you enter.

There is currently no field to record the time and duration of the test in this mode. This information will typically not be available when paper forms are used, and the Fast-Input-Form was optimized to show only the most important fields. Thus, the fields start time: and end time: will remain empty in the produced result files. The field delta time: will carry the value 00:00:00 and a special notice.

Additional fields are available to record the patient's (or examinee's) ID-number (or alphanumeric code), date of birth, first name, last name, and physician number. The combination of patient and physician number may typically be used in multicenter setups, where patient numbers are local to the office (physician) that the patient visits, and the combination of patient and physician number makes the ID unique (as long as patients do not visit multiple physicians). You need to take care whether a physician number actually identifies a physician within an office, or an office with all of its physicians.

If you are going to process incoming paper questionnaires from multiple offices in a single place, you may be better off recording a single combined OOOO-PPPP office-and-patient identifier. This ensures that every patient from any office has one unique ID in the patient-ID field, and this in turn lets you use patient-ID based patient recognition and cumulative result production etc.

Additional fields are available to record the rater, assessment, group, subgroup, cycle, subcycle as well as the patient's sex and ethnicity.

The actual availability (and necessity to fill in) any of these additional fields is controlled via the settings in the "Navigation" - "Patient identification options to ask for" menu, which are stored with each individual configuration file.

The date of test (DoT) and date of birth (DoB) input fields honour the setting of the DateFormatDialog variable in the [Options] section of the respective configuration file. If you enter a date in a shortened but at least any reliably interpretable form (like: "010203" or "1.2.3"), it will be reformatted, depending upon the setting of that option, to either "01.02.1903" or "1901-02-03" and displayed as soon as you press the Enter key. If you enter a string into a date input field which cannot be interpreted, an error message will appear, which will denote the problematic portion of the supplied term as specifically as possible.

If you have the patient-ID-recognition feature enabled, you would typically enter/accept the date of test, and afterwards enter the PID in the respective field, and press the Enter key once. If data for the same PID have been recorded before, AnyQuest will fill in all other details of this patient (name, date of birth etc.) from the previous recording.

Since version 3.25, this also handles multiple first and last names correctly. Before version 3.25, only the name field (with first and last names in one line) would be read from previous result files, and would be split at the first space into first name and last name. Versions before 3.25 would also replace spaces within the first name or last name by underscores, producing first_name and last_name, to protect manually entered multiple_first_names from being split, and partially drewn into the wrong field. This workaround has now been dropped.

The patient-ID-recognition is available in standard or index based mode. The latter reduces file-system or network load significantly, but relies on some properties of the underlying file-system, operating-system, or file-server.

Since version 3.24, interspersed Infoscreens will be translated into section separators, which is demonstrated in the eOSCE example GOEDMDE.QDW.

To enter data for scoring a paper form as quickly as possible (if you do not happen to have a pen-computer), you can also select the answer for most questions by a single direct keystroke. AnyQuest selects the next answer of the question whose answers are currently highlighted, which matches your keystroke, and automatically advances the cursor to the answers of the next question.

Versions before 3.48 only recognized the keys 0..9, which would select an answer with a value of exactly the corresponding integer number and no decimals. Since version 3.48, the keys 0..9, A..Z, ÄÖÜß are recognized and select an answer field according to the following staged matching algorithm:

1. 	match with the first character of the value of an answer field,

2. 	match with the first character of the label of an answer field,

3. 	match with any character of the label of an answer field.

This should be sufficient to select most answers quickly and relatively specifically by keyboard input, and therefore enter all data for scoring a paper questionnaire very fast. Where this does not suffice, the TAB and cursor keys or the mouse can still be used.