Corso visual basic script\Il sunto di Donato taddei

Donato taddei su winguidotecnica, 22\01\2010, h. 19.40.

altro ripasso, un ragionamento e una domanda con risposta a tempo e a luogo
Smaltito l'arretrato, mi sono rimesso al passo.
Considerato che in questa fase di fissaggio dei concetti fondamentali "ripetita iuvant", beccatevi questo riassunto;
sottopongo alla vostra attenzione soprattutto il ragionamento finale e la domanda che ne scaturisce,la cui risposta Guido rinvierà a tempo e a luogo.
Abbiamo capito che ci sono programmi compilati e programmi interpretati.
Quelli compilati hanno nomi che finiscono in .exe o .dll, sono dei files non di testo, ottenuti con speciali programmi detti compilatori che, a partire sempre da un file di testo, detto codice sorgente, scritto secondo precise regole grammaticali, sintarttiche e semantiche,
ottentono un programma eseguibile che cioè non ha bisogno di altro per funzionare.
Invece i programmi interpretati sono dei file di testo, ugualmente chiamato codice sorgente ,ma per funzionare hanno bisogno di un particolare programma capaci di interpretarli ed eseguirli, detto appunto interprete.
Sono esempi del genere i famosi file con nome terminante in .bat.
L'interprete di tali files è il command.com o il cmd.exe di windows, noto anche come prompt dei comandi.
Altro esempio:
un indirizzo web che punti a una data pagina, non fa che scaricare la relativa pagina che è sempre un file di testo che il nostro browser, internet explorer, winguido o mozilla firefox interpreta e ci presenta come la vediamo o udiamo, permettendoci di interagire con essa, per esempio immettendo dei dati.
I nostri programmi sono realizzati in vbscript di cui esiste un interprete su tutte le macchine windows, e idem dicasi per i file .js dell'interprete javascript, e, come potrà forse dirvi qualche utente di nvda, altrettanto vale per i suoi file python.
Del resto, sebbene ora poco praticati, anche gli utenti di jaws sanno o dovrebbero sapere che questi implementa un proprio linguaggio di script,
anzi addirittura quasi un compilatore e infatti per funzionare gli script di jaws vanno compilati, ovvero trasformati da file di testo in file binari con l'apposita utility.
Allora poichè i programmi di cui stiamo parlando sono programmi per computer, o più italianamente calcolatore elettronico, macchine cioè per l'elaborazione automatica dei dati, abbiamo visto come rappresentare questi dati, i diversi tipi, i diversi formati, come trasformarli da un tipo all'altro, come associare loro dei nomi a noi comprensibili.
Abbiamo visto che tali nomi possono essere delle costanti, vale a dire che i dati assegnati o associati a quel nome non possono essere variati durante tutta la sessione del programma, e le variabili il cui valore, ovvero i cui dati associati, può variare nel corso del programma, come la parola variabile suggerisce.
Sappiamo come rappresentare i dati, come riferirci sinteticamente ad essi con dei nostri nomi,
vediamo ora come dire al computer di elaborarli.
Attraverso una serie di comandi impartiti all'interprete,
con l'uso di parole che a lui dicano cose precise
e ne abbiamo viste di vari tipi:
-ordini impliciti od espliciti (mediante Dim) di dichiarare variabili e costanti e di assegnar loro dei dati.
- ordini di aprire finestre di dialogo per l'immissione dei dati o finestre per la notificazione di messaggi
- ordini di eseguire o meno determinati pezzi di programma attraverso le istruzioni condizionali.
Abbiamo appreso che alcune di queste "parole chiave" sono, analogamente ai nomi di testa nostra che usiamo per le variabili, dei riferimenti sintetici tramite una parola, a operazioni più complesse che in realtà si sostanziano in serie più o meno complesse di istruzioni:
noi scriviamo InputBox ma a questa parola corrisponde una modifica dello schermo, la preparazione della finestra, dimensione, posizionamento, font, grandezza e colore della scritta, disegno e posizionamento dei pulsanti,
attesa dell'input, accorgersi che abbiamo premuto uno dei due pulsanti.
Abbiamo pure detto kkkkkkkkkkkkkkkkkkkkkkkkkche InputBox è una funzione, ovvero con quel nome noi ordiniamo all'interprete di eseguire una data sequenza di istruzioni, appunto quelle di cui sopra.
Abbiamo poi distinto tra funzioni e procedure, assodando che entrambe sono nomi che fanno riferimento a sequenze di istruzioni, e che l'unica differenza è che le funzioni restituiscono un esito a chi le ha chiamate, le procedure no.
Abbiamo scritto i primi programmini e abbiamo assodato che essi sono costituiti da sequenze o serie di istruzioni, più o meno contenute ciascuna in una riga.
Gli ordini all'interprete vengono quindi eseguiti in sequenza, uno dopo l'altro.
Abbiamo visto che senza poter subordinare l'esecuzione di una o più istruzioni al verificarsi di differenti condizioni, non possiamo elaborare gran che. Rimane comunque il fatto che, in assenza di deviazioni dal flusso normale, le istruzioni vengono eseguite nell'ordine sequenziale in cui le abbiamo scritte.
Possiamo concludere che la sequenza è una delle strutture logiche fondamentali di un programma.
Abbiamo poi visto che modificare questa sequenza inserendovi all'interno delle istruzioni condizionali, semplici, con un solo ramo.
Poi abbiamo visto come costruire istruzioni condizionali in cui la condizione viene verificata una sola volta producendo sequenze di istruzioni differenti per il caso in cui essa sia vera e per il caso in cui sia falsa.
Abbiamo cioè un vero e proprio deviatore logico.
Abbiamo visto come tali costrutti logici if-then-else possano essere nidificati ovvero come ciascun ramo possa contenere al suo interno altre istruzioni condizionali che a loro volta possano contenere nei loro rami altre istruzioni condizionali, e ci è stata mostrata una semplificazione attraverso la paerola chiave ElseIf, che ci permette di inserire altri rami nel nostro deviatore, ovvero di inserire un certo numero di istruzioni condizionali e relativi rami.
Siamo di fronte, dopo la sequenza, alla seconda struttura logica fondamentale della programmazione.
Attualmente ci stiamo confrontando con la terza struttura logica fondamentale:
abbiamo sequenze di istruzioni, abbiamo istruzioni condizionali, e ora pure che tali sequenze e condizioni vengono ripetute, come in un cerchio, perciò in modo ciclico.
Dopo aver realizzato che questi costrutti debbono necessariamente prevedere una condizione di uscita, pena il ripetersi all'infinito del ciclo,
abbiamo imparato a farlo con l'utilizzo della "parola chiave" o clausola Exit Do.
E sono stati forniti parecchi esempi di come condizionare l'uscita dal loop subordinandola al raggiungimento di un certo numero di ripetizioni o cicli o iterazioni, e di come anche questi costrutti, come le istruzioni condizionali possano essere nidificati, ovvero contenuti gli uni negli altri.
Da qui il ragionamento e il quesito.
Negli esercizi proposti abbiamo spesso subordinato l'uscita dal ciclo al non inserimento di alcun cognome.
Funge ma è primòitivo dal lato utente: un invio a caso può sempre scappare, e quindi gli si dovrebbe dare una ulteriore chance.
Già se avessimo saputo testare quale dei pulsanti l'utente ha premuto sarebbe stato più facile.
Quando avesse immesso una stringa vuota gli manderemmo un messaggio e solo se insistesse a non scrivere usciremmo.
Perchè complicarsi la vita?
Ok. Non me la complico.
Poichè ho una fame da "lup" Ho da mangiare un piatto di caldarroste.
Faccio un loop e come una macchinetta comincio a prendere ogni castagna, la sbuccio, la pelo, la mastico e la ingurgito.
A un certo punto ne trovoo una marcia.
Coi vostri esempi mi fate uscire dal loop e buttare il resto delle castagne ancora calde e con la buccia.
invece occorre che io, quando vedo la muffa possa evitare di pelarla e masticarla, buttarla, e cominciarne un'altra.
Guido ci aveva pure accennato che noi potremmo inserire delle condizioni all'inizio e/o alla fine del costrutto
Do - Loop
ricorrendo alle clausole o parole chiave
While "fino a che"
ed Until (fino a quando non) ma nemmeno con quelle ci farei niente.
Se non apro la castagna non vedrò la muffa e nemmeno potrò sputarla se sarà fradicia.
So perfettamente che anche in vbscript c'è un modo per non eseguire un certo numero di istruzioni al verificardi di una data condizione e, anzicchè uscire dal ciclo, avviarne una nuova iterazione, pur non conoscendone la relativa parola chiave.
Un ciclo deve prevedere sempre almeno una via di uscita.
Un ciclo deve prevedere quasi sempre una via di uscita in caso positivo, che cioè il ciclo abbia esaurito il suo compito senza intoppi,
e una via di uscita per tutte le condizioni di errore che possono verificarsi nell'elaborazione.
Avere anche la possibilità, in presenza di determinate condizioni, di eseguire solo parzialmente la singola iterazione e saltare direttamente all'inizio di un nuovo ciclo.

Ed ora, un po' di pubblicità