Tuesday, 13 November 2012

Formate; Windows Language for non-Unicode programs

[Formate]  Until formate v2.15.6 Formate's working pages files used a single character to identify where one item ends and the next starts. It does this by placing a special separator character between the items, which has to be a character that won’t appear within the items themselves or it would be mistakenly seen as a separator. This meant that an unusual character had to be chosen.

The chosen character has worked well for quite some time, but It has now been found that if the “Language for non-Unicode programs” option in the operating system’s regional settings is set to something other than UK English (e.g. Polish), the special character is automatically converted into a different character by Windows when it’s written to the “.tfp” file, presumably in an attempt to make it fit into the character set for the selected language. Unfortunately, this means that when the file is loaded in order to display or print the contents, the separator characters aren’t recognised and the file appears to be corrupt. This often results in a “DisplayPage” error, usually a “Type Mismatch”.

The “Use Extended TFP Separator” checkbox has been added to resolve this issue. When it’s not ticked, the original single character separator is used and Formate works exactly as it previously did. When it is ticked, however, a new multi-character separator string is used which contains characters that are likely to be available in most languages and so will generally not be converted into something else by Windows. It’s because common characters are used that the new separator has to be multi-character so that it can be a combination of characters which is extremely unlikely to appear in the data; if it were a single character as before but the character was a common one such as say an exclamantion mark, the first time a Form Type produced text containing an exclamation mark it would cause an error.

This leads to the disadvantage of using the new multi-character separator, which is that the “.tfp” files will be slightly larger and take slighty longer to read and write. In practice this probably won’t make a noticeable difference, but it does mean that the recommended approach is to always use the old separator (i.e. with the checkbox not ticked) so that the best performance is achieved, and this will work on the majority of systems, even in many cases where a non-UK-English language is selected for non-Unicode programs. The checkbox should only be ticked if problems arise which you find are cured by ticking it.

  (extracted from formate help)