Common Errors/en

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 (but the list will grow over time).

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.

Editor Errors

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. You can also insert a cast step (either checking or non-checking) between the two pins.

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.

Execution Errors in Compound Actions

See also " Errors during Execution".

Step not Executed in a Loop / Loop Executed only Once

A common error when a diagram's steps are executed in a loop is that the input value of a step is consumed, and no other input value is present when the loop is executed the second time. Thus, there is no input value for the second iteration and the action will not execute again.

For this, change the pin's behavior to "Parameter".

Step is Triggered Again and Again (Machine Gun)

Be careful to not make it both "Non-Consuming" AND "Triggering": the step may behave like a machine gun and start to constantly fire.

The "machine gun" behavior will appear if all triggering pins of the step are non-consuming. If there is any other consuming triggering pin (enable- or data input), this error will not happen.

The builtin lint-checker detects most of those and will give you a warning when you Accept the diagram.

Self-Retriggering does not Work

Another similar situation may arise when a step is to be re-triggered by one of its own data output pins.

If the output is unbuffered (i.e. set to send its value immediately), then the new trigger will arrive while the step is still executing, and ignore the re-trigger.

Thus, this only works if the output pin is buffered, and thus writes its values after the step has finished. An alternative and better solution is to re-trigger the step from its "Enable-Output" pin (a non-data pin at the bottom). This will fire AFTER the step has finished and therefore will retriever the step.

In the screenshot, the first step will not correctly re-trigger itself (it has an unbuffered output), whereas the second works as expected (it uses the Enable-Output to re-trigger itself).

Execution Errors in Elementary Actions: DLL-Call

See also " Errors during Execution".

Cannot find or load dll/module: "<dllName>"

Happens when a DLL-action block (not a bridged C action) 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 ".expeccoSettings" file.

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 (ldd or similar tools)

Missing function: "<functionName>" in shared library: "<dllName>"

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).

Execution Errors in Elementary Actions: CBridge

Failed to load Shared Library

This issue refers to bridged C actions - not DLL actions.

Ensure that the shared libraries are found. Under Unix/Linux, you may want to set the LD_LIBRARY_PATH shell variable. A best practice is to set it before expecco is started, usually in your loginrc file. As alternative, set it in "Extras"- "Settings" - "Execution" - "External Script Interpreters".

You can also take one of the existing compile scripts in the bridge folder, copy it to a new name, and add your shared library to the link command at the end. Then specify this compile script in your expecco settings. Consult the compiler-toolchain's manual pages on how shared libraries are searched and resolved; typically there is a command line argument for the linker (such as -L or -linkPath) which tells the executable where libraries are to be found.

If all fails, copy or symlink your shared library to the cBridge folder ("installDir/packages/exept/expecco/bridgeFramework/cBridge").

---

Copyright © 2014-2024 eXept Software AG