+ Reply to Thread
Results 1 to 5 of 5

Thread: Workarounds and tips for the current software release (3.1.4918)

  1. #1

    Workarounds and tips for the current software release (3.1.4918)

    This is an update for the new software release version 3.1.4918. Some of the workarounds/tips from the previous thread are still valid so we have re-posted them here. We have also added some new ones. So if you are using version 3.1.418 we recommend that you read this thread - you will find it useful!

    Displaying response code and description in label

    Surveybe version 3.1 allows you to dynamically populate labels with the description and/or the code of a response list.

    You can use the following syntax if you want to populate a label with the description of a response option found on the base table: [current.ResponseListVariable]

    To display the code of a response option please use the following syntax: [Select ResponseListVariable from Basetable]

  2. #2
    Using dynamic text in question or label to refer to table identifier

    It has emerged that in the current Surveybe software version 3.1.4918, the syntax [TableIdentifier] cannot be used in newly created question or label to display the item description in a roster that has been populated from an item list.This has been fixed in the main development version of the Designer and will be available to clients in a future release.

    Fortunately, there is a simple work around to this, which is to use the 'current.' Prefix when you create or change a question or label containing dynamic text referring to a table identifier. If your questionnaire was build on previous software the [TableIdentifier] syntax will continue to work as the issue is not with the syntax, but with the way it is being validated in the Designer.

    After the bug fix is released any dynamic text containing [current.TableIdentifier] will continue to work as expected, so you won't need to change it back.

    Please note that this bug does not affect the use of either the [QuestionVariableName] or [current.QuestionVariableName] syntaxes in dynamic Text

  3. #3
    Top Tip: Renaming Interviews

    A personal experience prompted me to post this:

    Changing the windows filename of an interview file can be tempting for interviews who have created an interview with the wrong identifiers or their supervisor. This will, at best, create difficulty reconciling the .json imported against the data held in and exported from surveybe.

    At worst, if the interviews are subsequently updated using the implementer, the uploaded and subsequently exported data can be corrupted. Technical support input is then required to remedy this situation.

    According to surveybe changes to prevent this damage arising are currently under development, in the meantime please impress on all project staff the importance of not changing the filenames.

  4. #4
    NOT A WORKAROUND BUT A STRONG TIP: Cloning Questionnaires

    Version 3.1 allows the questionnaire designer to 'clone' an interview. This is 'powerful' and exciting feature of the software which can cause a variety of unintended issues if not used with great care.

    It allows data from two different questionnaires to be exported from either of those questionnaires. There are no constraints currently implemented in the software to ensure that the two cloned questionnaire remain compatible with each other. A rigid development process is required to track and control cloned questionnaires in your work.

    While this feature remains in its early stages of development we advise that you do not use it without reference to your surveybe contact.
    If the 'Rename Questionnaire to import' dialogue opens when you are importing a questionnaire into the designer you are advised to rename the imported questionnaire and un-tick the 'clone' tick-box.

  5. #5
    Screen Enablements

    It has become apparent that there is an enablement rule in version 3.1 of the surveybe software which prevents screens with only a label on them from being disabled. This rule is intended to prevent 'help' screens from being disabled by skips. This rule effect should be over be overridden by the other rules introduced with screen enablement functionality in 3.1. In the current version this is not happening.

    Designers who wish to disable a screen with only a label can do this by:
    • Creating a screen enablement rule as described in the 3.1 manual
    • Creating a hidden question on the screen with the same enablement rule as the screen

+ Reply to Thread

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts