Definições de compatibilidade – Usar o período e a vírgula como marcadores de lugar (Parte 2)

Iniciámos uma série de posts em blogues sobre definições de compatibilidade e as opções secretas que podem ajudá-lo a melhorar drasticamente o desempenho e o comportamento das suas aplicações. O primeiro post foi sobre QUERY BY FORMULA.

A segunda parte da série de compatibilidade é sobre a utilização internacional das suas aplicações empresariais. Isto pode significar vender para outros países – ou ter colegas de trabalho vindos de outros países para trabalhar durante algum tempo, mas utilizando os seus sistemas locais.

Se alguma vez viu ou recebeu relatórios como “os números são exibidos como >>>>>>>>>”, este post no blogue é para si.

Não tem a certeza de como os seus números serão mostrados? Verifique as definições da sua base de dados:

Se a opção acima já estiver activada ou não for exibida (aplicações criadas com 4D v11 ou posterior), tudo está bem e não há necessidade de ler mais.

Como deve funcionar

O revelador 4D desenha para uso internacional, enquanto o utilizador final pode usar quaisquer configurações regionais, mesmo configurações mistas no modo cliente/servidor.

Exemplo: “####,##0.00” exibido na Alemanha como “1.234,56”, nos EUA como “1.234,56”, na Suíça como “1’234,56”.

Como costumava funcionar (modo de compatibilidade)

O revelador 4D concebido para uma dada configuração regional (geralmente a local) e o utilizador final precisava de ter exactamente as mesmas configurações.

Exemplo: “####,##0.00” exibido na Alemanha como “>>>>>>>>”, nos EUA como “1.234,56”, na Suíça como “>>>>>>>>>”.

como funciona agora (Developing internationalLY)

Nas versões 4D recentes, tudo nos métodos 4D está num formato internacional:

• Um valor numérico constante é definido usando um ponto como delimitador decimal internacional (por exemplo, 5,3).
• As datas são definidas usando o formato internacional “yyyy-mm-dd” (2018-07-31). Note o “-” utilizado como delimitador e a ordem do Ano/Mês/Dia.
• Os tempos são definidos no formato de 24 horas.

Assim que o valor é exibido (ou formatado), são utilizadas as definições regionais actuais.

Por exemplo, estou a escrever este post num sistema alemão, por isso String(!2018-07-31!) resulta em “31.07.2018” e String(5.3) resulta em 5,3. Resultados diferentes com configurações regionais diferentes – para a mesma aplicação.

Isto requer uma mudança de pensamento para os programadores de longa data, mas como resultado obtém-se aplicações de trabalho internacionais sem esforço extra.

Dicas de migração

Para alterar o comportamento das configurações regionais, é necessário alterar todos os locais onde as configurações locais são codificadas de forma rígida. Esta poderia ser uma missão quase impossível. É por isso que existe uma opção de compatibilidade e que está definida para “compatível” por defeito.

Mas há muito a ganhar, por isso vamos ver como é realmente difícil.

Constantes de codificação dura nos métodos

Boas notícias! Não há nada que possa fazer. Quando criar um método 4D em v2004 e escrever $i:=5,3 (sistema alemão) e abrir esse método em 4D v16 ou mais recente, verá $i:=5,3.

É o mesmo para datas e horas. Problema resolvido!

Usando formatos numéricos – filtros.

Enquanto que 4D permite formatos de codificação dura(i.e., “###.##0,00“) em métodos ou formas, há mais de 20 anos que aconselhamos a não o fazer.

Se tiver usado filtros em todo o lado, mudá-los será extremamente fácil. Poderá ter 5 ou 10 filtros, mas provavelmente não mais do que 20. Portanto, terá de modificar os seus filtros do formato local para o formato internacional(isto é, usando pontos (“.”) para decimais e vírgulas (“,”) para o separador de milhares).

Uma vez isso terminado, active a caixa de verificação de compatibilidade e já está!

Como encontrar filtros codificados nos métodos

Este passo não é tão fácil como os acima mencionados. Embora possa ter utilizado filtros nas suas aplicações, pode não ter a certeza se (ocasionalmente) saltou ou não os filtros e criou código “rápido e sujo” em alguns casos.

Exemplo:

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

Como encontrá-los?

Como não existem assim tantos formatos diferentes, é simples!

##0 ^^0 ^0 0,00 ***0 são formatos típicos. Apenas uma parte (a mais única possível) do formato é necessária. Se encontrar um destes fragmentos de texto nos seus métodos, é muito provável que sejam codificados de forma rígida. Use a ferramenta Encontrar no modo de desenho para procurar estes fragmentos de código e procurar os resultados.

Se encontrar apenas alguns, passe por eles manualmente e substitua-os por filtros, como por exemplo:

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

Se encontrar muito, navegue através deles manualmente e verifique se a sua condição de pesquisa estava correcta. Se necessário, aperfeiçoe a sua pesquisa.

Pode ser necessário algum trabalho, mas será capaz de definir alguns padrões para tratar da maioria dos casos. Estes padrões devem permitir uma operação automática de “pesquisa e substituição”.

Dependendo da quantidade de esforço necessário, pode até escrever um método para correr através do seu código e procurar por si, usando o METHOD GET CODE e METHOD SET CODE ordens.

Como encontrar todos os filtros codificados em formulários

4D não fornece uma opção de pesquisa de formulários, pelo que não se pode verificar automaticamente se existem formatos codificados nos mesmos. Mas como somos criadores, podemos fazer isso nós próprios …

Primeiro, teremos de obter uma lista de todos os formulários para todas as tabelas e passar por elas. Em seguida, para cada formulário, obteremos uma lista de todos os objectos e também um laço através deles. E finalmente, para cada objecto, verificaremos se ele usa um formato numérico e, se o fizer, veremos se está codificado. Se o for, comunicaremos a sua utilização.

A boa notícia: este código fornecerá uma lista semelhante à opção Encontrar em modo de desenho para métodos. A má notícia: terá de abrir cada resultado e atribuir manualmente o formato, pelo que poderá demorar algum tempo.

$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)+"nome do objecto: "+arrObjNames{$i}+char(9)+"formato:SET TEXT TO PASTEBOARD"+$format+char(13)
End if
End if FORM UNLOAD
End if

If
$report
End for End for

($report="")
$report :="Tudo está bem!"
End if

ALERT ($report) End for ( )

ordem de operações

Na sua candidatura actual:

• Verifique os seus filtros e crie novos (se necessário)
• Que todos os filtros continuem a utilizar definições regionais… ainda sem alterações!
• Alterar todos os métodos e formulários para utilizar filtros
• Implementar

Ao mesmo tempo, com uma cópia da sua candidatura:

• Seja internamente ou para testadores beta seleccionados:
  • Altere os filtros para utilizar o formato internacional
  • Activar a caixa de verificação de compatibilidade
  • Compilar e instalar para testadores durante várias semanas
  • Depois de tudo ter sido testado e verificado, destacar para todos (substituir o existente)

Comandos relacionados

Ainda que, em quase todos os casos, queira que os números sejam formatados para seguir as definições regionais, existem algumas excepções. Por exemplo, poderá usar regras diferentes quando importar ou exportar dados. Depende de quem irá utilizar ou de quem forneceu os dados. Outro exemplo são os dados em formato XML ou JSON, que usa sempre um ponto (“.”) como separador decimal.

O seu trabalho é apenas lidar com estas excepções, não com o comportamento normal.

Converter um número em cadeia usando um ponto como separador decimal, em qualquer parte do mundo, independentemente da configuração regional do utilizador, utilizar:

String($mynumber; "&xml")

Nota: Mesmo o formato é denominado XML, pelo que pode ser utilizado para qualquer caso de utilização, desde que se pretenda utilizar um ponto como separador decimal.

Por outro lado, quando quiser analisar uma cadeia de caracteres e souber que a cadeia usa um ponto como separador decimal(porque o importou de um documento XML ou JSON), use:

Num($mystring;".")

Conclusão “.

Para aplicações mais antigas e bem estabelecidas, pode ser necessário algum trabalho, mas resulta em aplicações que pode implementar em qualquer lugar com formatos numéricos correctos. Isto irá tirar a pressão do seu suporte técnico e ajudar os seus clientes, também. É uma vitória para todos!