Ajustes de compatibilidad – Usar punto y coma como marcadores de posición (Parte 2)

Hemos iniciado una serie de entradas en el blog sobre los ajustes de compatibilidad y las opciones secretas que pueden ayudarle a mejorar drásticamente el rendimiento y el comportamiento de sus aplicaciones. El primer post fue sobre QUERY BY FORMULA.

La segunda parte de la serie de compatibilidad trata sobre el uso internacional de tus aplicaciones empresariales. Esto podría significar vender a otros países – o tener compañeros de trabajo que vienen de otros países a trabajar por un tiempo, pero usando sus sistemas locales.

Si alguna vez has visto o recibido informes como «los números se muestran como >>>>>>>>>», esta entrada del blog es para ti.

¿No estás seguro de cómo se mostrarán tus números? Comprueba la configuración de tu base de datos:

Si la opción anterior ya está habilitada o no se muestra en absoluto (aplicaciones creadas con 4D v11 o posterior), todo está bien y no hay necesidad de seguir leyendo.

Cómo debería funcionar

El desarrollador 4D diseña para un uso internacional, mientras que el usuario final puede utilizar cualquier configuración regional, incluso configuraciones mixtas en modo cliente/servidor.

Ejemplo: «###,##0.00» se muestra en Alemania como «1.234,56», en EEUU como «1,234.56», en Suiza como «1’234.56»

Cómo funcionaba antes (modo de compatibilidad)

El desarrollador de 4D diseñaba para una configuración regional determinada (normalmente la local) y el usuario final debía tener exactamente la misma configuración.

Ejemplo: «###,##0.00» se mostraba en Alemania como «>>>>>>>>», en Estados Unidos como «1.234.56», en Suiza como «>>>>>>>>>»

cómo funciona ahora (Desarrollando internationalLY)

En las últimas versiones de 4D, todo en los métodos de 4D está en formato internacional:

• Un valor numérico constante se define utilizando un punto como delimitador decimal internacional (por ejemplo, 5,3).
• Las fechas se definen utilizando el formato internacional «aaaa-mm-dd» (2018-07-31). Tenga en cuenta el «-» utilizado como delimitador y el orden del Año/Mes/Dia.
• Las horas se definen en formato de 24 horas.

En cuanto se muestra el valor (o se formatea), se utiliza la configuración regional actual.

Por ejemplo, estoy escribiendo esta entrada del blog en un sistema alemán, así que String(!2018-07-31!) da como resultado «31.07.2018» y String(5.3) da como resultado 5,3. Diferentes resultados con diferentes configuraciones regionales – para la misma aplicación.

Esto requiere un cambio de mentalidad para los desarrolladores de toda la vida, pero como resultado se obtienen aplicaciones que funcionan a nivel internacional sin esfuerzo adicional.

Consejos para la migración

Para cambiar el comportamiento de la configuración regional, es necesario cambiar cada lugar donde la configuración local está codificada. Esto podría ser una misión casi imposible. Por eso existe una opción de compatibilidad y está configurada como «compatible» por defecto.

Pero hay mucho que ganar, así que vamos a ver lo difícil que es realmente.

Constantes codificadas en los métodos

Buenas noticias. No hay nada que hacer. Cuando crea un método 4D en v2004 y escribe $i:=5,3 (sistema alemán) y abre ese método en 4D v16 o más reciente, verá $i:=5,3.

Es lo mismo para las fechas y las horas. ¡Problema resuelto!

Uso de formatos numéricos – filtros.

Si bien 4D permite la codificación de formatos duros(por ejemplo, «###.##0,00«) en métodos o formularios, lo hemos desaconsejado durante más de 20 años.

Si ha utilizado filtros en todas partes, cambiarlos será extremadamente fácil. Puede que tengas 5 o 10 filtros, pero probablemente no más de 20. Así que tendrás que modificar tus filtros de formato local a formato internacional(es decir, utilizando puntos («.») para los decimales y comas («,») para el separador de miles).

Una vez que haya terminado, active la casilla de compatibilidad y ¡ya está!

Cómo encontrar los filtros codificados en los métodos

Este paso no es tan fácil como los mencionados anteriormente. Si bien es posible que hayas utilizado filtros en tus aplicaciones, puede que no estés seguro de si (ocasionalmente) te has saltado los filtros y has creado código «rápido y sucio» en algunos casos.

Ejemplo:

$text:= String(5300; "### ##0") // to be used in Sweden with a space for thousands

¿Cómo encontrarlos?

Como no hay tantos formatos diferentes, es sencillo.

##0 ^^0 0,00 ***0 son los formatos típicos. Sólo se necesita una parte (lo más única posible) del formato. Si encuentra uno de estos fragmentos de texto en sus métodos, es muy probable que estén codificados. Utiliza la herramienta Buscar en el modo de diseño para buscar estos fragmentos de código y examina los resultados.

Si sólo encuentra unos pocos, revíselos manualmente y sustitúyalos por filtros, como por ejemplo

$text:= String(5300;"|mynumberformat") // vertical line before filter name

Si encuentra muchos, revíselos manualmente y compruebe que su condición de búsqueda es correcta. Ajústala si es necesario.

Puede que le cueste un poco de trabajo, pero podrá definir algunos patrones para manejar la mayoría de los casos. Estos patrones deberían permitir una operación automática de «buscar y reemplazar».

Dependiendo de la cantidad de esfuerzo que se requiera, incluso podría escribir un método que recorra su código y lo busque por usted, utilizando el método METHOD GET CODE y METHOD SET CODE y el comando.

Cómo encontrar todos los filtros codificados en los formularios

4D no proporciona una opción de búsqueda para los formularios, por lo que no puede comprobar automáticamente los formatos codificados en ellos. Pero como somos desarrolladores, podemos hacerlo nosotros mismos…

En primer lugar, tendremos que obtener una lista de todos los formularios para todas las tablas y hacer un bucle a través de ellos. Luego, para cada formulario, obtendremos una lista de todos los objetos y haremos un bucle a través de ellos, también. Y finalmente, para cada objeto, comprobaremos si utiliza un formato numérico y si lo hace, veremos si está codificado. Si lo está, lo informaremos.

La buena noticia: este código proporcionará una lista similar a la opción Buscar en el modo de diseño para los métodos. La mala noticia: tendrás que abrir cada resultado y asignar manualmente el formato, por lo que puede llevar algo de tiempo.

$report:=""
For ($table;0;Get last table number)
ARRAY TEXT ($arr_Names;0)

If ($table=0) // project forms
FORM GET NAMES ($arr_Names)
Else
If (Is table number valid($table))
FORM GET NAMES (Table($table)->;$arr_Names)
End if
End if

For ($forms;1;Size of array($arr_Names))
If ($table=0)
FORM LOAD ($arr_Names{$forms})
Else
FORM LOAD (Table($table)->;$arr_Names{$forms})
End if

FORM GET OBJECTS (arrObjNames;arrObjPtrs;arrPages;Form all pages)
For ($i;1;Size of array(arrObjNames))
$type :=OBJECT Get type(*;arrObjNames{$i})
If (($type=Object type text input) | ($type=Object type listbox column) \
| ($type=Object type listbox footer) | ($type=Object type static text))
$format :=OBJECT Get format(*;arrObjNames{$i})
If (($format#"") & (($format#"|@")))
If (($format="@,@")|($format="@.@")
$report :=$report+$arr_Names{$forms}+char(9)+"nombre del objeto: "+arrObjNames{$i}+char(9)+"formato: "+$format+char(13)
End if
End if
End if
End for
FORM UNLOAD
End for
End for

If ($report=")
$report :="¡Todo va bien!"
End if

ALERT ($report)
SET TEXT TO PASTEBOARD ($report)

orden de las operaciones

En su aplicación actual:

• Compruebe sus filtros y cree otros nuevos (si es necesario)
• Deje que todos los filtros sigan utilizando la configuración regional… ¡sin cambios todavía!
• Cambie todos los métodos y formularios para utilizar los filtros
• Despliegue

Al mismo tiempo, con una copia de su aplicación:

• Ya sea internamente o para probadores beta seleccionados:
  • Cambie los filtros para utilizar el formato internacional
  • Active la casilla de compatibilidad
  • Compilar y desplegar para los probadores durante varias semanas
  • Una vez que todo esté probado y verificado, despliegue para todo el mundo (sustituya lo existente)

Comandos relacionados

Aunque en casi todos los casos querrá que el formato de los números siga la configuración regional, hay algunas excepciones. Por ejemplo, puede utilizar reglas diferentes cuando importe o exporte datos. Depende de quién vaya a utilizar o de quién haya proporcionado los datos. Otro ejemplo son los datos en formato XML o JSON, que siempre utilizan un punto («.») como separador decimal.

Su trabajo es sólo para manejar estas excepciones, no el comportamiento normal.

Para convertir un número en cadena utilizando un punto como separador decimal, en cualquier parte del mundo, independientemente de la configuración regional del usuario, utilice

String($mynumber; "&xml")

Nota: Incluso el formato se llama XML, por lo que se puede utilizar para cualquier caso de uso, siempre que se quiera utilizar un punto como separador decimal.

Por otro lado, cuando quieras analizar una cadena y sepas que la cadena utiliza un punto como separador decimal(porque la has importado de un documento XML o JSON), utiliza

Num($mystring;".")

Conclusión

Para las aplicaciones más antiguas y bien establecidas, puede ser necesario un poco de trabajo, pero el resultado son aplicaciones que puedes desplegar en cualquier lugar con formatos numéricos correctos. Esto le quitará presión a su soporte técnico y también ayudará a sus clientes. Es una situación en la que todos ganan.