In 4D v15, you can assign the value of the "id_added_by_converter" special field that is automatically added by 4D when converting a database from a version prior to v11. Previously, this value could only be assigned by 4D, which forced developers to use obsolete commands such as _o_CREATE SUBRECORD to be able to add new records in converted subtables.
With this new possibility, you can convert your old databases that use subtables in a more progressive way: you can keep the special "subtable relation" link, and add or modify related records as if they were standard. Once all your methods have been updated, you can replace the special relation with a regular one with no change in your code.
For example, you can now write:
CREATE RECORD([Employees]) [Employees]Last Name:="Jones" CREATE RECORD([Employees_Children]) [Employees_Children]First Name:="Natasha" [Employees_Children]Birthday:=!12/24/2013! [Employees_Children]id_added_by_converter:=4 //Type mismatch in previous releases SAVE RECORD([Employees_Children]) SAVE RECORD([Employees]
This code will work with both special and regular relations.
In 4D, fields with the Unique attribute must be indexed. Starting with 4D v15, you are no longer able to define fields in the Structure editor with a Unique attribute if they do not have an index. In previous releases, it was still possible to obtain such a configuration for maintenance purposes.
In 4D v15, a new icon is displayed for pictures that are saved in a format which cannot be rendered on the machine. The extension of the missing format is written at the bottom of the icon:
This icon is automatically used wherever these pictures are displayed.
It indicates that the picture cannot be displayed or processed locally -- but it can be stored for display on another machine. This is the case, for example, for PDF pictures on a Windows platform, or PICT-based pictures on a 64-bit 4D Server on OS X.
In databases created in 4D v15, methods are automatically saved in Unicode. In a converted database, you have to select the Save methods as Unicode option in the "Compatibility" dialog of the Database settings.
In 4D v15, 4D's Method editor uses the international "English-US" language by default, regardless of the 4D version or local system settings:
decimal separators for real numbers must now be periods (".") in all versions (and not commas (","),
date constants must now use the ISO format (!YYYY-MM-DD!)
command and constant names must be in English (this change only concerns French versions of 4D, since this was already the case with other languages).
In applications converted from prior versions, be careful when using formulas such as with EXECUTE FORMULA.
This setting can be disabled using the new Use regional system settings option of the Methods/Options page of 4D's Preferences dialog box:
Deployment: since the Use regional system settings preference is local to the machine, it is not included in merged applications.
When deploying merged applications, there are two solutions for using regional settings:
Solution 1: delete the en.lproj directory located at the first level of the Resources folder of the 4D Volume Desktop application before building the final merged application.
Solution 2: Edit the contents of the 4D v15 preferences file on each local machine and set the "use_localized_language" key to "true". Sample code to do this is provided in the appendix. After executing it, keep in mind that you will need to restart the 4D application in order for the modification to take effect.
Since 4D v14, on a Windows PC, using the "decimal separator" key of the numeric keypad produces a different result for a numeric type field than it does for a text type field:
Until 4D v13: regardless of whether a field is numeric or a text, pressing this key on the numeric keypad inserted the decimal separator defined at the system level (this definition must have been done before launching 4D);
In 4D v14 and 4D v15: for Real type fields, using this key of the numeric keypad inserts the decimal separator defined at the system level (no change). For other field types, hitting this key inserts the character associated with the key, usually a period (.) or comma (,).
This difference is only noticeable in cases where the system decimal separator is different from the one shown on the key. This is the case, for instance, for French systems where the system decimal separator (comma) is not the one assigned to the numeric keypad (period).
Note: For more information about numeric formatting in converted databases, see also the "Use period and comma as placeholders in numeric formats" compatibility option in the Compatibility page section.
The number of significant digits used for representing the decimals of real numbers has been reduced in 4D:
in previous versions, this number was 15 digits
in 4D v15 and subsequent versions, it is now 13 digits.
This modification concerns only the conversion of real numbers into text, not the way they are represented internally (storage), or arithmetic operations between real numbers. The accuracy of real numbers is not affected. The purpose is to limit the number of cases where operations on real numbers produce incorrect results. For example, this will allow us to obtain valid results in the following cases:
Operation
Result in 4D before v14R3
Result in 4D starting with 4D v14R3
String(3216.36 - 3214.89)
"1.47000000000025"
"1.47"
String(0.321636-0.321489)
"0.000146999999999953"
"0.000147"
The accuracy of real numbers is limited in nature so if your 4D application uses the first 15 digits or more of real numbers, you may need to use other data formats, such as text or long integers (for serial numbers or astronomical measurements). Note that in 4D, the degree of accuracy by default of these comparisons can be modified using the SET REAL COMPARISON LEVEL command.
We needed to modify pointer representations in the code of 4D due to the changing of methods to Unicode. Pointers were optimized and support extra features such as 2D array elements; since it is important to maintain compatibility with previously compiled components and plug-ins, a new pointer data type, managed transparently by 4D, has been added to the language.
Two commands have been affected:
RESOLVE POINTER now returns -1 instead of 0 in the fourth parameter for pointers to variables or single-dimension arrays