Quando una soluzione sfida il tempo (e tu giochi contro il banco)

Lo scenario

Anni fa (correva la versione 8.5, poi aggiornata alla 9 in corso d’opera) mi sono cimentato in un compito comune a molti sviluppatori della vecchia guardia: la creazione di un gestionale per studio dentistico. A parte il consueto flusso dei dati comune a tutte le realtà del genere, che in sostanza si svolge seconde le consuete prassi:

amministrativa: paziente -> anamnesi-> ciclo di cura -> preventivo -> operazione -> fattura acconto -> fattura saldo

operativa: inserimento operazione -> cambio stato -> diario clinico -> gestione immagini

questa specifica installazione aveva un requisito molto speciale.

La schermata Parodontale, infatti aveva delle richieste molto specifiche:

• Dovevano essere mostrate le operazioni effettuate su tutti i denti, sui quadranti, sestanti, le due arcate palatali e l’intero cavo orale. Le sole operazioni di pulizia dovevano essere evidenziate in una colonna a lato, in ordine di data.
• Le operazioni effettuate dovevano essere identificate per sigla, icona e colore (che ne identifica lo stato).
• I denti dovevano essere identificati mediante numero e colore (con le relative modifiche in caso di mancanti o decidui)
• A seconda di quale procedura l’utente stesse effettuando (selezionata con un clic in combinazione con la pressione di un tasto) doveva apparire una diversa interfaccia di caricamento/modifica operazione (per icona, sigla, categoria, etc).
• Nel caso NON ci fossero procedure specifiche selezionate, semplicemente  passando il mouse sulla sigla di una qualunque operazione effettuata (quindi presente nella schermata Parodontale), dovevano esserne mostrate le specifiche (descrizione, stato, operatore, importo, sala…), A MENO CHE non fosse già stata selezionata una operazione mediante  clic
• Ovviamente non dovevano verificarsi fastidiosi fenomeni di refresh sulla schermata (cosa che escludeva la possibilità di più di 50 portali concorrenti).

Come era prevedibile, la soddisfazione di queste specifiche ci ha portato più tempo che la realizzazione del resto del gestionale. Vediamo come abbiamo proceduto (notare l’interfaccia stile anni 80, con le icone gelosamente specificate dal dottore, che ci era abituato e molto affezionato).

L'intervento

Per evitare l’effetto refresh abbiamo utilizzato dei campi multipli al posto dei portali, che mostrano le sigle (e i colori) delle ultime 8 operazioni effettuate su ciascun dente, quadrante, etc.  Le operazioni sono ovviamente in una tabella correlata, quindi i campi multipli servono solo come visualizzazione. I campi multipli invece dei portali per visualizzare i dati è una soluzione interessante che utilizzavamo spesso (anche se dalla versione 14 è sostituita frequentemente dalla barra pulsanti), quindi non una sfida particolare: oltre alle procedure di visualizzazione mi sono limitato ad aggiungere due pulsanti per ciascuna colonna per scorrere (in su e giù) eventuali operazioni non comprese nelle 8 mostrate, semplicemente cambiando il record correlato visualizzato nelle varie ripetizioni del campo. 

La croce del problema è stata ovviamente l’effetto on-mouse-over sulle singole operazioni - per mostrare le informazioni dell’operazione su cui il puntatore via via passava, SENZA che l’utente dovesse cliccare. L’unico modo per gestirla era (ed è) utilizzare l’opzione testo descrizione sulle singole ripetizioni per mostrare le informazioni, mediante il componente dell’OS che mostra gli hint degli oggetti su cui il mouse si sofferma.

Ma… questo tipo di approccio non era soddisfacente in quanto limitato, sia come informazioni che come tempo di apparizione dell’hint.

 A questo punto, l’unico modo era utilizzare un plugin che lanciasse uno script utilizzando l’opzione testo descrizione come un calcolo: in questo modo è possibile mostrare e gestire le informazioni in maniera molto più precisa. Al momento dello sviluppo esistevano vari plugin, ma la scelta su quelli che fossero a) gratuiti e b) multipiattaforma era molto più ristretta: EventScript e ZippScript.
Per primo è stato preso in esame EventScript, per poi migrare a ZippScript per problemi di stabilità. E il tutto funzionava in maniera impeccabile… su Windows, meno su Mac OSX.

Questo non per colpa di FileMaker: il problema è che il componente dell’OS a cui si appoggiava all'epoca l’opzione di FileMaker (poi per fortuna le cose sono cambiate, come abbiamo descritto in un laboratorio di sviluppo) faceva parte appunto… dell’OS . Quindi il modo in cui Windows e Mac OSX mostrano gli hint cambiava (anche fra le varie versioni dello stesso OS): e su Mac OSX il delay nella visualizzazione degli hint (e quindi fra il tocco del puntatore e il lancio dello script) è maggiore rispetto a Windows. Ne è risultata comunque una piccola imperfezione, certamente non bloccante, e il sistema ha funzionato senza nemmeno una modifica per dieci anni.

Apparentemente, sembra uno di quei casi in cui abbiamo approfittato di una serie di funzioni non ben documentate per ottenere un risultato apparentemente impossibile. Però… dopo 10 anni abbiamo dovuto aggiornare il sistema. All’inizio pensavamo fosse una cosa semplice: conversione del file al nuovo formato, qualche piccola modifica e via. E subito è emerso il primo problema: zippScript non è più disponibile. Anche a utilizzare l'ultima versione in archivio - vecchia di anni e fuori supporto - rimane un plugin a 32 bit, il che significa che su Mac OSX non gira su nessuna versione superiore alla 13, mentre su Windows è necessario utilizzare le versioni FileMaker Pro (Advanced) a 32 Bit (e comunque non è possibile utilizzarlo oltre la 17). Poco male, mettiamo la versione 32 bit, dato che al momento serve solo su Windows. Abbiamo comunque dovuto pianificare in futuro la riscrittura di tutte le procedure basate su ZippScript: almeno un giorno di lavoro fuori preventivo. 

Convertiamo tutto e iniziamo i test su Windows e… parecchie funzioni non vanno. Dopo alcuni test, decidiamo di partire dalla base per capire esattamente il problema; andiamo quindi di retrocompatibilità.
Non potendo installare FileMaker Pro Advanced 9 (era la versione per cui serviva l’attivazione mediante server – non più attivo -  e/o servizio telefonico sostitutivo,  al momento lunga da ottenere essendo fuori procedura da anni), installiamo FileMaker Pro Advanced 11, così da utilizzare il file originale e capire dov’è il problema. Certi che tutto vada bene apriamo il file e… i malfunzionamenti del file aggiornato avvengono in maniera identica anche sul file originale con la versione 11. 

Il problema

A questo punto si accende la lampadina: fra la versione 9 e la versione 11 uno dei più grandi cambiamenti è l’introduzione degli script trigger. Ovviamente l’avevamo considerato, ma dato che il plugin lancia gli script a livello di motore di calcolo, mentre gli script trigger di FileMaker agiscono a livello di interfaccia, ritenevamo che le due gestioni non interferissero fra loro. E in effetti non lo fanno… direttamente.

Tuttavia, l’introduzione dei trigger a livello di interfaccia ha comportato alcune modifiche su come il motore di calcolo valuta il lancio degli script in base alle azioni degli utenti, e questo ha fatto si che il metodo utilizzato per l’on-mouse-over bloccasse alcune procedure, cancellando al momento sbagliato l’ID dell’operazione in esame, e quindi bloccando il proseguimento. 
Capito il problema, la risoluzione ha richiesto qualche decina di righe di script in tutto. Riportate le modifiche sul file convertito, il tutto funziona su Windows, mentre su Mac l’opzione on-mouse-over non è attiva. 

Considerazioni finali

Quindi tutto bene?
Ni. L'applicativo funziona bene (su Windows), ed è aggiornato. Il plugin rimane una incognita e funziona solo a 32 bit, quindi non possiamo aggiornare FileMaker oltre la versione 16/17. Sicuramente un problema risolvibile, ma comporta la migrazione di tutte le istanze interessate a un altro plugin (MBS, BaseElements…). Infine, l’intervento si è concluso in flagrante remissione, dato che ci abbiamo messo il triplo per previsto (e preventivato) e dobbiamo comunque ancora riscrivere la parte OSX.

Cosa abbiamo imparato:

• La scelta del plugin: Avessimo usato a suo tempo un plugin commerciale (o uno con un supporto migliore) non avremmo dovuto riscrivere le procedure (anche a costo di dover aggiornare la licenza).
• Gli aggiornamenti che Claris effettua sul motore di calcolo fra le varie versioni sono in buona parte trasparenti agli utenti. Ma comunque impattano diverse aree e possono avere effetto su caratteristiche che sembrano completamente scollegate.
• Mentre anni fa lo sviluppo tecnologico era più lento, la maggiore integrazione e complessità del mondo tecnologico fa molti meno "sconti" allo sviluppatore: ogni scelta va considerata non solo per come funziona nell'immediato ma anche per come potrà comportarsi in futuro.
  
  Da cui si desume che:
• L'utilizzo di caratteristiche o funzioni in maniera non documentata porta quasi sempre problemi nelle versioni successive: Il "giocare contro il banco" alla fine porta qusi sempre lavoro in più, o comunque delle situazioni non previste da gestire (e documentazione da produrre, ad uso interno ed esterno) . Nulla di male, ma va sempre considerato in fase di preventivo o assistenza su un prodotto.

E tu, hai qualche soluzione creata anni fa che ti da gli incubi al pensiero di doverla aggiornare?

Se ti serve aiuto per una consulenza o aggiornare la tua soluzione FileMaker ci trovi sul FileMaker Guru Corner, il nostro forum e nella nostra meravigliosa community Facebook FileMaker Developer Italia dove facciamo assistenza gratuitamente. Se invece hai bisogno di un preventivo per una consulenza, mandaci una email (team@fmguru.it)!