This document lists the most common error situations and provides advice on how to fix it. It is incomplete and does not cover all possible errors.
- 1 Project Load/Save Errors
- 2 Editor Errors
- 3 Execution Errors
Project Load/Save Errors
You are about to save the suite under another name...
This warning and confirmation dialog is shown when you save a suite under another name; it tries to prevent a common error situation, in which two test suites or import libraries have the same functionID (unique identifier) and are therefore considered to be different versions of the same suite, although they should really be treated as two different suites.
Be reminded, that expecco associates a so called "function identifier" with every suite or library, and uses this to check for newer versions when (re-) importing. This allows for expecco to find matching elements and automatically find and replace newer versions during the reimport operation (independent, especially of an action's name, number of pins, types etc.).
However, if you actually intent to create a new suite or library, but want to use the current one to start with (i.e. as template), the above interpretation should be prevented and the suite should be given a new functionID first.
Datatypes (<type1> -> <type2>) are not compatible - press CTRL to force
You tried to connect two pins, but the datatypes are not compatible. In some situations, expecco's interpretation of "being compatible" is too strict, and you may want to override this and force a connection.
This happens, if an output pin's datatype is more general than the input pin's type; for example, if you attempt to connect an output pin with a "Number"-type to an input pin typed as "Integer". Here, expecco assumes that the output value might be a Float, Rational or other non-integral number, which may cause trouble in the receiving action. However, you as a developer often know or can assert, that the actual output values will always be integral.
Usually, this happens when an action's output pins have been specified too general, and a good fix would be to change the type to either a more specific concrete type, or to a template type. A typical beginner's mistake is to define outputs as "Any" or "Object"; both will certainly lead to this kind of trouble later, when those actions are to be reused.
Cannot find or load dll/module: "<dllName>"
Happens when a DLL-action block could not load its underlying dll.
Go to the "Extras" - "Settings" - "Project Management" - "DLL Mappings" dialog and make sure that the folder in which your dll is located is listed in the DLL-Path list. If not, enter it, click on the "Add" button and save your settings.
Notice that the DLL-path setting is NOT stored
inside the test suite, but instead a per-user/per machine setting
which is stored in your "
If the error is persistent, ensure that:
- the dll is readable (i.e. check the access rights)
- the dll is for the same OS+CPU architecture (especially check for 32bit vs. 64bit compatibility; also be reminded that windows dlls are not compatible with linux and vice versa).
- any other dlls required by the dll (i.e. second level dependencies) are also found along you path (windows) or
LD_LIBRARY_PATH(unix/linux). Check this using an appropriate command line tool (
lddor similar tools)
A function (as specified in a DLL call action) was not found in the DLL (although a DLL by that name was found and has been loaded). Check for a mistyped function name in your DLL-call action, correct export definitions (windows ".def" files), up-to-date library (recompile/relink) and wrong path settings (loading the wrong dll).