Release 9.7.20314.11438

eVo 9.7.20314.11438 is a maintenance release, and should only be installed if the published fix is required.

Implements fix for error in ScanbarCode() module

Do not work on configuration file outside of Dashboard

[su_note note_color=”#ec2310″ text_color=”#f8f4f4″]Working on {evo} configuration files outside of Dashboard can cause serious problems.[/su_note]

Facilities are provided within the Dashboard application to work with various configuration items such as Form Types, Server Tasks, etc, and these include the ability to copy them within the same machine to provide a duplicate, or to copy from one machine to another in case you need to distribute the file (which is normally done by export/import rather than copy/paste). These built-in facilities in Dashboard are the only approved way in which to carry out those actions.

Copying, moving or deleting files in the configuration folder by other means such as using Windows Explorer or a command prompt is absolutely not approved and is extremely likely to cause problems. When you use the export/import or copy/paste/clone/delete facilities in Dashboard, a number of special processes are automatically carried out in relation to security, linking between various configuration files, identifying the machine on which a file was created, tracking which files exist, and so on. If you simply move, copy or delete a file in the configuration folder using a normal file manager or command prompt, none of those special processes will be carried out and there is a very high probability that either immediately or at some point later this will cause serious problems, up to and including loss of data and/or the entire installation becoming unusable.

Also, a file being deleted or copied outside of Dashboard may actually be in use by the Configuration Manager service at the time, so the attempted action may fail altogether anyway, or in the case of a file copy the copied file may not be intact (this won’t happen when you use the facilities within Dashboard as they make sure the file isn’t in use before doing anything like a copy or delete).

Type 4 printer drivers are recommended when printing from eVo

[su_note note_color=”#acf596″]When printing directly from eVo, if possible a Type 4 printer driver should be used.[/su_note]

This is because eVo uses Type 4 (XPS) printing, so if a matching printer driver is used then no format conversion is required and that avoids any potential problems and saves time. It is possible to print to a Type 3 (GDI/EMF) printer driver directly from eVo, and Windows will automatically convert the output into GDI format so this will normally work, but it will take slightly longer to print due to the time taken for the conversion. Also on rare occasions it has been found that the conversion routine (which is built into the Windows printing system) can fail to work correctly, resulting in corrupted output being sent to the printer. This may prevent the print job being printed at all, possibly with an error being reported, or it may be printed but with the content not as intended. Switching to a Type 4 driver avoids this problem.

To determine the type of an installed driver, go to “Devices and Printers” in Control Panel, select any printer, then click on “Print server properties”. In the dialog which pops up, select the “Drivers” tab and all the installed printer drivers are listed along with the type of each one. Unfortunately, many printer driver downloads and installers don’t seem to mention which type of driver they going to install, so you may need to install a driver first in order to then look in that dialogue and find out which type it was. A driver is likely to be Type 3 if there is any mention of either that type, or GDI, or EMF. It’s likely to be Type 4 if there is any mention of XPS, WPF, or print tickets.

A Form Type isn’t found or doesn’t appear to behave as the latest edited version should

[su_note note_color=”#acf596″]This topic applies to release 6.2 onwards.[/su_note]
You may encounter either of these problems:

  1. A Server Task executes a Form Type but execution fails with a “Form Type Not Found” message being added to the event log.
  2. You edit a Form Type and save the changes, but when the Form Type is next executed by a Server Task, the changes you made don’t seem to have any effect and the Form Type goes on behaving as it did before the edit.

Both of these can have the same cause, which is related to preparing the scripts in a Form Type for execution, or “linking” them (see “Scripting internals” in the help for more details of how the scripts in a Form Type are linked). Although it’s rare, it is possible to introduce an error which only arises at link time, for example by having an Include Script which contains a function definition, and including that script into a Form Type somewhere other than the Globals script, for example in the Prep script. Because functions can only be defined in the Globals script, this causes an error when the scripts are linked and the linker finds that it now has a function definition in the Prep script, and this makes the linking process fail because the Form Type is not valid to be executed.

The system can’t prevent you doing this because the Form Type and the Include Script are separate entities and you can change either without the other, so for example there may not be a function in the Include Script at the time when you edit and test the Form Type using that Include Script, but you later edit the Include Script and add the function. So the Form Type was valid when you last tested it, but suddenly it isn’t any more because as soon as the change to the Include Script reaches the Task Despatcher’s cache it will relink the Form Type with the new version of the script and that will cause the error.

However Dashboard can’t warn you about this when you edit the Include Script either because it could be used in several different Form Types in different places, so it may still be valid in those Form Types where you used it in the Globals script, but not in other Form Types where you placed it in other scripts, so whether it’s valid depends on where and how you use it. It could take a prohibitively long time to scan every Form Type on your system to see whether it uses this Include Script, then check whether it will still be valid after the update, so the system doesn’t do that. This means the bottom line is that it’s up to you to make sure that each combination of Include Script and Form Type will be valid after any edit you do, which is particularly important if you have many Form Types using the same Include Script and you may have forgotten that one of them uses it in a different place to all the rest.

Why are there two different problems I might see for the same error?

If you do introduce this sort of error, you will hit either problem 1 or problem 2 above depending on when you did it. If the problem is already there when the Task Despatcher service starts up, then the Form Type that fails to relink will never be added to the service’s configuration cache in the first place, which means that any task which tries to execute it will cause a “Form Type Not Found” error in the event log.

On the other hand, if everything was ok to start with and the Form Type was working, then it will have been added to the Task Despatcher service’s cache at startup. If you then edited either the Form Type or the Include Script and introduced the error while the service was already running, the new version of the Form Type won’t make it into the cache, but the old copy that was already there may remain in the cache instead of being replaced because the error will abort that replacement process (whether the old version gets removed depends on exactly where the error arises, so sometimes the Form Type may be missing afterwards, other times not). If the old Form Type does remain in the cache, a Server Task which uses the Form Type would execute successfully but the version of the Form Type that gets executed would be the one from before your changes, so you may notice that your changes don’t seem to have had any effect.

Regardless of whether it’s scenario 1 or 2, there would always be a “Failed to relink Form Type” error in the event log, either when the Task Despatcher service’s cache is being populated at startup, or just after you edited the Form Type / Include Script. So if you think there may be a problem it’s always worth searching the event log for, say the last half day (or further back if the service has been running longer), looking for “relink” in the “Details” field to see if the failure is there.

Bear in mind that if the Form Type is missing from the cache you’ll get a “Form Type Not Found” error in the event log every time a task tries to execute it, so there may be many of those messages but they don’t absolutely confirm why the Form Type is missing as there could be other reasons. The relink was only done once when the Form Type was being added to the cache or updated, so you won’t see a “Failed to relink Form Type” error each time a task tries to execute it. That’s why you need to search back to the time when that message would have been logged.

Another approach is to open the suspect Form Type in Dashboard and do a preview run to see if any errors come up. If the linking fails, it will appear as a pop-up error message so you won’t be in any doubt. Bear in mind though that if you’ve edited an Include Script recently you may need to use the “Refresh Caches” button in the Form Type ribbon to make sure that you have up to date copies of all the Include Scripts before you do the preview run. So long as you do have up to date scripts, if the preview run executes without errors in Dashboard then so should the Form Type when a Server Task executes it.

PDF Printing

[su_note note_color=”#f0c4f4″]PDF Printing released[/su_note]
Release 5.7 brings a new PDF Printing facility, which can take pages from existing PDFs and send them to a printer with complete control over:

  • Which pages are included, and in what order.
  • How the page content is scaled and positioned.
  • Printer settings such as which paper tray to feed from (even down to individual pages)
  • How the print is split into separate print jobs in the Windows spooler.
  • What’s done with the PDF afterwards.
  • And much more.

A single print job can contain pages from several PDFs, and the whole process can be controlled from an XML metadata file to allow it to be automated and driven from other applications. However you can still change any and all settings in your script before committing the work to be printed, so you can tailor it according to any information your script can access (perhaps customer preferences looked up from a database).

[notice]PDF Printing is part of the new “PDF Processing” module so you’ll need a license which covers that module in order to use it. Enterprise Plus licenses will have that automatically, but other licenses will need to be upgraded. Contact your reseller for pricing.[/notice]

Welcome from Document Genetics!

Welcome to the {formate-evo} blog.

As the UK distributor for eVo, we’ll be chiming in from time to time with useful nuggets of information, hints etc. So keep an eye on the blog for more…