Deprecated or removed features in v17 product range

As of version 16 R5, 4D Windows Server 32-bit is obsolete. This release relies on component and legacy libraries, which are no longer maintained. Only 4D Windows Server 64-bit will be available in new major releases.

64-bit versions of 4D favor recent technologies and usually do not support those that have been declared obsolete in previous versions of 4D. For a complete list of functions that are not supported in the 64-bit product range of 4D, please refer to the Quick table section of this manual.

Standard actions have been internally redesigned in 4D v16 R3. They are now based on string patterns and support parameters (for more information, please refer to the Standard actions section).

In your converted applications, standard actions are transparently remapped to the new design. However, in the 4D language, standard actions were previously based on code values. This principle is deprecated and should no longer be used:

• Code-based text standard actions in the Standard Action constant theme (previously named "Text Values for Associated Standard Action") are prefixed with "_o_" and should no longer be used.
• The whole Value for Associated Standard Action constant theme is deprecated.
• The _o_OBJECT Get action command (which returns a code) is deprecated and has been replaced by the updated OBJECT Get action command (which returns a name).

The XSLT language, inspired by functional programming concepts, transforms XML data to any format (XML, HTML, or any other type). All major Web browsers as well as 4D software have implemented the XSLT 1.0 specification.

Currently the XSLT trend is in decline because developers consider that it is difficult to use and debug. Following this trend as well as feedback from developers, we decided that the XSL transformation feature will not be developed for 4D 64-bit versions. However, to support our customers still using XSLT in 4D, we made the choice to rely on the PHP XSL library, which provides a comprehensive API allowing you to perform all operations necessary for your XSL transformations. This library is an efficient tool which can easily replace the _o_XSLT APPLY TRANSFORMATION, _o_XSLT SET PARAMETER and _o_XSLT GET ERROR commands after their removal. 4D has produced a specific document to help you use PHP XSL as a replacement for the 4D XSLT commands: Download XSLT with PHP technical document (PDF).

We also suggest that you consider using 4D tags when dealing with the dynamic generation of HTML pages, since in most cases it is easier if you handle HTML code as unformatted text (see also the PROCESS 4D TAGS command).

Note: Trends of XSLT search in Google: http://www.google.com/trends/explore#q=xslt       

For compatibility, XSL transformations are still supported in 4D, but their use is now discouraged. Support for XSLT processing will be removed in future 4D releases.

Note for 64-bit versions: XSLT is not available with 4D 64-bit (OS X and Windows) and 4D Server 64-bit for OS X. Consequently, calling one of the XSLT commands from these applications will generate an error 33 "Unimplemented command or function".  

The PICT format will not be supported in the next major releases of 4D and you must no longer use it in 4D. The GET PICTURE FORMATS command helps you detect and filter pictures using the PICT format in your data file.

Note: The Mac "PICT" format has been deprecated by Apple since several prior Mac OS versions (see the description of PICT format on Wikipedia).

The ‘PICT’ format is a very old Mac format. Prior to version 11, 4D stored all pictures in this format, even on Windows. The PICT format has been deprecated since QuickDraw was deprecated in 2005.

There is one important thing to understand about PICT. It can store (read “encapsulate”) 2 main kinds of information:

• the drawing primitives themselves (either bitmap or vectorial), or
   
• a more modern format (JPEG for example) stored in a PICT using QuickTime. (Usually the developer was calling _o_QT COMPRESS PICTURE with the QT Photo compressor constant).

This means that even back when all pictures stored in the data files were PICT, those PICTs could, in fact, contain JPEGs (or other formats). It’s important for our customers to stop using PICT, not only because it is obsolete, but also because 4D needs Altura (+ QuickTime if _o_QT COMPRESS PICTURE was used) to read PICT on Windows. This is not efficient, and it requires QuickTime to be installed.

When migrating data from versions prior to v11, developers should apply the CONVERT PICTURE command to every picture field of the data. When converting data from more recent versions, we recommend using the GET PICTURE FORMATS command to find pictures in your data file that need to be converted.

Starting with v16, you can detect pictures that use the deprecated PICT format in your database structure by means of the Maintenance and security center (MSC). When you use the Verifying the application feature, the log file produced includes warnings indicating any pictures found which use or contain the PICT format. These warnings may concern static pictures, as well as pictures found in the picture library or in form objects.

Note: It is up to you to either remove or replace pictures that use the deprecated PICT format. Using the MSC to perform a Repair the structure file operation does not have any effect on "deprecated" pictures and the same warnings will appear in its log file.

Support for the picture codecs related to QuickTime is now obsolete.

By default, the use of QuickTime is disabled since 4D v14. However for compatibility reasons, you can enable it using the new QuickTime support option of the SET DATABASE PARAMETER, Get database parameter commands (except in 64-bit versions of 4D, where QuickTime is not supported). 

For several years, image handling in the Windows version of QuickTime has not evolved (only the video part is evolving). We plan to remove support for these specific APIs in the next release.

4D for Windows natively supports all major formats (JPEG, PNG, GIF, TIFF, etc.), and also supports WIC (Windows Imaging Component). If, in your data, you have some pictures saved–in Windows–in a specific format known only by QuickTime, you can convert them (CONVERT PICTURE).

We also remind you that the support for QuickTime picture formats has been removed from the 64-bit version of 4D Server for Windows as of 4D v12.

In previous versions of 4D, the Web server automatically recopied the value of variables sent through a Web form or a URL into 4D variables when they had the same name.

For reasons of optimization and control, this principle is not maintained starting with 4D v14: the value of Web variables are no longer automatically assigned to the 4D variables. To recover variables sent using a POST or a GET, you must use the WEB GET VARIABLES command exclusively. To recover the posted files, you must use the WEB GET BODY PART/WEB Get body part count commands.

Note: Dynamic assignment is also disabled by default in 4D databases created beginning with version 13.4.

However, for compatibility, this mechanism is maintained by default in databases created with a version of 4D earlier than 13.4. In this case, you can disable it using the Automatic variable assignment compatibility option on the Compatibility page of the Database Settings.

Since this mechanism is obsolete, we strongly recommend that you uncheck this option in your converted databases (and adapt your code if necessary) so as to facilitate future evolutions.

Altura Mac2Win was used to port 4D to Windows. It is a set of APIs that helped porting Mac OS (pre OS X) code to Windows, by translating APIs: filesystem, QuickDraw, Resources, PICT, etc. It was very useful and helped a lot (Mac plug-in developers, for example, could move their plug-ins to Windows more easily), but it translates old (read “deprecated”) Mac OS APIs, and doesn’t use modern native Windows APIs: 4D must remove Mac2Win from its code as much as possible. This is very long and hard work, and in each version of 4D, some dependencies are removed (and replaced by modern APIs).

Right now, 4D (only 32-bit versions) still depends on it in part, mostly to be able to handle compatibility of old databases: Resources, PICT, part of the user events handling, support for third party plug-ins that are built using Altura, etc. By removing resources in the .RSR file to separate files in the “Resources” folder, and by converting pictures (CONVERT PICTURE) to not-PICT, 4D developers will be ready once 4D has removed Altura. But the first people concerned by this huge step are plug-in developers. They must stop using Altura as soon as possible, which means they must rewrite some parts of their Windows source code. (We have already been warning them for several years now.)

Reminder: Altura Mac2Win has been completely removed from the 64-bit versions of 4D Developer Edition and 4D Volume Desktop with 4D v16 R2; it has been removed from the 64-bit version of 4D Server with 4D Server v16 R4.

Over several major versions, 4D has warned developers against the use of subtables and since 4D v11, it is no longer possible to create a field of the SubTable type. Subrecords have several known limitations. For example, they are always loaded in memory; they are not handled by the SEND RECORD or DUPLICATE RECORD commands.

We do not plan to remove support for subtables in the near future, but it’s really time for developers to convert their subtables to regular N-> tables because we do plan to remove them in a future major version of 4D. Developers who used subtables for performance reasons (certain specific situations where loading related records was slow) can be reassured, especially since v12: the speed is here and using classic N<->1 relations is very fast.

Basically, there are two main ways to remove subtables (note: the following is not a full tech tip; just a quick overview):

• Before conversion from a pre-v11 structure: in 2004, create the appropriate N table and the ID field in Table 1 (if not already there). Then change the code everywhere it is needed (see below).
   
• After conversion: in this situation, 4D has replaced the subtable with a N table using a special relation, that allows the language to work with the subselection and the subrecords. The 4D developer needs to remove this special relation, replace it with a normal relation and change the code everywhere if it is needed (see below).

What we mean by “change the code everywhere if it is needed” is, basically:

• Create the new forms, update included forms
   
• In the methods (project, form, object, etc.):
  
  • Replace all commands of the “SubRecords” theme with the corresponding Selection or Record command (for example, replace _o_CREATE SUBRECORD with CREATE RECORD, filling the ID fields)
  • Explicitly load the N records when needed

Note: Starting with 4D v14 R3, you can assign values to the special "id_added_by_converter" fields that are automatically added by 4D when it converts a database containing subtables. This allows you to keep the "subtable relation" link, and add or modifiy related records, without needing to use deprecated commands such as _o_CREATE SUBRECORD. Once you have updated your methods, these special relations can be replaced with standard ones with no change in your code.

QuickDraw fonts (e.g. Geneva, Chicago) are now deprecated and you should no longer use ID numbers to designate fonts. The _o_Font number and _o_Font name commands are kept in 4D v15 and higher for compatibility but will be removed in subsequent versions. The OBJECT SET FONT command now only accepts font names.

There are two types of plug-ins: those using the new plug-in API, and those that still use the old one (with QuickDraw).

For plug-ins using the old tool box (with QuickDraw): to maintain compatibility, the drawing/rendering is no longer done directly in a QuickDraw port, as in previous versions, but instead through a GWorld QuickDraw offscreen area dedicated to the plugin.

Consequently, you have to respect a few rules, like plugins must not modify the current port set by the container (form object).

For plug-ins using the new tool box: only this new tool box is used and not QuickDraw (see https://github.com/4D/4D-Plugin-SDK).

Supporting ASCII mode (synonym for “non-Unicode mode”) leads to poor performance when manipulating text because it must be converted to and from Mac-Roman every time it is used in the legacy-converted structure. We plan to remove ASCII mode in future major versions.

Note that support for ASCII mode was already removed for compiled structures running on 4D Server 64-bit for Windows. 4D developers should – for converted structures – activate the Unicode mode. The Conversion to 4D v14 PDF document gives hints about this topic.

Note for 64-bit versions: ASCII mode is not supported in 64-bit versions of 4D and 4D Server.

Starting with 4D v16 R6, Mac OS 9-based APIs for file and folder management are deprecated in 4D. These APIs have already been deprecated by Apple for a long time. 

4D commands relying on the old APIs have been renamed: _o_Document type, _o_Document creator, _o_SET DOCUMENT TYPE, _o_SET DOCUMENT CREATOR, and _o_MAP FILE TYPES. These commands are maintained for compatibility, but are deprecated and should no longer be used. 4D includes two new commands to handle pathnames and file extensions: Path to object and Object to path.

This is another old Mac OS technology, deprecated since Mac OS X 10.4 (Tiger, 2005). Resources are used to store structured data such as text and strings (localization), as well as icons, etc. Basically, we can say that it’s not the resources that are deprecated, it’s their on-disk support, known as the resource fork. The resource fork is part of the Mac OS file system, and since the beginning of Mac OS X, Apple has tried to remove this support as it is not compatible with other file systems (Unix, Windows), and is the source of a lot of problems when files are transferred via the network.

On Windows, this mechanism is emulated and Mac Resources reside in a .RSR file.

But even if there are still APIs to handle resources (and Mac OS transparently handles resources stored in a data fork), it is no longer recommended to use this old mechanism for several reasons:

• Text and strings are Mac-Roman. You can’t store Unicode in resources of type TEXT or STR#
   
• PICT resources store PICTs: not modern, deprecated, no transparency, etc. (See the “Pictures in PICT format” topic above.)
   
• The count of resources and the size of the resources are limited (about 2,700 resources or 16 MB)

We have removed support for commands that write/create resources.

The vast majority of 4D applications using resources are, in fact, using the “Strings List” resources, ‘STR#’. 4D provides tools to easily move from STR# to XLIFF:

• The 4D Pop component can automatically create the XLIFF files by reading and transferring the content of the STR#.
   
• All the routines and expressions that reference STR# work with no change with XLIFF. For example, if the label of a button or a menu was “:15000,3” (meaning “get the third item of STR# ID 15000”), 4D will load the appropriate XLIFF (if it exists).

For other kinds of resources:

• Put resources in separate files inside the Resources folder (create sub-directories if needed):
  
  • Save 'TEXT' resources in XLIFF or .txt files
  • Save 'PICT' resources as separate .jpg/.png/etc. files
  • Save 'PICT' + MASK’ resources as png files
  • Use (on Mac) icns instead of ICON or colored icons
  • Save any private resources as appropriate for you (typically: save as a binary file with a specific extension)
     
• Use the “Resources” folder to store your resources. Use Get 4D folder(Current resources folder) to dynamically get the parent path for your resources.

Modifying the CPU priority is an obsolete setting. Memory management for 4D applications has been optimized over the different versions and it is unnecessary and may even be counterproductive to modify the default settings. As a result:

• the "CPU Priority" area ("General" page of the Database Settings) is now displayed only in converted databases where a custom value has previously been set. We recommend clicking on the Factory settings button in this case in order to reinitialize these parameters and remove them from the dialog box. 
   
• beginning with 4D v16 R2, obsolete selectors of the SET DATABASE PARAMETER command have been renamed (_o_4D Remote mode scheduler, _o_4D Local mode scheduler and _o_4D Server scheduler) and must no longer be used.

Over the course of different versions, the most useful 4D Pack routines were progressively integrated into 4D itself, while those that became obsolete were removed. Starting with 4D v16 R2, the 4D Pack plug-in is no longer provided in versions of 4D. Refer to the table below to find out the replacement solutions available (if any) for 4D Pack routines.

The OLE_Tools plug-in (available on Windows only) is now deprecated in 4D 32-bit versions and will not be supported in 4D 64-bit versions. Features provided by this legacy plug-in can be replaced, depending on the case, by the Web areas, the LAUNCH EXTERNAL PROCESS command, or PHP.

For better clarity in the 4D language, starting with 4D v15, every obsolete command has been prefixed by "_o_", if this was not already the case and are no longer available in 4D lists (code editor, type-ahead feature, etc.).
 
They will not be removed from existing code and will continue to work normally as long as they are supported. It is still possible (but not recommended) to add an obsolete command in a method by simply entering its name prefixed by "_o_"; it will be interpreted correctly.