Difference: Appx610Features (25 vs. 26)

Revision 262021-05-12 - MisaghKarimi

Line: 1 to 1
 

APPX 6.1.0 Features

_This page provides an overview of the new features in APPX 6.1.x

Line: 6 to 6
 

Overview

Changed:
<
<		The most significant change in this is release is support for a Unicode data type. From Wikipedia: "Unicode is a computing industry standard for the consistent encoding, representation, and handling of text expressed in most of the world's writing systems. The latest version contains a repertoire of 136,755 characters covering 139 modern and historic scripts, as well as multiple symbol sets. The Unicode Standard is maintained in conjunction with ISO/IEC 10646, and both are code-for-code identical." The addition of Unicode will allow you to develop APPX applications to run in any language.
>
>		The most significant change in this is release is support for a Unicode data type. From Wikipedia: "Unicode is a computing industry standard for the consistent encoding, representation, and handling of text expressed in most of the world's writing systems. The latest version contains a repertoire of 136,755 characters covering 139 modern and historic scripts, as well as multiple symbol sets. The Unicode Standard is maintained in conjunction with ISO/IEC 10646, and both are code-for-code identical." The addition of Unicode will allow you to develop APPX applications to run in any language.
  'UNICODE' is a new storage attribute for Alpha and Text fields. You can change this attribute, restructure the file, and APPX will accept Unicode data in that field. Although you may see some references to a NATIONAL encoding type, it is not implemented in this release. When storing the data in APPX/IO, APPX uses the UTF-32 format, which requires 4 bytes for each character. When printing Unicode data in a non PDF report or reading/writing a stream file, APPX uses UTF-8. The UTF-8 standard uses 1 to 4 bytes per character. It was designed for backward compatibility with ASCII. The first 128 characters of Unicode, which correspond one-to-one with ASCII, are encoded using a single octet with the same binary value as ASCII, so that valid ASCII text is valid UTF-8-encoded Unicode as well.
Line: 14 to 14
  Transcoding is the act of converting to or from Unicode. APPX handles this for you automatically. However, if you move a field containing Unicode data to a non Unicode field and the Unicode data cannot be transcoded to the target encoding a runtime error will occur. This is similar to an overflow condition with a numeric field. We do not want to simply continue, as you have lost data in this case. There are also APIs for transcoding that give you more control.
Changed:
<
<		Various fields in APPX System Administration and Application Design have been converted to Unicode. As a result of this, System Administration, Application Design and all Structure files are incompatible between Release 6 and any earlier release. A migration tool is provided to move the System Administration and Application Design files to Release 6.0. See Upgrading an Existing installation for the details.
>
>		Various fields in APPX System Administration and Application Design have been converted to Unicode. As a result of this, System Administration, Application Design and all Structure files are incompatible between Release 6 and any earlier release. A migration tool is provided to move the System Administration and Application Design files to Release 6.x. See Upgrading an Existing installation for the details.
  Unicode is not accepted everywhere in the System Administration or Application Design files. Only those fields that are 'user-facing' have been changed. For example, Printer Descriptions, Form Descriptions, Field Descriptions, Field Column Headings are all Unicode. Fields the end user does not see, such as Process Names, File names, etc., are not Unicode. To check if a field accepts Unicode or not, just press Help (F1). The help text will tell you if it is a Unicode field.
Line: 25 to 25
  The new API's have been enhanced to work with Unicode fields, but the older ones have not. You may need to update your applications to use the newer APIs.
Changed:
<
<		Since Unicode fields require 4 bytes per character, the maximum size of an Alpha/Text field is now 1M (1,048,576 characters). The maximum record length for an APPX/IO file remains at 32K, but is not limited when using Oracle or MS SQL Server.
>
>		Since Unicode fields require 4 bytes per character, the maximum size of an Alpha/Text field is now 1M (1,048,576 characters). The maximum record length for an APPX/IO Type 9 (Large File) increased to 4,194,560 bytes but APPX/IO Type 1 file remains at 32K. Oracle or MS SQL Server don't have record length limit.
  Unicode is not accepted in ILF statements or Enduser/Designer Selections in a Query. Unicode is accepted in a Query at runtime. If you must refer to a Unicode character in ILF, you can use the \uxxxx syntax. For example, to use the ❤ symbol you could use: 
      SET --- TEMP 1 = \u2764
      DISPLAY --- TEMP 1 (AT APPEARANCE # )
Line: 53 to 53
  Unicode fields must be aligned on a 4 byte boundary. When the file is processed, APPX will check this and warn you if you need to add alignment bytes. Simply add an alpha field of the designated length in front of your Unicode field. If you have more than one Unicode field in your file, you may have to add multiple alignment bytes.
Changed:
<
<		If the new record length is > 32K, you will get a warning from the Data Dictionary compiler. If you are going to store this file in Oracle or SQL Server, you can ignore this. However, the 32k limit still applies to APPX/IO files.
>
>		If the new record length is > 32K, you will get a warning from the Data Dictionary compiler. If you are going to store this file in Oracle or SQL Server, you can ignore this. If you are using APPX/IO Type 9 file, the new record length limit is 4,194,560. However, the 32k limit still applies to APPX/IO Type 1 files.
  In order to display or print Unicode data, the field must have a GUI Attribute of either a LABEL (non modifiable field on an Input or normal field on an Output) or RAW TEXT. The default font for a LABEL is Arial, which may be noticeable if the other fields on the image are not. You can override the default font to COURIER to use the same font as fields without a GUI attribute.
Line: 91 to 91
  The .STREAM functions have been reworked to read or write data in UTF-8 format.
Added:
>
>		The regular expression library has changed to support unicode characters. It also supports more complex patterns.
 The following APIs were added:

.TEXT FROM UNICODE - transcodes a Unicode field to a Raw field, with control over characters that can't be transcoded.

Line: 129 to 131
  The following fields have been added to --- WIDGET and can be manipulated via ILF:
Changed:
<
<		Drop Shadows
>
>		Drop Shadows
  WIDGET DS VISIBLE
WIDGET DS DISTANCE
WIDGET DS ANGLE
WIDGET DS OPACITY
WIDGET DS SIZE
WIDGET COLOR DS (Group Header)
WIDGET COLOR DS R
WIDGET COLOR DS G
WIDGET COLOR DS B
WIDGET COLOR DS NL
Line: 324 to 326
 
Added:
>
>
 

Known Issues

  • Performance in some areas is slow
Added:
>
>
  • APPX -c doens't work
 We expect to deal with these issues in the next patch release.

For an up to date list of known issues, use Bugtracker & search for bugs in Release 6.1.1. These are the known bugs that we expect to fix in the patch release.

View topic | History: r48 < r47 < r46 < r45 | More topic actions...
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback