Come molti di voi sanno già Instant Developer è equipaggiato con due diversi moduli di debug: il debug step by step, come quello degli ambienti tradizionali, e il debug a run-time, che permette di ripercorrere e analizzare tutta la storia della sessione applicativa.
Il tipo di debug predefinito è quello a run-time e viene abilitato automaticamente alla prima compilazione del progetto. Riconosce e blocca sia i cycle loop che gli stack loop, tiene traccia dei vari stati delle variabili e del risultato delle funzioni, fornisce informazioni sul numero di chiamate e su dove viene utilizzato il tempo. È uno strumento molto potente, insomma, ma che alle volte può richiedere una piccola configurazione.
Per tenere traccia di tutte queste informazioni, infatti, l’applicazione non può far altro che tenerle in memoria. Più diventa complessa l’applicazione e più voluminosa è la quantità di memoria occupata dal modulo, così come l’apertura del debug stesso. In casi particolari si arriva ad avere procedure che sono molto difficilmente debuggabili a causa della loro ricorsività o della quantità di altre procedure che vengono chiamate. Alle volte la quantità di memoria necessaria è semplicemente troppo grande o gli oggetti da mostrare nella finestra di debug sono troppi per il browser, che impiega minuti a mostrare il risultato.
È proprio per questo che oggi voglio parlare di quei due bottoni che si trovano a sinistra del nome di ogni procedura coinvolta nella richiesta aperta nel debug. Quelli che si vedono nell’immagine sopra.
Il bottone a sinistra serve a disabilitare/abilitare il debug della procedura relativa, evitando di usare la memoria di sistema per tutti quei metodi il cui funzionamento è già sicuro.
Il bottone di destra serve a nascondere/mostrare la procedura relativa nella finestra di debug, permettendo di vedere solo quei metodi che devono essere investigati e di nascondere gli altri.
La scelta effettuata dall’utente è memorizzata nella cartella di output dell’applicazione, all’interno del file dtt.ini che contiene l’elenco dei GUID delle procedure e la relativa configurazione. Ad ogni successiva ricompilazione la configurazione viene mantenuta e riusata dall’applicazione a run-time.
Potete fare una prova scaricando questo progetto di esempio. Provate a cliccare sul comando Procedure 1 e ad aprire il debug, non troverete le chiamate a Procedure 2. Accade perché nello zip del progetto ho incluso anche la cartella di output da me configurata. Ora provate a riabilitare entrambe le funzionalità per la seconda procedura e a ripetere il tutto, vedrete che sia i tempi di apertura del debug sia la sua dimensione sono notevolmente diversi.
Maggiori informazioni sul modulo di debug sono reperibili nel capitolo 12 della guida all’uso.
Buona analisi 🙂
