Durante más de 30 años, nuestro objetivo principal ha sido mejorar nuestro producto (utilizando nuevos conceptos y tecnologías) al tiempo que garantizamos la compatibilidad de las aplicaciones 4D. Como saben los primeros usuarios de 4D, siempre hemos puesto mucho esfuerzo en la compatibilidad, y podemos encontrar aplicaciones 4D en todo el mundo que se crearon hace años y años, con versiones antiguas de 4D y de un sistema operativo, que aún funcionan con las últimas revisiones del producto.

Desafortunadamente, a veces se vuelve demasiado difícil mezclar tecnologías antiguas con nuevas:

• 4D debe brindar nuevas tecnologías, nuevas API y nuevos paradigmas a los desarrolladores
• Los sistemas operativos cambian todos los días y, a veces, dejan de utilizar sus propias APIs antiguas

Es por eso que 4D a veces necesita etiquetar algunos comandos y funcionalidades como obsoletos, lo que significa que algún día se eliminarán del lenguaje en una versión principal futura.

Dejar que los desarrolladores sepan qué está en desuso y qué tipo de reemplazo se puede utilizar en su lugar hace que sea mucho más cómodo implementar el cambio en su código: no hay urgencia, no hay presión, y el desarrollador tiene tiempo de sobra para realizar los cambios necesarios.

Explicación de los valores para la columna “Estado”:

Cada comando obsoleto tiene el prefijo "_o_" y no está disponible en listas 4D (editor de código, funcionalidad de autocompletar, etc.). Los comandos obsoletos (o desaprobados) no se eliminarán del código existente y continuarán funcionando normalmente mientras sean compatibles. Todavía es posible (pero no se recomienda) agregar un comando obsoleto en un método simplemente ingresando su nombre con el prefijo "_o_"; Se interpretará correctamente.

Una lista alfabetica de estos comando puede consultarse en el anexo Comandos obsoletos de Manual de lenguaje 4D.

Los siguientes comandos, anteriormente en desuso, han sido eliminados de 4D y no deben utilizarse en su código. Si se les llama, activarán un error (Error 33 - Comando o función no implementado).

Atención: las funcionalidades de verificación de sintaxis o compilación no pueden detectar las llamadas a los comandos eliminados. Debe verificar su código para asegurarse de que no contenga ninguna llamada a los comandos eliminados.

A partir de 4D v19, el plug-in 4D ODBC Pro ya no está disponible en todas las plataformas. Recomendamos utilizar el pass-trough integrado ODBC/SQL (ver SQL LOGIN y Presentación de los comandos del tema SQL) o la API REST 4D para manejar las funciones de conectividad ODBC/SQL.

A partir de 4D v19, el plug-in 4D for OCI ya no está disponible en macOS. Recomendamos utilizar el pass-through integrado ODBC/SQLL (ver SQL LOGIN y Presentación de los comandos del tema SQL) o la API REST 4D para manejar las funcionalidades de conectividad en esta plataforma.

A partir de 4D v19, el Driver 4D ODBC ya no está disponible en macOS. Recomendamos utilizar el API 4D REST para el acceso a datos externos en esta plataforma.

La opción de almacenamiento de archivos de datos externos ya no se soporta para los campos de tipo de objeto (ver Almacenamiento en el registro, en el archivo de datos, fuera del archivo de datos). Si se seleccionó esta opción para un campo objeto, se convierte automáticamente a En archivo de datos y se usa para nuevos registros. Los datos existentes en los campos objeto se reescriben de forma transparente en la nueva ubicación cuando se guarda el registro principal. Para forzar que todos los registros se reescriban a la vez, puede compactar el archivo de datos con la opción "Actualizar registros".

A partir de 4D v17 R4, los formularios de usuario están en desuso. Para ofrecer interfaces de usuario personalizables, ahora se recomienda utilizar formularios dinámicos (ver Formularios dinámicos en Manual de Diseño). Todos los comandos dentro del tema "Formularios de usuario" han quedado en desuso.

Los formularios de usuario aún son soportados por compatibilidad, sin embargo, ya no deben utilizarse. Su soporte será eliminado en futuras versiones.

En las versiones anteriores de 4D, el servidor web recopiaba automáticamente el valor de las variables enviadas a través de un formulario web o una URL en las variables 4D cuando tenían el mismo nombre.

Por razones de optimización y control, este principio no se mantiene a partir de 4D v14: el valor de las variables Web ya no se asigna automáticamente a las variables 4D. Para recuperar las variables enviadas utilizando un POST o un GET, debe utilizar el comando WEB GET VARIABLES exclusivamente.  Para recuperar las imágenes enviadas, debe utilizar los comandos WEB GET BODY PART/WEB Get body part count.

Nota: la asignación dinámica también está desactivada por defecto en las bases de datos 4D creadas a partir de la versión 13.4.

Sin embargo, por compatibilidad, este mecanismo se mantiene por defecto en las bases de datos creadas con una versión de 4D anterior a la 13.4. En este caso, se puede desactivar el uso de la opción de compatibilidad de asignación de variable automática en la página Compatibilidad de las Propiedades de la base.

Dado que este mecanismo es obsoleto, se recomienda desmarcar esta opción en sus bases de datos convertidas (y adaptar su código si es necesario) con el fin de facilitar futuras evoluciones.

En varias versiones principales, 4D ha advertido a los desarrolladores en contra del uso de las subtablas. Desde 4D v11, es imposible crear un campo del tipo subtabla. Los subregistros tienen algunas limitaciones conocidas. Por ejemplo, siempre se cargan en memoria; no se manejan por los comandos SEND RECORD o DUPLICATE RECORD.

No tenemos planes de eliminar el soporte para las subtablas en un futuro próximo, pero es realmente el momento de que los desarrolladores conviertan sus subtablas a tablas N-> regulares porque tenemos la intención de eliminarlas en una futura versión principal de 4D. Los desarrolladores que utilizan subtablas por razones de rendimiento (algunas situaciones específicas en las que la carga de los registros relacionados de era lenta) pueden estar tranquilos, especialmente con v12: utilizar las relaciones N <-> 1 clásicas es muy rápido.

Básicamente, hay dos formas principales para eliminar subtablas (nota: lo siguiente no es una tecnología completa de punta; sólo una visión general rápida):

• Antes de la conversión de una estructura pre-v11: en 2004, crear la tabla N apropiada y el campo ID en la tabla 1 (si no está ya allí). Luego, cambie el código en todas las partes es necesario (ver más adelante).
• Después de la conversión: en esta situación, 4D ha reemplazado la subtabla con una tabla N usando una relación especial, que permite que el lenguaje para trabajar con la subselección y los subregistros. El desarrollador 4D necesita eliminar esta relación especial, sustituirla por una relación normal y cambiar el código por todas partes si es necesario (ver más adelante).

Lo que queremos decir con "cambiar el código por todas partes si es necesario" es, básicamente:

• Crear los nuevos formularios, actualizar los formularios incluidos
• En los métodos (proyecto, formulario, objeto, etc.):
  • Remplace todos los comandos del tema "Subregistros" con el comando Selection o Record correspondiente (por ejemplo, reemplazar CREATE SUBRECORD con CREATE RECORD, llenando los campos ID)
  • Explícitamente cargar los registros N cuando sea necesario

Nota: a partir de 4D v14 R3, puede asignar valores a los campos "id_added_by_converter" especiales que se agregan automáticamente por 4D cuando convierte una base de datos que contiene subtablas. Esto le permite mantener el enlace "relación subtabla", y agregar o modificar registros relacionados, sin necesidad de usar comandos en desuso tales como _o_CREATE SUBRECORD. Una vez que haya actualizado sus métodos, estas relaciones especiales pueden ser sustituidas por otros estándares con ningún cambio en su código.

A partir de 4D v16 R6, las APIs basadas en Mac OS 9 para la administración de archivos y carpetas están en desuso en 4D. Estas API ya han quedado obsoletas por Apple desde hace mucho tiempo.

Los comandos 4D que dependen de las antiguas API se han renombrado: _o_Document type, _o_Document creator, _o_SET DOCUMENT TYPE, _o_SET DOCUMENT CREATOR y _o_MAP FILE TYPES.  Estos comandos se mantienen por compatibilidad, pero están en desuso y ya no deben utilizarse. 4D incluye dos nuevos comandos para manejar nombres de rutas y extensiones de archivos: Path to object y Object to path.

Las acciones estándar han sido rediseñadas internamente en 4D v16 R3. Ahora se basan en patrones de cadena y parámetros de soporte (para más información, consulte la sección Acciones estándar).

En las aplicaciones convertidas, las acciones estándar se vuelcan de forma transparente al nuevo diseño. Sin embargo, en el lenguaje 4D, las acciones estándar se basaban previamente en valores de código. Este principio es obsoleto y no debe utilizarse:

• Las acciones estándar de texto basadas en código en el tema constante Acción estándar (anteriormente llamadas "Valores de texto para acción estándar asociada") están prefijadas con "_o_" y ya no deben utilizarse.
• Todo el tema constante Valores para acción estándar asociada es obsoleto.
• El comando _o_OBJECT Get action (devuelve un código) es obsoleto y ha sido reemplazado por el comando OBJECT Get action  actualizado (que devuelve un nombre).

Esta es otra antigua tecnología Mac OS, en desuso desde Mac OS X 10.4 (Tiger, 2005). Los recursos se utilizan para almacenar datos estructurados, como texto y cadenas (localización), así como también iconos, etc. Básicamente, podemos decir que no son los recursos los que están en desuso, es su soporte en disco, conocido como el resource fork. El resource fork es parte del sistema de archivos de Mac OS y desde el inicio de Mac OS X, Apple ha tratado de eliminar este soporte, ya que no es compatible con otros sistemas de archivos (Unix, Windows), y es la fuente de una gran cantidad de problemas cuando los archivos se transfieren a través de la red.

En Windows, este mecanismo se emula y y los recursos Mac residen en un archivo .RSR.

Pero aún así, incluso si aún hay APIs para manejar los recursos (y Mac OS maneja de forma transparente los recursos almacenados en un data fork), ya no se recomienda utilizar este viejo mecanismo por varias razones:

• Los textos y las cadenas son Mac-roman. No se puede almacenar Unicode en recursos de tipo TEXT o STR#
• Los recursos PICT almacenan PICTs: no es moderno, obsoleto, sin transparencia, etc. (Consulte el tema "PICT" arriba.)
• El conteo de los recursos y el tamaño de los recursos son limitados (unos 2.700 recursos o 16 MB)

Hemos eliminado soporte para comandos de escritura/creación de recursos

La gran mayoría de las aplicaciones 4D que utilizan recursos están, de hecho, utilizando recursos "Strings List", 'STR#'. 4D ofrece las herramientas para cambiar fácilmente del STR # a XLIFF:

• El componente 4D Pop puede crear automáticamente los archivos XLIFF mediante la lectura y transferir el contenido de la STR #.
• Todas las rutinas y las expresiones que hacen referencia a trabajo STR# sin cambio con XLIFF. Por ejemplo, si la etiqueta de un botón o un menú era ":15000,3" (que significa "conseguir el tercer elemento de STR# ID 15000"), 4D cargará el XLIFF apropiado (si existe).

Para otros tipos de recursos:

• Poner los recursos en archivos separados dentro de la carpeta Resources (crear subdirectorios si es necesario):
  • Guardar recursos 'TEXT' en archivos XLIFF o .txt
  • Guardar recursos 'PICT' como archivos .jpg/.png/etc. separado
  • Guardar recursos 'PICT' + MASK’ como archivos png
  • Utilizar (en Mac) icns en lugar de ICON o iconos de colores
  • Guardar todos los recursos privados como sea apropiado para usted (normalmente: guardar como un archivo binario con una extensión específica)
• Utilice la carpeta "Recursos" para almacenar sus recursos. Utilice Get 4D folder (carpeta de recursos actuales) para obtener dinámicamente la ruta padre para sus recursos.