Deprecated or removed features

For over 30 years, our main goal has been to enhance our product (using new concepts and technologies) while ensuring the compatibility of 4D applications. As early adopters of 4D know, we have always put a lot of effort into compatibility, and we can find 4D applications all over the world that were created years and years ago, with old versions of 4D and of an OS, that are still working with the latest revisions of the product.

Unfortunately, it sometimes becomes too difficult to mix old technologies with new:

• 4D must bring new technologies, new APIs, and new paradigms to developers
• OSes change every day, and sometimes deprecate their own old APIs

This is why 4D sometimes needs to tag some commands and features as deprecated, meaning that one day, they will be removed from the language in a future major version.

Letting developers know what is deprecated and what kind of replacement can be used instead makes it much more comfortable for them to implement the change in their code: There is no urgency, no pressure, and the developer has plenty of time to make any necessary changes.

Explanation of values for the “Status” column:

• Removed: No longer available in the current version (or the version indicated).
• Deprecated: Should no longer be used and will be removed in a future major version.
• OS: Depends on officially deprecated OS technologies (e.g.: PICT format). Status is the same as Deprecated, but an OS could remove the support before we do.

Every obsolete command is prefixed by "_o_" and is not available in 4D lists (code editor, type-ahead feature, etc.). Obsolete (or deprecated) commands 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.

You can find an alphabetical list of obsolete commands in the Deprecated Commands appendix of the 4D Language Reference.

The following commands, previously deprecated, have been removed from 4D and must not be used in your code. If they are called, they will trigger an error (Error 33 - Unimplemented command or function). 

Warning: Calls to removed commands cannot be detected by the check syntax or compile features. You must verify your code to make sure that it does not contain any calls to removed commands.   

Projects represent an important evolution of 4D databases architecture. Since projects rely on latest software interface requirements and most modern technologies, they do not support some legacy features, listed below. These features are now deprecated and should no longer be used in your databases, for a better compliance with the project architecture.

For detailed information on the project architecture in 4D, please refer to the 4D projects documentation on developer.4d.com. 4D provides an automatic export tool to convert .4db databases to projects. During the export, deprecated features are automatically converted, removed or generate errors (see Converting databases to projects).

The following form objects and properties do not comply with current interface requirements and are now deprecated. They are not supported in Dynamic Forms, and may generate a warning or an error in the project conversion log file (see comments).  

The following database structure options are deprecated and will be edited or generate errors in the project conversion log file (see comments).  

The following Toolbox editors or features are deprecated and are not supported in projects:

Legacy compatibility modes are not supported in projects. Compatibility settings are reset as for a new database during the export to project. If your database still rely on old compatibility settings, you need to consider updating it. 

We highly recommend that you read the series of blog posts devoted to how to get rid of compatibility settings. 

Starting with 4D v17 R5, 32-bit versions of 4D and 4D Server are no longer produced or delivered. Only 64-bit versions are available, allowing the 4D applications to take full advantage of this powerful architecture.

Although 64-bit versions support most legacy 4D features, they favor most recent technologies and do not support those that have been declared obsolete in previous versions. Upgrading databases developed for 32-bit versions may require some adaptations. Please consult the "Changing from 32-bit versions to 64-bit versions" page in the Conversion to v17 manual. 

XSLT is no longer available in 4D. Calling an XSLT command will generate an error 33 "Unimplemented command or function".  

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 removed _o_XSLT APPLY TRANSFORMATION, _o_XSLT SET PARAMETER and _o_XSLT GET ERROR. 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).

Support for QuickTime (through a database parameter) is removed from 4D starting with v17 R5. Picture codecs related to QuickTime are no longer supported on macOS and Windows.

As of v18, Float data field type is no longer supported the 4D database. This field type was only used by the SQL engine of 4D. If your database was using a Float type field, it is automatically converted to Real type when the database is open in v18 or higher. Existing data are not converted, unless you compact the data or re-save records. 

Note that this data type was only fully handled by the SQL engine. Float values were converted to Real values in 4D if they were handled via the 4D language.

Support for ASCII mode (synonym for “non-Unicode mode”) is removed from 4D v17 R5 and higher. When opening a converted database that was not set to Unicode, 4D displays the following alert dialog box:

This alert will be displayed at each startup while the Unicode mode option is not checked in the "Compatibility" page of the database settings. You must – for converted structures – activate the Unicode mode. The Conversion to 4D v14 PDF document gives hints about this topic.

The PICT format (deprecated by Apple since 2005) is no longer supported in 4D starting with v17 R5. It means that pictures in PICT format cannot be rendered by any means, they must be converted. Use the GET PICTURE FORMATS command to detect and filter pictures using the PICT format in your data file.

Specific deployment mode for merged single-user 4D applications on the mac platform using a DatabaseOutsidePackage key in the info.plist is no longer supported. Starting with 4D v17 R5, the DatabaseOutsidePackage key is ignored. 

As for 4D v17 R4, 4D no longer provides specific support for right-to-left interfaces on Windows. Corresponding options are no longer available in the database settings or form properties. In converted databases, right-to-left settings will be ignored at runtime.

As of 4D v17 R4, user forms are deprecated. To provide customizable user interfaces, it is now recommended to use dynamic forms (see Dynamic Forms in the 4D Design Reference). All commands within the "User Forms" theme have been deprecated.

User forms are still supported for compatibility, however, they should no longer be used. Their support will be removed in future releases.

4D Mobile feature is deprecated as of 4D v18 and should no longer be used. Access to 4D data through REST requests is now supported by ORDA technology and the 4D REST Server. 

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.

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 name command is kept 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).

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.

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).

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
  • 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.