Impostazioni di compatibilità – Utilizzare il punto e la virgola come segnaposto (parte 2)

Abbiamo iniziato una serie di post sul blog dedicati alle impostazioni di compatibilità e alle opzioni segrete che possono aiutare drasticamente a migliorare le prestazioni e il comportamento delle applicazioni. Il primo post riguardava QUERY BY FORMULA.

La seconda parte della serie sulla compatibilità riguarda l’utilizzo internazionale delle vostre applicazioni aziendali. Ciò potrebbe significare vendere in altri Paesi o avere colleghi che vengono da altri Paesi per lavorare per un po’, ma utilizzando i loro sistemi locali.

Se avete mai visto o ricevuto segnalazioni del tipo “i numeri sono visualizzati come >>>>>>>>>”, questo blog post è per voi.

Non siete sicuri di come verranno visualizzati i vostri numeri? Controllate le impostazioni del database:

Se l’opzione di cui sopra è già abilitata o non viene visualizzata affatto (applicazioni create con 4D v11 o successive), tutto va bene e non è necessario leggere oltre.

Come dovrebbe funzionare

Lo sviluppatore di 4D progetta per un uso internazionale, mentre l’utente finale può utilizzare qualsiasi impostazione regionale, anche mista in modalità client/server.

Esempio: “###,##0.00” visualizzato in Germania come “1.234,56”, negli USA come “1.234,56”, in Svizzera come “1’234,56”.

Come funzionava una volta (modalità compatibilità)

Lo sviluppatore di 4D progettava per una determinata impostazione regionale (di solito quella locale) e l’utente finale doveva avere esattamente le stesse impostazioni.

Esempio: “###,##0.00” visualizzato in Germania come “>>>>>>>>”, negli USA come “1.234,56”, in Svizzera come “>>>>>>>>>”.

come funziona ora (Sviluppo internazionale)

Nelle ultime versioni di 4D, tutti i metodi di 4D sono in formato internazionale:

• Un valore numerico costante è definito utilizzando un punto come delimitatore decimale internazionale (ad esempio, 5,3).
• Le date sono definite utilizzando il formato internazionale “yyyy-mm-dd” (2018-07-31). Si noti il “-” usato come delimitatore e l’ordine di Anno/Mese/Giorno.
• Gli orari sono definiti nel formato 24 ore.

Non appena il valore viene visualizzato (o formattato), vengono utilizzate le impostazioni regionali correnti.

Ad esempio, sto scrivendo questo post su un sistema tedesco, quindi String(!2018-07-31!) risulta “31.07.2018” e String(5.3) risulta ” 5,3“. Risultati diversi con impostazioni regionali diverse, per la stessa applicazione.

Questo richiede un cambiamento di mentalità per gli sviluppatori di lunga data, ma come risultato si ottengono applicazioni funzionanti a livello internazionale senza ulteriori sforzi.

Suggerimenti per la migrazione

Per modificare il comportamento delle impostazioni regionali, è necessario cambiare tutti i punti in cui le impostazioni locali sono codificate. Questa potrebbe essere una missione quasi impossibile. Ecco perché esiste un’opzione di compatibilità e perché è impostata su “compatibile” per impostazione predefinita.

Ma c’è molto da guadagnare, quindi vediamo quanto è difficile.

Costanti codificate in modo rigido nei metodi

Buone notizie! Non c’è nulla da fare. Quando create un metodo 4D in v2004 e scrivete $i:=5,3 (sistema tedesco) e aprite quel metodo in 4D v16 o più recente, vedrete $i:=5,3.

Lo stesso vale per le date e gli orari. Problema risolto!

Utilizzo dei formati numerici – filtri.

Sebbene 4D consenta la codifica dei formati (adesempio, “###.##0,00“) nei metodi o nei moduli, lo sconsigliamo da oltre 20 anni.

Se avete usato i filtri ovunque, cambiarli sarà estremamente facile. Si possono avere 5 o 10 filtri, ma probabilmente non più di 20. Dovrete quindi modificare i filtri dal formato locale a quello internazionale(cioè utilizzando i punti (“.”) per i decimali e le virgole (“,”) per il separatore delle migliaia).

Una volta terminato, attivate la casella di controllo della compatibilità e il gioco è fatto!

Come trovare i filtri codificati nei metodi

Questo passo non è facile come quelli menzionati sopra. Sebbene abbiate usato dei filtri nelle vostre applicazioni, potreste non essere certi di aver saltato (occasionalmente) i filtri e di aver creato del codice “quick & dirty” in alcuni casi.

Esempio:

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

Come trovarli?

Dato che non ci sono molti formati diversi, è semplice!

##0 ^^^0 0,00 ***0 sono formati tipici. È necessaria solo una parte (il più possibile unica) del formato. Se trovate uno di questi frammenti di testo nei vostri metodi, è molto probabile che siano codificati. Utilizzate lo strumento Trova in modalità progettazione per cercare questi frammenti di codice e sfogliate i risultati.

Se ne trovate solo alcuni, esaminateli manualmente e sostituiteli con dei filtri, come ad esempio:

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

Se ne trovate molti, sfogliateli manualmente e verificate che la condizione di ricerca sia corretta. Se necessario, perfezionatela.

Potrebbe essere necessario un po’ di lavoro, ma si riuscirà a definire alcuni schemi per gestire la maggior parte dei casi. Questi schemi dovrebbero consentire un’operazione di “ricerca e sostituzione” automatica.

A seconda dell’impegno richiesto, si potrebbe anche scrivere un metodo per eseguire una ricerca nel codice al posto dell’utente, utilizzando i metodi METHOD GET CODE e METHOD SET CODE e.

Come trovare tutti i filtri codificati nei moduli

4D non fornisce un’opzione di ricerca per i moduli, quindi non è possibile verificare automaticamente la presenza di formati codificati. Ma dato che siamo sviluppatori, possiamo farlo noi stessi…

Per prima cosa, dovremo ottenere un elenco di tutti i moduli per tutte le tabelle e scorrerli. Poi, per ogni modulo, otterremo un elenco di tutti gli oggetti e faremo un ciclo anche su di essi. Infine, per ogni oggetto, controlleremo se utilizza un formato numerico e, in caso affermativo, vedremo se è codificato in modo rigido. In caso affermativo, lo segnaleremo.

La buona notizia: questo codice fornirà un elenco simile all’opzione Trova in modalità progettazione per i metodi. La cattiva notizia è che dovrete aprire ogni risultato e assegnare manualmente il formato, quindi potrebbe volerci un po’ di 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 arrObjNames($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;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 :=Oggetto Get format(*;arrObjNames{$i})
If (($format#") & (($format#"|@")))
If (($format="@,@")|($format="@.@"))
$report :=$report+$arr_Names{$forms}+char(9)+"nome oggetto: "+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 :="Tutto bene!"
End if

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

ordine delle operazioni

Nell’applicazione corrente:

• Controllare i filtri e crearne di nuovi (se necessario).
• Lasciare che tutti i filtri continuino a usare le impostazioni regionali… nessuna modifica!
• Modificare tutti i metodi e i moduli per utilizzare i filtri
• Distribuire

Allo stesso tempo, con una copia della vostra applicazione:

• Sia internamente che per beta tester selezionati:
  • Cambiare i filtri per utilizzare il formato internazionale
  • Attivare la casella di controllo della compatibilità
  • Compilare e distribuire per i tester per diverse settimane
  • Una volta che tutto è stato testato e verificato, distribuire per tutti (sostituire l’esistente)

Comandi correlati

Anche se in quasi tutti i casi si desidera che i numeri siano formattati in base alle impostazioni regionali, ci sono alcune eccezioni. Ad esempio, si possono usare regole diverse quando si importano o esportano dati. Dipende da chi utilizzerà o da chi ha fornito i dati. Un altro esempio sono i dati in formato XML o JSON, che utilizzano sempre un punto (“.”) come separatore decimale.

Il vostro compito è solo quello di gestire queste eccezioni, non il comportamento normale.

Per convertire un numero in stringa utilizzando un punto come separatore decimale, in qualsiasi parte del mondo, indipendentemente dalle impostazioni regionali dell’utente, utilizzare:

String($mynumber; "&xml")

Nota: anche il formato è denominato XML, quindi può essere utilizzato per qualsiasi caso d’uso, purché si voglia usare un punto come separatore decimale.

D’altra parte, quando si vuole analizzare una stringa e si sa che la stringa usa un punto come separatore decimale(perché è stata importata da un documento XML o JSON), usare:

Num($mystring;".")

Conclusione

Per le applicazioni più vecchie e consolidate può essere necessario un po’ di lavoro, ma il risultato è un’applicazione che può essere distribuita ovunque con formati numerici corretti. In questo modo si alleggerisce l’assistenza tecnica e si aiutano i clienti. È un vantaggio per tutti!