Difference: Appx600Features (4 vs. 5)

Revision 52018-02-22 - JeanNeron

Line: 1 to 1
 

APPX 6.0.0 Features


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 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.
Changed:
<
<		Printing Unicode characters in a PDF document is handled by the inclusion of the DejaVu Font library. This is an open source font collection designed for greater coverage of Unicode, as well as providing more styles. Since there are over 1 million possible Unicode characters, not every font family can print all the characters. You may need to source a different font library if your target language is not fully supported in DejaVu. APPX provides a way for you to override the default fonts. The fonts will be embedded in the PDF document and will display regardless of what fonts the user has on their desktop.
>
>		Printing Unicode characters in a PDF document is handled by the inclusion of the DejaVu Font library. This is an open source font collection designed for greater coverage of Unicode, as well as providing more styles. Since there are over 1 million possible Unicode characters, not every font family can print all the characters. You may need to source a different font library if your target language is not fully supported in DejaVu. APPX provides a way for you to override the default fonts. The fonts will be embedded in the PDF document and will display regardless of which fonts are installed on the user's desktop.
 
Changed:
<
<		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.
>
>		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. Because of this, System Administration, Application Design and all data 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. All key files must be rebuilt as well. 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.0. See Upgrading an Existing installation for the details.
 
Changed:
<
<		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.
>
>		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.
 

Application Design Considerations

Changed:
<
<		All --- TEMP fields are now Unicode. This may have an impact if you are PASSing a TEMP field to an internal or external routine or program. If it isn't expecting Unicode, that may be a problem. A number of --- WORK RAW xx fields have been added, you can use these in place of --- TEMP if you need a non Unicode field.
>
>		All --- TEMP fields are now Unicode. This may have an impact if you are PASSing a TEMP field to an internal or external routine or program. If it isn't expecting Unicode, that may be a problem. A number of --- WORK RAW xx fields have been added - you can use these in place of --- TEMP fields if you need a non Unicode field.
 
Changed:
<
<		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 API's, ie, use --- .STREAM OPEN/READ/WRITE instead of --- STREAM OPEN/READ/WRITE.
>
>		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 API's, i.e., use --- .STREAM OPEN/READ/WRITE instead of --- STREAM OPEN/READ/WRITE.
 
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 file remains at 32K, but is not limited when using Oracle or MS SQL Server.
 
Changed:
<
<		Unicode is not accepted in ILF statements. 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:
>
>		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 # )

where 2764 is the code point for the ❤ symbol.

Added:
>
>		Since Unicode is not allowed in ILF, the 'Delimited Exporter' in the Data Dictionary toolbox will substitute a ? for Unicode characters if generating a row of field names.
 If a Group field contains a Unicode field, you cannot SET that group to or from an Alpha field. The process will give an 'Invalid Storage Type' compile error. Similarly, Unicode fields cannot be set into a Group field. This may have an impact on your applications if you are using --- TEMP fields to move data to/from a group, since all --- TEMP fields are Unicode. You can use one of the new WORK RAW fields instead. If a group field contains a Unicode field, it can only be moved to/from another group field.
Changed:
<
<		There are many new fields on the GUI Attributes screens for Items on an Image. Because of this, we recommend using at least 27 rows in your Desktop Client setting.
>
>		There are many new fields on the GUI Attributes screens for Items on an Image. Because of this, we recommend using at least 27 rows in your Desktop Client settings.
  There are additional considerations discussed in more detail at the end of the Upgrade instructions.
Line: 40 to 42
 Here is a list of the changes in Release 6.0:

Unicode

Changed:
<
<		You can now specify a 'Unicode' encoding type for Alpha and Text fields. This is specifed in the Additional Attributes dialog box:
>
>		You can now specify a 'Unicode' encoding type for Alpha and Text fields. This is entered in the Additional Attributes dialog box:
  Field_AA.png

The default encoding type is RAW, which corresponds to US ASCII (ISO-8859-15). If you are not using ISO-8859-15 as your default encoding, then set the APPX_RAW_ENCODING environment variable to tell APPX which encoding you are using.

Changed:
<
<		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 a simple 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.
>
>		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.

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.

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.

 
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.
>
>		You also need to consider how this field is used. If it is moved to a non Unicode field (via SET or RECEIVE) that will cause a runtime error to occur if the source field contains Unicode characters that cannot be transcoded. To prevent this, all target fields must also be Unicode and any fields they are moved to, and so on.

Desktop Client Uses external Text Viewer

 
Changed:
<
<		In order to display or print Unicode data, the field must have 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.
>
>		The Desktop Client now uses an external program for viewing text report. Previously these would be displayed in the client itself. The text viewer to use is specified in the client settings:
 
Changed:
<
<		You also need to consider how this field is used. If it is moved to a non Unicode field (via SET, RECEIVE, etc) that will cause a runtime error to occur if the source field contains Unicode characters that cannot be transcoded. To prevent this, all target fields must also be Unicode and any fields they are moved to, and so on.

New & Revised API's

>
>		text_viewer.png

New & Revised APIs

 
Changed:
<
<		All the .TEXT API's have been reworked to accept Unicode strings up to 1M in length. The .TEXT LOWER TO UPPER and .TEXT UPPER TO LOWER use the Unicode library to convert text. If you have applications that add or subtract 32 from the ASCII value to convert case, be aware this technique will not work with Unicode data (unless the Unicode field only contains US ASCII characters).
>
>		All the .TEXT APIs have been reworked to accept Unicode strings up to 1M in length. The .TEXT LOWER TO UPPER and .TEXT UPPER TO LOWER use the Unicode library to convert text. If you have applications that add or subtract 32 from the ASCII value to convert case, be aware that this technique will not work with Unicode data (unless the Unicode field only contains US ASCII characters).
  The .STREAM functions have been reworked to read or write data in UTF-8 format.
Changed:
<
<		The following API's were added:
>
>		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: 72 to 79
 .TEXT UNICODE COMP - compares 2 Unicode fields.

New Widget fields

Changed:
<
<		There were a number of GUI capabilities that were only accessible via macros (@xxx=yy). The following macros have been converted to formal WIDGET specifications:
>
>		There were a number of GUI capabilities that were previously only accessible via macros (@xxx=yy). The following macros have been converted to formal WIDGET specifications:
  @SDS - Drop Shadows
@SLN - Layering
@SFP - Focus Painting
@SMV - Movable
@SLUB, @SSPO - Line settings
@TSRN - Show Row Numbers on Tables (HTML client only)
@TSFB - Show footer bar on Tables (HTML client only)
@TCSS - Case Sensitive Sorting on Tables (HTML client only)
@FULC - Suppress use of Local Connector (HTML client only)

Line: 125 to 132
  trap_options.png
Changed:
<
<		The options are self explanatory. The system identifies 'your' TRAPs by checking the user id of the user that added the TRAP and the date. Anything you added today will be considered 'your' TRAPs. TRAPs you added in the past, or TRAPs added by other designers are not considered 'your' TRAPs.
>
>		The options are self-explanatory. The system identifies 'your' TRAPs by checking the user id of the user that added the TRAP and the date. Anything you added today will be considered 'your' TRAPs. TRAPs you added in the past, or TRAPs added by other designers are not considered 'your' TRAPs.
 
Changed:
<
<		The method of turning off TRAPs has been changed as well. Previously, APPX would convert the TRAP to a comment statement, making it awkward to activate the TRAP later. Now it will check the TF flags, and as long as there is one available flag, it will simply comment the TRAP, making it easier for you to uncomment it later.
>
>		The method of turning off TRAPs has been changed as well. Previously, APPX would convert the TRAP to a comment statement, making it awkward to reactivate the TRAP later. Now it will check the TF flags and as long as there is one available flag, it will simply comment the TRAP, making it easier for you to uncomment it later.
  This option is also available in the Toolbar and Toolbox pulldown menu while at the Process level:
Line: 164 to 171
 Choosing this font type will cause APPX to use the font specified by the Named Resource. If you choose this font type, you must also enter a Named Resource.

This replaces the technique described where you have to read the WIDGET record and indirectly set WIDGET FONT to 10 via ILF. Now you can simply choose the font RESOURCE.

Changed:
<
<

New utility to check for dup shortcuts

>
>

New utility to check for duplicate shortcuts

  A new utility has been added to the 'Tools' tab in Application Design - 'Check for Dup Shortcuts'. It will list all the shortcuts used in the application and flag the ones it thinks might be duplicates:

shortcuts.png

In this example, the letter S is used for both the 'Save' button and the 'Sales Opport.' button and W is used for both 'Weather' and the WWW button.

Changed:
<
<

0LA Output STANDARD MOD LOG and 0LA Input CONFIRMATION (END) in 0LC and can be hooked

>
>

0LA Output STANDARD ACTION LOG and 0LA Input CONFIRMATION (END) included in 0LC and can be hooked

 
Changed:
<
<		The Output STANDARD MOD LOG and the Input CONFIRMATION (END) have been added to application 0LC and can now be hooked.
>
>		The Output STANDARD ACTION LOG and the Input CONFIRMATION (END) have been added to application 0LC and can now be hooked.
 

Bugs Fixed

The following bugs were addressed in this Release:

Line: 205 to 212
 
META FILEATTACHMENT attachment="font_type.png" attr="h" comment="" date="1519236827" name="font_type.png" path="font type.png" size="88760" user="JeanNeron" version="1"
META FILEATTACHMENT attachment="shortcuts.png" attr="h" comment="" date="1519237329" name="shortcuts.png" path="shortcuts.png" size="123844" user="JeanNeron" version="1"
META FILEATTACHMENT attachment="trap_toolbar_new.png" attr="h" comment="" date="1519247748" name="trap_toolbar_new.png" path="trap toolbar new.png" size="288667" user="JeanNeron" version="1"
Added:
>
>
META FILEATTACHMENT attachment="text_viewer.png" attr="h" comment="" date="1519316430" name="text_viewer.png" path="text viewer.png" size="63369" user="JeanNeron" version="1"
View topic | History: r19 < r18 < r17 < r16 | 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