In questi ultimi giorni mi sono imbattuto in una situazione strana di cui voglio mettere a conoscenza gli Unifacers. Negli ultimi mesi ho migrato il mio lavoro con Uniface su una nuova macchina (virtuale) W10. Ieri dovevo testare l’utilizzo di alcuni fonts di barcode e li ho installati ed utilizzati in pochi minuti su U9.6.08; quando ho migrato la stessa form su U9.7.01.G104 (la versione corrente) e ho modificato l’INI file per definire anche su questa versione i font logici che l’applicazione doveva utilizzare ho perso parecchio tempo per via di un sistema di protezione che Windows applica a tutte le applicazioni che vengono installate nelle directory “protette” e al registry di sistema. Tra queste sono (ovviamente) presenti:
– C:\Windows
– C:\Program Files
– C:\Program Files (x86)
Nel mio caso avevo installato le versioni di uso di Uniface nella directory “C:\Program Files (x86)”.

In breve: le modifiche che applicavo al file USYS.INI presente nella directory “C:\Program Files (x86)\<U97installDir>\uniface\adm” NON venivano riconosciute dall’ambiente di sviluppo di Uniface eseguendo il programma con la mia normale utenza Windows (Gianni); le form che facevano riferimento ai font logici inseriti nel file usys.ini all’atto della compilazione non risultavano contenere il riferimento a tali font logici perché NON erano visti dall’ambiente di sviluppo.

Dopo aver perso un pò di tempo e aver scambiato qualche chiacchiera con il supporto ad A’dam la luce si è cominciata a schiarire quando lanciando l’ambiente di sviluppo con l’opzione “Run as Administrator” ho visto utilizzata la copia aggiornata del file usys.ini mentre lanciandolo senza questa opzione vedevo utilizzata una copia vecchia del medesimo file.

La chiave di lettura di questo caso si chiama UAC ed il suo “Virtual Store”: sulle directory protette, in determinate condizioni, Windows permette ad un utente, NON abilitato al pieno accesso ad una specifica risorsa, di svolgere una certa funzione accedendo alla sua versione “dedicata” di quella risorsa e non a quella reale, corrente salvata su disco. Tale versione “dedicata” della risorsa protetta viene salvata nel “Virtual Store”.

In pratica: nella directory di installazione di Uniface c’era il mio file usys.ini aggiornato con i miei font logici definiti; nella directory “C:\Users\<UserName>\AppData\Local\VirtualStore” e ramo sottostante c’era la copia vecchia del file usys.ini salvata all’atto della modifica del file con definizione dei font logici necessari. Se eseguivo IDF come Administrator accedevo alla copia di usys.ini aggiornata mentre se eseguivo IDF come Gianni accedevo alla copia vecchia di usys.ini salvata nel “Virtual Store”.

Eliminando il file usys.ini salvato da Windows nel “Virtual Store” per “proteggersi” e “proteggermi” ho risolto il problema…

Al momento la soluzione più banale è quella di installare Uniface in una directory che NON sia tra quelle “protette” da Windows… 😉

Il problema verrà definitivamente superato in una prossima release di Uniface con una modifica alla distribuzione e installazione del prodotto che renderà Uniface più adeguato alle ultime regole dettate da Microsoft per l’ecosistema Windows.

P.S. La virtualizzazione del registry di sistema funziona in modo analogo ma riguarda le chiavi del sottoalbero HKEY_LOCAL_MACHINE\SOFTWARE. In mancanza dei diritti di amministratore gli aggiornamenti delle chiavi e dei dati di questo sottoalbero vengono reindirizzati alla sottochiave HKEY_CURRENT_USER\Software\Classes\VirtualStore.

More info a questa pagina.

La settimana scorsa durante un’attività formativa mi sono stati chiesti lumi su una funzionalità di interruzione dell’esecuzione di una applicazione Uniface con attivazione del debugger a fronte di una specifica condizione: ad esempio quando un campo assume un certo valore. Questa funzionalità in genere viene definita “Watchpoint”.

Dialogando con gli ULab ho scoperto che questa funzionalità pur non essendo ufficialmente supportata o documentata è disponibile da sempre nel mondo Uniface a partire da Uniface 6.1 (1994!) anche se a livelli diversi nel corso del tempo.

Ecco come implementarla:
1) Attivare una sessione di Uniface con il debugger attivo
2) Definire un breakpoint qualunque
3) Rimanendo nel debugger attivare la funzione di “Edit Breakpoint”
4) Nella finestra che compare selezionare il breakpoint temporaneo definito al punto #2; nei campi della parte bassa della maschera su cui si è posizionati compare il contesto SPECIFICO del breakpoint definito.
5) Modificare il contesto specifico del breakpoint definendo:
5a) Una condizione generica nell’ultimo campo, come nomeCampo=valore oppure nomeVariabile=valore.
5b) Eliminare le specificità di contesto non necessarie: “line”, “module”, “component”. Io ho provato ad eliminarle tutte quante per definire un contesto molto generico.
5c) Uscire dal debug e continuare l’utilizzo dell’applicazione
Nel momento in cui la condizione definita sarà “vera” il debugger comparirà automaticamente! Voilà.

Si possono anche inserire nel campo “condition” delle funzioni come ad esempio:
$scan($uppercase($item(“LIN”,($itemnr(1,$proccontext(“FULL”))))),”VARIA”)>0
che ferma l’applicazione in debug ogniqualvolta viene coinvolta in una istruzione Proc la variabile VARIA. In quest’ultimo caso si tenga in considerazione che esiste al momento un limite massimo di lunghezza del campo “condition” pari a 75caratteri; è stato richiesto un ampliamento a 128 caratteri.

L’unica avvertenza da tenere in considerazione è che questo tipo di settaggio NON viene salvato come stato del debug e quindi viene perso uscendo dalla sessione applicativa sotto verifica e va ridefinito all’inizio della sessione successiva nel caso in cui servisse nuovamente.