Funcionalidades obsoletas o eliminadas

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”:

• Eliminado: ya no está disponible en la versión actual (o la versión indicada).
• Obsoleto: ya no se debe utilizar y se eliminará en una futura versión principal.
• OS: depende de tecnologías OS oficialmente obsoletas (por ejemplo: formato PICT). Este Estado es identico al estado Obsoleto, pero un sistema operativo podría retirar el soporte antes que nosotros.

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.

Los proyectos representan una importante evolución de la arquitectura de bases 4D. Dado que los proyectos 4D se basan en los últimos requisitos de interfaz de software y en las tecnologías más modernas, no admiten algunas características heredadas. Estas características ahora están en desuso y ya no deben utilizarse en sus bases, para un mejor cumplimiento de la arquitectura proyecto.

Para información detallada en la arquitectura proyecto en 4D, ver la documentación de proyectos 4D en developer.4d.com). 4D ofrece una herramienta de exportación automática para convertir bases de datos .4db a proyectos. Durante la exportación, las funciones en desuso se convierten, eliminan o generan errores automáticamente (ver Convertir bases en proyectos).

Los siguientes objetos y propiedades de formulario no cumplen con los requisitos actuales de la interfaz y ahora están en desuso. No se soportan en Formularios dinámicos, y podrían generar una advertencia o un error en el archivo de registro de conversión del proyecto (ver comentarios).

Las siguientes opciones de estructura de la base de datos están en desuso y se editarán o generarán errores en el archivo de registro de conversión del proyecto (ver comentarios).

Los siguientes editores y funcionalidades de Caja de herramientas están en desuso y no son soportados en proyectos:

Los modos de compatibilidad heredados no son soportados en proyectos. Las configuraciones de compatibilidad se restablecen para una nueva base de datos durante la exportación al proyecto. Si su base aún se basa en configuraciones de compatibilidad antiguas, debe considerar actualizarla.

Le recomendamos que lea la serie de publicaciones de blog dedicadas a cómo deshacerse de la configuración de compatibilidad.

A partir de 4D v17 R5, las versiones 32 bits de 4D ya no se producen o entregan. Solo están disponibles las versiones 64 bits, lo que permite a las aplicaciones 4D aprovechar al máximo esta poderosa arquitectura.

Aunque las versiones 64 bits admiten la mayoría de las funcionalidades 4D heredadas, favorecen las tecnologías más recientes y no admiten las que se han declarado obsoletas en versiones anteriores. La actualización de las bases desarrolladas para versiones 32 bits puede requerir algunas adaptaciones:

• Para obtener una lista de las funcionalidades heredadas que no se admiten en 4D v18, consulte la página Quick table de este manual.
• Para adaptar sus bases de datos, consulte la página "Cambio de 32 bits a 64 bits" en el manual Conversión a v17.

XSLT no está disponible en 4D. Llamar un comando XSLT generará un error 33 "Comando o función no implementado".

Para soportar a nuestros clientes que siguen utilizando XSLT en 4D, elegimos confiar en la librería XSL PHP, que ofrece una completa API que le permite realizar todas las operaciones necesarias para sus transformaciones XSL. Esta librería es una herramienta eficaz que puede sustituir fácilmente los comandos o_XSLT APPLY TRANSFORMATION, _o_XSLT SET PARAMETER y_o_XSLT GET ERROR después de su eliminación. 4D ha producido un documento específico para ayudarle a utilizar PHP XSL como un reemplazo para los comandos XSLT de 4D:  Descarga XSLT con el documento técnico PHP (PDF).

También le sugerimos que considere el uso de etiquetas 4D cuando se trata de la generación dinámica de páginas HTML, ya que en la mayoría de los casos es más fácil si maneja código HTML como texto sin formato (ver también el comando PROCESS 4D TAGS).

El soporte para QuickTime (vía los parámetros de la base) se eliminó de 4D a partir de la v17 R5. Los codecs de imagen relacionados con QuickTime ya no son soportados en macOS y Windows.

A partir de la v18, el tipo de campo de datos flotantes ya no es compatible con la base 4D. Este tipo de campo solo era utilizado por el motor SQL de 4D. Si su base estaba utilizando un campo Tipo flotante, se convierte automáticamente en Tipo real cuando la base se abre en v18 o superior. Los datos existentes no se convierten, a menos que compacte los datos o vuelva a guardar registros.

El soporte al modo ASCII (sinónimo de "modo no Unicode") se eliminó a partir de 4D v17 R5 y superiores. Al abrir una base de datos convertida que no se definió en Unicode, 4D muestra el siguiente cuadro de diálogo de alerta:

Esta alerta se mostrará en cada inicio mientras que la opción de modo Unicode no esté marcada en la página "Compatibilidad" de la configuración de la base. Debe, para las estructuras convertidas, activar el modo Unicode. El documento PDF Conversión a 4D v14 brinda sugerencias sobre este tema.

El formato PICT(en desuso por Apple desde 2005) ya no se soporta en 4D a partir de v17 R5. Esto significa que las imágenes en formato PICT no pueden renderizarse de ninguna manera, deben convertirse.
Utilice el comando GET PICTURE FORMATS para detectar y filtrar imágenes utilizando el formato PICT en su archivo de datos.

Ya no se admite el modo de despliegue específico para aplicaciones 4D monopuesto en la plataforma mac utilizando una llave DatabaseOutsidePackage en info.plist. A partir de 4D v17 R5, la llave DatabaseOutsidePackage se ignora.

En cuanto a 4D v17 R4, 4D ya no ofrece soporte específico para interfaces de derecha a izquierda en Windows. Las opciones correspondientes ya no están disponibles en la configuración de la base de datos o en las propiedades del formulario. En las bases de datos convertidas, la configuración de derecha a izquierda se ignorará en el momento de la ejecución.

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.

La funcionalidad 4D Mobile está en desuso a partir de 4D v18 y ya no se debe utilizar. El acceso a los datos 4D a través de solicitudes REST ahora es soportado por la tecnología ORDA y el servidor 4D REST.

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.

El uso de números de identificación QuickDraw para designar fuentes es obsoleto y no debe ser utilizarse más. Los comandos  y _o_Font name se conservan en 4D v15 y superiores por compatibilidad, pero se eliminarán en versiones posteriores. El comando OBJECT SET FONT ahora sólo acepta nombres de fuentes.

Hay dos tipos de plug-ins: los que utilizan el nuevo plug-in API y los que siguen utilizando el viejo (con QuickDraw). Para los plug-ins que utilizan la vieja caja de herramientas (con QuickDraw): para mantener la compatibilidad, el dibujo/renderización ya no se realiza directamente en un puerto QuickDraw, como en las versiones anteriores, pero en su lugar a través de un área GWorld QuickDraw offscreen dedicada al plugin.

En consecuencia, hay que respetar algunas reglas, como los plug-ins no deben modificar el puerto actual definido por el contenedor (objeto formulario).

Para los plug-ins que utilizan la nueva caja de herramientas: sólo se utiliza esta nueva caja de herramientas y no QuickDraw: (ver https://github.com/4D/4D-Plugin-SDK).

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.

Modificar la prioridad de la CPU es un ajuste obsoleto. La gestión de memoria para las aplicaciones 4D se ha optimizado en las diferentes versiones y es innecesaria e incluso puede ser contraproducente modificar los ajustes predeterminados. Como resultado:

• El área "Prioridad de la CPU" (página "General" de la Configuración de base de datos) se muestra ahora sólo en las bases de datos convertidas en las que previamente se ha establecido un valor personalizado. Se recomienda hacer clic en el botón Configuración por defecto en este caso para reiniciar estos parámetros y eliminarlos del diálogo. 
• A partir de 4D v16 R2, los selectores obsoletos del comando SET DATABASE PARAMETER han sido renombrados (_o_4D Remote mode scheduler, _o_4D Local mode scheduler y _o_4D Server scheduler) y ya no se deben utilizar.