Newsgroup: it.comp.lang.visual-basic
Titolo: Urgente: Blocco del programma a fine esecuzione!!!

 Se non lo dici troppo in giro, End
    Lupo, ma tu non eri permaloso? O sei anche masochista?
--
Ciao.
Maurizio
--------
?SPQR(C)
 X
--------

     Lupo, ma tu non eri permaloso? O sei anche masochista?
Maurizio, non ho capito :-(( Spiegami.
Se chiudo tutte le form (e credo proprio di esserne certo), che male può
fargli un End (nel caso me ne sia dimenticata una)?
Se è vero che l'EXE si chiude da sè quando scarica l'ultima form,
probabilmente il mio End non lo esegue nemmeno.
Ti posso garantire che i miei EXE (oltre che in IDE) non danno nessun
problema, e vengono usati su un 2/300 macchine, sia in rete che separate.

 e vengono usati su un 2/300 macchine, sia in rete che separate.
    :-))
    Ti credo sulla parola. Che un programma, in passato, non abbia dato
problemi e' una delle poche cose che generalmente si presume di poter
garantire. Infatti quando poi da' problemi cosa si dice? Strano... mai
successo... e' la prima volta che fa cosi'...
    Ci sono poi i problemi che hanno origine nel passato i cui effetti si
manifestano nel futuro. Sono i problemi piu' affascinanti.
    :-)))


 non nell'IDE, meglio l'unload di tutte le form
Scusa, ma vorrei capire questa storia dell'End che farebbe andare in crash
(che significa? che si blocca? Che da' errore? O cosa?): facci un esempio di
codice che secondo te da' problemi in un compilato e non nell'IDE.
--
   Alex Palmese
---
Sei anche tu stanco dei messaggi spam? Usa Terminator, il programma
anti-spam italiano FREEWARE! 
http://www.sertel.net/terminator/

 manifestano nel futuro. Sono i problemi piu' affascinanti.
Ora spiegati tu, per favore. 'sto End, se si è chiuso tutto (oggetti,
recordset, connessioni, database, form, etc) che problemi può creare?

 manifestano nel futuro. Sono i problemi piu' affascinanti.
I miei geitori me lo ripetono sempre ^_^
Pero' al posto di "affascinante" usa sempre "disgraziato" ecc..
ghghg scusate ma l'aria di ferie mi ha rapito

 recordset, connessioni, database, form, etc) che problemi può creare?
    Quelli che indichi tu stesso. Infatti hai scritto "se": "se si e' chiuso
tutto" eccetera. *Se* indica dubbio, ipotesi...
    Visto che non sei un novellino, perche' non ti fai un bel giro su google
alla ricerca dei fiumi di parole scritti in proposito in questo ng? Un
rimprovero, pero': come mai non l'hai gia' fatto?


 rimprovero, pero': come mai non l'hai gia' fatto?
L'avevo fatto e l'ho rifatto, ma più che dire di non usare End e/o di fare
gli unload, non spiega. L'unico riferimento significativo, molto generico, è
quello che fa pensare VB non fa sempre quel che dovrebbe. Le note poi
all'istruzione End di MSDN sono sibilline e io le traduco così: "Vi dico ciò
che non faccio, siccome non ho un metodo alternativo più completo, ho deciso
che non sono cavoli miei e quindi arrangiatevi!".
Comunque sia, ho fatto una prova e, pur avendo verificato di unload-are
tutte le forms prima di eseguire l'End (anche per il fatto che arrivo a
quell'End solo se l'operatore ha chiuso tutte le form), ho voluto fare un
For Each frm in Forms, Unload frm, Set frm=Nothing, Next frm.
Bene (l'ho comunque messo sotto opzione per poter tornare immediatamente
indietro), ma c'è qualcosa che non mi quadra. Farò delle prove e informerò.
Perchè scrivere ora, allora? Forse perchè non so star zitto? O solo per dire
che c'è qualcosa che non quadra, mi puzza. Ora annuso 'sto fetore, magari lo
assaggio e tornerò.

 assaggio e tornerò.
No, falso allarme. Sorry.

 che non sono cavoli miei e quindi arrangiatevi!".
    Io invece non leggo niente di sibillino ma semplicemente:
    "L'istruzione End rappresenta un metodo per forzare l'interruzione del
programma."
    Bene, se hai bisogno di questo usala. Ma non ti incuriosisce sapere cosa
avrebbe fatto il tuo programma se non l'avessi interrotto? Magari qualcosa
di utile o necessario. Se invece sei certo che null'altro aveva da fare il
tuo programma, perche' fargli fare una cosa inutile? Con l'impegno poi, da
parte tua, ad ogni modifica, di verificare che quell'*inutile* End venga
eseguito a tempo e luogo opportuno...


 ha scritto
...
Maurizio, giornata storta? Lo noto dal tenore dei tuoi post di oggi, non
solo quelli che direttamente mi riguardano. Su che è agosto e piove, dai!
;-))
Comunque, il mio End lo lascio, giusto nel punto in cui il programma non
deve fare null'altro e da eseguirsi dopo aver chiuso anche il cassetto della
scrivania a chiave.
Preferisco una procedura che può (nella remota eventualità) interrompersi
brutalmente e/o lasciare qualche oggetto appeso che una procedura che è
regolarmente terminata, ma resta attiva e appesa essa stessa. Io il Task
Manager non lo cito nemmeno ai miei utenti, immagina se solo m'arrischio a
farglielo usare.

 farglielo usare.
    Allora lo vedi che "preferisci" fare come vuoi? Cosa si puo' ribattere a
questo tipo di affermazioni, per altro piu' che legittime, intendiamoci, se
non: buon pro ti faccia, e sanita'? Oppure preferisci: auguri e figli
maschi? O: in culo alla balena? O: contento tu contenti tutti?


 di utile o necessario.
Sono d'accordo, pero' ancora in tutto questo thread non ho capito (e/o
nessuno ha risposto con una spiegazione logica e riproducibile -cfr. metodo
galileiano-) per quale motivo usare End dovrebbe far bloccare un programma
VB.
E' vero che ad esempio scarica tutte le form "brutalmente", pero' al massimo
posso perdermi qualche dato se ho messo la End troppo presto... Io
solitamente faccio prima tutti gli Unload del caso, ed alla fine metto l'End
e non ho mai avuto blocchi strani del programma, comunque.
Ripeto: qualcuno dei sostenitori del "non usate l'End che fa crachare il
programma" potrebbe cortesemente spiegare PERCHE' dovrebbe accadere,
eventualmente in quali condizioni, e magari un pezzo di codice utile per
permettere agli altri di riprodurre il problema?


 permettere agli altri di riprodurre il problema?
    Ok per il metodo galileiano e ti prometto che appena avro' la mente
sgombra (potrebbero passare anni, pero'...) tentero' di scrivere un esempio
di quelli che tagliano la testa a voi torelli... pero'... pero'... segui un
po' questo ragionamento: io non uso end, e non ho problemi, tu usi end e non
hai problemi, giusto? *Ma* il manuale di riferimento dice non solo che e'
inutile ("Č sempre facoltativa" per me vuol dire che non e' necessaria,
quindi inutile) ma anche che ha una funzione ben precisa ("L'istruzione End
rappresenta un metodo per forzare l'interruzione del programma") ed
*eccezionale* ("Per interrompere normalmente un programma Visual Basic
[...]"). Orbene, dato che io sono in linea col manuale, perche' dovrebbe
spettare a me (alla mia "fazione") l'_onere della prova_? :-P + :-)


 spettare a me (alla mia "fazione") l'_onere della prova_? :-P + :-)
Sono uno dei "torelli" (stavo meglio nelle mie normali e selvatiche spoglie)
e ti dico che hai ragione. Dovrebbe essere infatti Sharkman a rispondere con
un esempio di quelli che (cito):
"L'istruzione End provoca il crach del programma se lo fai girare compilato
e
non nell'IDE, meglio l'unload di tutte le form".
Ma, aggiungo, che tu sei della sua "fazione" e hai sostenuto indirettamente
(molto piů di lui, dov'č finito, a proposito?) la sua idea.
Prove, vogliamo prove, fatti che ci ... cosino. ;-)

 Prove, vogliamo prove, fatti che ci ... cosino. ;-)
    :-)
    Io non sottoscrivo la frase di Sharkman in quanto sono piu' radicale: un
programma Visual Basic non deve essere concluso con l'istruzione End. Punto
e basta. Perche'? E perche' si'? Ovvero, a costo di ripetermi, non sono io a
dover dire perche' non vada usato End a questo scopo ma *deve* dirmelo chi
lo usa. In quanto e' chi lo usa che fa qualcosa che si discosta da cio' che
indica il manuale di riferimento del linguaggio.
    Caro Lupo, sono io che ti domando: perche'?
    Ovvero, fammi *tu* un esempio in cui E' NECESSARIO concludere un
programma Visual Basic con End SENZA INTERROMPERNE L'ESECUZIONE.


 programma Visual Basic con End SENZA INTERROMPERNE L'ESECUZIONE.
La mia risposta? Eccesso di sicurezza, forse di ... legittima difesa (da
VB).
Mi cito:
Preferisco una procedura che può (nella remota eventualità) interrompersi
brutalmente e/o lasciare qualche oggetto appeso che una procedura che è
regolarmente terminata, ma resta attiva e appesa essa stessa. Io il Task
Manager non lo cito nemmeno ai miei utenti, immagina se solo m'arrischio a
farglielo usare.
Comunque, a parte tutto, sarebbe interessante (magari da Sharkman) vedere un
po' di codice di quelli "che crashano la macchina, solo in EXE e non in
IDE". Ovvio che se devo eseguire delle istruzioni (nella routine corrente o
in altre che verrebbero eseguite successivamente) e invece ci sbatto un End,
pardon a tutti, il piccio sono io, non VB. Diverso è il discorso di
eventuali oggetti che, se non esplicitamente scaricati, potrebbero restare
appesi in memoria, anche dopo l'End e, quindi, persino dopo la chiusura
dell'EXE relativo. Su questo non discuto.

 VB).
    Ti do' una mano... :-) E ricopio qui sotto una delle poche risposte i
cui argomenti ho trovato convincenti. Anche se non ho cambiato il mio modo
di operare sto sempre in allerta e tengo presente quanto e' scritto qui
sotto.
--
Ciao.
Maurizio
--------
?SPQR(C)
 X
--------
From: "GbC"
Newsgroups: it.comp.lang.visual-basic
Subject: Re: Terminare un programma
Date: Mon, 27 Nov 2000 10:54:01 GMT
Maurizio, so bene cosa c'è scritto nella guida.
Ho iniziato ad usare VB dalla versione 2, ed ho maturato una certa
esperienza.
Programmo professionalmente (è il mio lavoro) ed uso anche altri
linguaggi.
Per quanto mi riguarda, mi comporto così:
- In ogni mio programma c'è un form 'master', da cui (generalmente)
parte ogni processo; è questo il form che si occupa anche della
chiusura del programma, attraverso il suo evento unload.
- Faccio uso di flag globali per controllare l'uso di processi esterni
che attivo in ragione delle mie esigenze (classi, ocx ed altro).
- Se all'evento unload alcuni processi sono attivi, cerco di chiuderli
(utilizzando i metodi già citati).
Pur con tutto questo, ho notato che alcuni task che un prg apre non si
chiudono se non con una istruzione end. Ad esempio chiamate a dll che
operano in background, utilizzo di funzioni eseguite con rundll ed
altro. Ed ho notato che l'unico modo per non lasciare 'appese' queste
funzioni è l'end.
Posso immaginare che siano state scritte in modo non corretto, ma
tanto è...
L'esperienza mi ha portato ad evitare approcci 'pragmatici' con la
programmazione. Seguire pedissequamente la guida ed i manuali (per
quanto indispensabile) spesso non porta ai risultati desiderati,
perché alle volte vengono omesse alcune cose (magari si perdono nei
meandri delle traduzioni o semplicemente nei dischi di chi scrive le
guide), o l'ambiente utilizzato non è esattamente quello, oppure non
si possiede tutta la documentazione delle funzioni esterne cui si fa
riferimento.
E siccome problemi nella chiusura dei programmi ne ho avuti (come
tutti, immagino), ho semplicemente riportato quello che la mia
esperienza mi porta a fare.
Non voglio essere polemico o altro.
Non mi reputo migliore di altri.
Non ne so ne più ne meno di tanti altri.
Ma dopo aver fatto tutto per chiudere quello che ho usato e aperto,
aggiungo una riga con end.
---
GbC
http://gbc.homeip.net
---
end :)

 sotto.
Maurizio, io non ho mai detto che tu sbagli, quindi non mi aspetto certo che
tu cambi idea.
Io, come si dice, "per non saper nè leggere nè scrivere", dopo aver fatto di
tutto per chiudere il possibile e il "ricordabile" (vedi anche il mio post
su come trovare gli insiemi Connection(s) e Recordset(s) di ADO, che non
esistono 'sti bastardi di ADO, sììììììììììììììì! - Nato dal dubbio che
questo topic ha scaturito, solo per la parte ADO), per "tranquillità" metto
End.
Non ti saprei citare situazioni simili a quelle descritte da GbC, nel senso
che, fortunatamente, non ne ho, ma, semmai mi capitassero, ho l'End che mi
salva dalla telefonata del cliente che mi dice "ho 15 finestre aperte,
vorrei andare a casa, non riesco a chiuderle. Se stacco la spina, succede
qualcosa?".

 spettare a me (alla mia "fazione") l'_onere della prova_? :-P + :-)
Semplice, perche' e' la "tua fazione" ad aver sollevato la questione,
facendo affermazioni assolutistiche senza pero' darne una spiegazione logica
ne' una descrizione dei motivi, ne' un esempio per consentire di riprodurre
il problema!
Anzi, leggo risposte del tipo "un programma Visual Basic non deve essere
concluso con l'istruzione End. Perche'? E perche' si'?", e questo tipo di
risposte, scusami, ma non hanno molto senso e non portano nulla alla
discussione...
Farete mica parte della setta religiosa di "Quelo", visto che quando vi si
chiede "perche'?" rispondete "e mica posso fare tutto io!" :-)) Battute a
parte, sappiamo tutti quello che dice il manuale, e sappiamo tutti che usare
l'"End" e' un modo sbrigativo per chiudere un programma (e sappiamo anche
che con End non vengono eseguiti tutti i Form_Unload), ma se puo' esere
utile perche' non usarlo? Se fosse dannoso, perche' non l'avrebbero tolto
nelle versioni piu' recenti (ed io programmo in VB dalla 1.0, passando
persino per la versione DOS!)?
Il punto e' proprio questo: noi affermiamo che non abbiamo mai avuto
problemi con l'End mentre c'e' chi afferma che e' pericoloso quindi e'
interesse di tutti, credo, sapere in quali condizioni non vada usato ed e'
logica conseguenza saperlo da chi afferma questo.
Personalmente ritengo che l'unico caso in cui puo' dare problemi (lasciando
comunque "appeso" il programma, ossia che non si chiude neanche con End) e'
quando e' stato nel frattempo invocato qualche metodo di un OCX o DLL
esterna che ancora non ha concluso l'esecuzione. Questo pero' significa una
programmazione "sporca", che non si risolve neanche con l'End.
Quindi, vogliamo piantarla di farne una "questione di fede" e dare
informazioni precise e riproducibili, se se ne possiedono (o altrimenti
evitare di polemizzare intuilmente se non si sa cosa rispondere)?


 evitare di polemizzare intuilmente se non si sa cosa rispondere)?
    Ancora voli di fantasia? Scusa, ma secondo te *chi* ne ha fatto una
questione di fede?


 questione di fede?
Chi dice che non si deve fare perche' fa "bloccare" il programma, senza
spiegare per quale ragione.
Io credo a cio' che vedo o a cio' che mi viene dimostrato.
E fino a quel momento per quanto mi riguarda sono solo chiacchiere da
"Quelo"!:-)
Quindi il thread per me finisce qui, a meno che non si torna a parlare di
tecnica, fatti e codice. Spero che tu me lo consenta..;-))
Ciao!


 migliore amico ti si fa la fidanzata! :-)
Go To Statement Considered Harmful - Edsger W. Dijkstra
http://www.acm.org/classics/oct95/
 =8-PPP
Oh, ragà, però non facciamo guerre di religione, please. :-))
Un Paperino appena tornato dalle ferie e rilassato...
per i prossimi cinque minuti, forse.

 tecnica, fatti e codice. Spero che tu me lo consenta..;-))
    Ma certo!... Magari poi mi fai sapere anche come potrei fare a non
consentirtelo...
    Vuoi parlare di tecnica? Non sono profondo in materia.
    Vuoi parlare di fatti? Qui mi arrangio benino.
    Vuoi parlare di codice? Pronti! Guardaqua':
        Private Sub Command1_Click()
        End
        End Sub
e' stato postato ieri sotto l'oggetto: "codice per generare anagrammi". Che
ne dici? Io sarei tentato di ritenerne moralmente responsabile la tua
"fazione". :-PPP


     No!... Perche'?... Non era gia' abbastanza lungo questo Esta3d?
Uhm, su questo hai ragione..;-)
Pero' per i puristi della programmazione strutturata il GoTo e'
l'esempio-degli-esempi a partire dai (miei) tempi dell'Universita'..:-)).
Ma sia chiaro, non odio il Goto perche' non e' "puro", ma perche'
semplicemente rende il codice meno leggibile e perche' fonte di innumerevoli
problemi che vanno poi debuggati per ore...;-)) Per cui non lo uso, ma non
minaccio chi lo fa! ;-)
Cosi' come non considero pericoloso l'End in se', ma solo se lo si usa "per
pigrizia". Un po' come l'"On Error Resume Next" (oddio, ecco che mi e'
scappato un altro argomento "scabroso" per noi programmatori!...:-))).
Comunque sono d'accordo, cerchiamo di troncare qui il thread (a meno che,
ripeto, non ci sia qualcuno che voglia postare un codice che riproduca il
problema dell'"End" che fa bloccare un eseguibile e non l'IDE del VB...).


Anch'io mi fermo (č tutto piuttosto chiaro, ora, a parte l'errore nell'EXE e
non nell'IDE), ma, da buon casinista, mi prendo l'ultima parola e dico:
"Lanci la prima pietra chi non ha mai usato un Go To (anche in VB, non solo
in GWBasic e/o Basic Pro)".
In certi casi puņ apparire necessario (lasciamo stare GoSub e On error Go To
..., ovviamente, perchč non ammettono altra sintassi) e io sono sicuro che
non morirņ certo lapidato.
Un buon argomento (o un link) potrebbe essere quello di spiegare, con esempi
semplicissimi, quali sono le possibili alternative al Go To in varie
situazioni.
;-)))

 situazioni.
La programmazione strutturata richiede una certa "forma mentale": una volta
capita, la applichi senza sforzo. Con una combinazione di "If .. Then ...
Else" e "Do... Loop" e strutture di controllo varie, conditi con qualche
"Exit" se necessario, si puo' far tutto quello che si fa con GoTo.
Posso dirti che per esperienza anche personale (ho "istruito" vari
programmatori...;-)) l'uso classico del Goto nei neofiti e' infatti molto
spesso per uscire da un ciclo:
Do While a > 10
   If b = 1 Then Goto Esci
   ...
Loop
:Esci
mentre basta scrivere:
Do While a > 10
  If b = 1 Then Exit Do
  ...
Loop
oppure:
Do While a > 10 And b <> 1
  ...
Loop
Ma di esempi possono essercene molti, e trovare un "metodo generale" e'
difficile...


 spesso per uscire da un ciclo:
Beh, per neo-neofiti...
Ok, parliamone. Ecco due blocchi di codice assolutamente inventati e nemmeno
provati.
Il primo col GoTo, il secondo senza, scritto con la prima idea che m'è
venuta per sostituire il GoTo.
Io sono dell'idea che il primo (se la label di arrivo del GoTo non è a anni
luce di distanza) è molto più leggibile, oltre a non dover "consumare" una
variabile di stato per ovviare al GoTo e un If per testarla.
Cosa ne dici? Hai altre soluzioni che possano salvaguardare la leggibilità?
Sub con_goto()
'============
    a = 1
    b = 2
    Do
        For n = 1 To 10
            If a + n = 3 Then
                GoTo dopo_prima_somma
'                -------------------------------------
            End If
            If a + b + n = 5 Then Exit Do
            If a + b + n = 7 Then Exit For
            a = a + 1
        Next n
        a = a + 3
        b = b + 4
        Exit Do
    Loop
    a = a + 1
    b = b + 1
dopo_prima_somma:
'-----------------------------
    a = a + 2
    b = b + 2
End Sub
Sub senza_goto()
'=============
    a = 1
    b = 2
    c = 0
    Do
        For n = 1 To 10
            If a + n = 3 Then
                c = 1
                Exit Do
            End If
            If a + b + n = 5 Then Exit Do
            If a + b + n = 7 Then Exit For
            a = a + 1
        Next n
        a = a + 3
        b = b + 4
        Exit Do
    Loop
    If c = 0 Then
        a = a + 1
        b = b + 1
    End If
    a = a + 2
    b = b + 2
End Sub

 Cosa ne dici? Hai altre soluzioni che possano salvaguardare la
leggibilità?
Uhm, per prima cosa non capisco l'utilita' del ciclo Do..Loop se prima del
Loop c'e' un "Exit Do" (quindi non fara' mai piu' di un ciclo). Vabbe',
facciamo finta che non ci sia (mi sa che ti e' scappato nel
copia&incolla;-)). Ah, anche la condizione "a+n=3" non si puo' mai
verificare perche' "a" ed "n" assumono gli stessi valori...;-))) Quindi
consideriamola un "a+n=6", almeno esce dopo 3 cicli..;-)
Diciamo quindi che non vedo soluzioni migliori, anche perche' non solo non
essendoci uno scopo preciso, ma essendo un esempio creato appositamente per
il GoTo (un For dentro ad un Loop e con condizioni astruse per saltare di
qua e di la') e' difficile trovarne...;-)) Tra l'altro la logica va anche
"distribuita" maggiormente sfruttando Sub e Function (soluzione minimale,
non parliamo di programmazione ad oggetti), comunque preferisco la soluzione
senza GoTo perche' mantiene quella "logica" lineare che rende piu' chiaro un
listato, e nei casi pratici e' sempre meglio un listato leggibile ed
aderente alllo schema logico di un algoritmo soprattutto perche' piu'
semplice da "sbacare".
Ovviamente IMHO. :-)
Comunque visto che mi hai provocato, eccoti una diversa versione del tuo
listato :-))) incollala dentro ad una form vuota e dimmi se ti piace:
Option Explicit
Dim a, b
Sub con_goto()
    Dim n
    a = 1
    b = 2
    Do
        For n = 1 To 10
            If a + n = 6 Then
                GoTo dopo_prima_somma
            End If
            If a + b + n = 5 Then Exit Do
            If a + b + n = 8 Then Exit For
            a = a + 1
        Next n
        a = a + 3
        b = b + 4
    Loop
    a = a + 1
    b = b + 1
dopo_prima_somma:
    a = a + 2
    b = b + 2
End Sub
Sub senza_goto()
    a = 1
    b = 2
    If EseguiCiclo() Then
        a = a + 2
        b = b + 2
    End If
End Sub
Function EseguiCiclo() As Boolean
    Dim n
    Do
        For n = 1 To 10
            If a + n = 6 Then
                EseguiCiclo = True
                Exit Function
            End If
            If a + b + n = 5 Then Exit Do
            If a + b + n = 7 Then Exit For
            a = a + 1
        Next n
        a = a + 3
        b = b + 4
    Loop
    a = a + 1
    b = b + 1
    EseguiCiclo = False
End Function
Private Sub Form_Load()
    con_goto
    Debug.Print a, b
    senza_goto
    Debug.Print a, b
End Sub


 listato :-))) incollala dentro ad una form vuota e dimmi se ti piace:
Non mi dispiace, senza ironia, ma io ... e torniamo alle preferenze
personali.
Ciao.

 personali.
Uhm, siamo in un loop infinito...;-)
Ciclo:
  GoTo Ciclo
Va bene cosi'? :-) Io pero' preferisco:
Function Ciclo()
  Ciclo = Ciclo()
End Function
Almeno cosi' il sistema schiatta prima..;-))
Vabbe', per finire questo thread (stiamo scivolando nell'OT ormai;-)) in
modo simpatico:
Un Matematico, Un Fisico ed un Ingegnere sostengono l'esame per insegnare
Matematica alle medie. Il quesito è: "Quanto fa due più due?" Le risposte:
Il fisico digita l'operazione su una calcolatrice e dice: "due piu' due fa
quattro".
L'ingegnere digita l'operazione su una calcolatrice e dice: " due più due fa
CIRCA quattro".
Il matematico riempie sei fogli protocollo e alla fine esclama:
"Converge!!!!"


     No!... Perche'?... Non era gia' abbastanza lungo questo Esta3d?
 ROTFL

 
http://www.acm.org/classics/oct95/
    Lo rileggero' con commozione, lo ammetto.



Scusa, ma funziona senza dare errori no?
Allora qual'è il problema?
Ho letto e riletto tutto il 3d ma a parte questioni morali o faziose niente
di tecnico o dimostrabile...
Secondo me è corretto se funziona...

 in GWBasic e/o Basic Pro)".
Verrò lapidato ma lo ammetto, un paio di volte ho fatto uso di goto fuori
dai consueti canoni (gestione errori), ma facendolo mi sono sentito male, e
prima mi sono sforzato per ore alla ricerca di un'altra soluzione.
Non so se avete presente quegli incastri dai quali non si riesce più ad
uscire se non con le mani sporche...
Cattiva programmazione? :-((((((((

 "Converge!!!!"
Il fisico non era un fisico: avrebbe contato le dita (metodo sperimentale)
L'ingegnere non era un ingegnere: mai sentito un ingegnere pronunciare la
parola "forse".
Il matematico non era un matematico: avrebbe risposto (immediatamente) 4,
disinteressandosi completamente della potenziale corrispondenza fisica a
qualsivoglia elemento.

 Cattiva programmazione? :-((((((((
Parliamoci chiaro: ma a che serve ... in fondo?
Spesso, per purismo informatico, a perdere tempo e, magari, ad aumentare
l'uso della CPU.
Io (quando mi viene, dopo averci pensato non piů di 30 secondi)
uso il GoTo, senza vergognarmene.

 Secondo me è corretto se funziona...
No David, non si può dire "funziona, quindi è corretto".
E' concettualmente sbagliato!
Ci troviamo all'interno di una Sub, a sua volta interna a una Form (Command1
è un controllo di una form) e pretendiamo di fare End? VB, in questo caso,
lavora più che bene, meglio di un servo nero (ho detto nero, non negro) nel
'800, ma stiamo costringendo il servo nero a dire "sono in volo, l'aria è
salubre (com'era nel '800) e mi piace un casino (no, casino allora non si
diceva), ma mi è stato ordinato di scendere, senza atterrare come
normalmente faccio, scendere _istantaneamente_. Cazzo (no, allora non si
diceva), mi farò male, ma sono un servo e devo ubbidire!".
Cadde all'istante, si fece un male boia, ma era un servo.
Anche i servi pensano. Chissà mai che il servo VB non possa decidere di
mettersi a pensare (oltre che a eseguire) e decidere (_istantaneamente_) di
esporre un MsgBox con frasi da censura?

 Parliamoci chiaro: ma a che serve ... in fondo?
Non lo so, ma avevo sentito dire che se il codice di un programma è stato
scritto in modo fluido e ben strutturato non ci si dovrebbe incastrare in
teoria.
Il problema è che si scrive oggi e non si sa mai quali (e perchè) saranno le
modifiche che dovremo apportare domani, dopo chissà quanto tempo, su quello
stesso codice.
Spesso mi ritrovo a riscrivere pagine di programma perchè non c'è modo di
adattare la logica del vecchio al nuovo, però andando avanti tento sempre di
scrivere immaginando al domani, ma non è facile, la sfera di cristallo non
me l'hanno ancora regalata.
Per non parlare di quando mi maledico da solo per non aver commentato una
funzione, avendo invece aggiunto 50 righe di commento a quella prima che
invece si capiva anche senza, ma questa è un'altra storia...
Scusate l'intervento OT
Ciao

 invece si capiva anche senza, ma questa è un'altra storia...
Mi ripeto:
Commenti, commenti, commenti, commenti, ...enti, ...entiiii, ...tiiii!

 diceva), mi farò male, ma sono un servo e devo ubbidire!".
[cut]
questo allora?
Anche qui siamo dentro ad un form
Private Sub Command1_Click()
dim frm as form
    for each frm in Forms
       unload frm
    next frm
End Sub
anche in questo caso...
Private Sub Command1_Click()
unload me
End Sub
Teoricamente dovrebbero essere sbagliati anche questi due metodi, perchè
scarico un form da dentro se stesso...(nel primo caso assieme a tutti gli
altri)
Inoltre, nel primo caso chi mi dice che l'unload del form in cui ci troviamo
avvenga per ultimo?
se questo non accade  rimarrebbero dei form caricati?
Confermi?
Inoltre, anche se si va nell'OT io il problema proprio non ce lo vedo perchè
in sqlWindows l'unico modo per chiudere un programma è richiamare la
funzione SalQuit() , che in teoria dovrebbe equivalere all''END di Vb con
l'unica differenza è che in SqlWindows è l'UNICO modo per chiudere
l'applicazione, e nessuno sta li a farsi delle pippe mentali...almeno non
l'ingegnere che mi ha fatto il corso :-)
Quindi non so, forse Vb è più bastardo, o più sottile, però  io tendevo a
credere che l'unica vera differenza tra un linguaggio e l'altro fosse la
sintassi.
Mi dovrò ricredere.

 sintassi.
Ribadisco, la sintassi è solo un metodo espressivo, interpretabile solo da
chi conosce/riconosce il linguaggio stesso.
La logica (come la musica?, non probabilmente la canzone) è comune a tutti i
linguaggi,
trasmette concetti, non parole, pensieri e metodi, non sintassi e linguaggi.
Io ti posso dire "il metodo è questo, fai come vuoi, ma questo è il
comportamento".
Bene, il modo esula da qualsiasi linguaggio o strumento, rappresenta una
certa virtualità incontestabile (certo, modificabile, migliorabile, persino
sostituibile). Lo strumento e/o il linguaggio che utilizzi per realizzare
quel metodo/comportamento (quella logica) è veramente cosa di poco conto,
uno strumento, appunto, nulla di più. Di suo non ha niente, assolutamente
niente. Quello che resta, alla fine, è quel metodo e i risultati che si
ottengono, non gli strumenti utilizzati.
La casa e le sue finiture, la sua eleganza e comodità, non la cazzuola o la
taglierina, non i secchi di pittura, nè il ponteggio.
Oddio, ... un posticino per il l'ingegnere, l'architetto e il pittore ... lo
vogliamo lasciare?

 tutti gli ammenicoli che posso aver creato/usato.
[...cut...]
Ok, capisco perfettamente e concordo pure, sicuramente se un giorno End
comincerà a fare i capricci oltre al classico
cito Borrelli
<<Ohi, Strano... mai
successo... e' la prima volta che fa cosi'...>>
potrò dire <<Ah si! Ok, beh, non è nulla di grave, ti mando
l'aggiornamento>>
:-)

 (ho iniziato a programmare su un Sinclair ZX81...;-)).
[...]
    :-))
    Io ce l'ho ancora! Funzionante. Credo, spero... Sono anni e anni che non
apro quella porta.


 Commenti, commenti, commenti, commenti, ...enti, ...entiiii, ...tiiii!
    A me invece i commenti stanno proprio poco simpatici. Preferisco un
breve testo introduttivo e scrivere codice autodocumentante. Tuttavia sono
perfettamente cosciente che non e' il miglior modo ne' di scrivere i
commenti ne' di scrivere codice. Pazienza. Compromesso per compromesso mi sa
che per ora vado avanti cosi'.


 Secondo me è corretto se funziona...
    Secondo me se funziona... funziona e basta.
    "Corretto" invece e' un concetto legato al mondo delle "regole". Nulla a
che vedere con i discorsi "tecnici" che invocavi prima. Un esempio? Option
Explicit. Il concetto e' lo stesso di End, a ben vedere: come End non e'
obbligatorio. Decidere di usarlo o meno dipende dalle "regole" che tu ti
dai. O che il gruppo (di lavoro) al quale appartieni si da' e che tu sei
tenuto a rispettare pena l'esclusione dal gruppo.
    Puoi dimostrare "tecnicamente" che se non usi Option Explicit succedono
disgrazie? No, perche' potra' sempre venire fuori quello che dice che *lui*
sta attento e che non sbaglia mai a digitare. Devi proprio beccare *lui* in
castagna per *dimostrare* a *lui* che "deve" usare Option Explicit. Potrebbe
anche non capitare mai... Mica abbiamo tutto 'sto tempo da dedicargli, no?
:-)
    Diciamo che la tua prudenza, l'esperienza, o che so io, ti hanno portato
a *decidere* di usarlo. Ti sei dato una regola. Nulla di "tecnico", insomma.
Apparentemente! Se infatti questi ragionamenti devi farli in grande scala
(per numero di programmatori o per numero di righe di codice) ecco allora
che diventano tecnici. Le "regole" di buon senso possono essere "misurate"
nei loro effetti, negli effetti derivanti dall'applicazione o meno, intendo.
Ovvio che tu a casa tua puoi continuare a fare cio' che vuoi. Puoi usare o
non usare Option Explicit o End. Tanto... se funziona!... ;-)))


 E' una questione di principio! Non posso uccidere chi mi mantiene in vita!
Vi prego, no, oltre alla teologia anche questioni di morale/etica NOOOO!
:-))
Forza, lasciamo una volta per tutte questo 3d oppure cerchiamo di fornire
informazioni oggettive e riproducibili altrimenti non la finiamo piu'!


     Io ce l'ho ancora! Funzionante.
Beato te, io l'avevo venduto per comprarmi lo Spectrum, ma mi piacerebbe
rivederne uno...:-)
Che ricordi, "ben" 1K di RAM (che poi ho espanso a "ben" 16K!),
monocromatico, niente grafica (ma costruii un generatore programmabile di
caratteri che rimappava su RAM la zona della ROM contenente il set di
caratteri, quindi potevo riprogrammare qualsiasi carattere per fare un
minimo di grafica, ad es. ci avevo fatto un bel programma per grafici di
funzioni...).
Li' la programmazione non era molto strutturata (;-)), ma mi sono divertito
parecchio con l'assembler Z80 (e li' si che ho usato i JMP! ;-))...


     Loop
Quello e' l'Exit Do a cui mi riferisco, e come vedi e' dentro al Loop e
fuori dal Next.
Comunque fa nulla.:-) Ciao!


 ha scritto nel messaggio


 >     Loop
Le istruzioni dopo Next n verrebbero eseguite comunque: quando viene
eseguita la Exit For o quando il ciclo For/Next si esaurisce per suo conto.
Quella Exit Do (###) all'interno del For/Next serve proprio ad evitare
l'esecuzione delle istruzioni dopo il Next.
Ovvio che, inserendo tutto in un Do (necessario per quanto detto sopra), è
necessario un Exit Do (quello che tu hai indicato) per uscire dal Do/Loop
stesso quando il suo scopo è esaurito.

 stesso quando il suo scopo è esaurito.
Questo lo immaginavo, ma rispondimi a questo: il Do...Loop che hai messo
quanti cicli fara'?
Se la risposta e' "uno", allora non serve a nulla il Do...Loop.


 Se la risposta e' "uno", allora non serve a nulla il Do...Loop.
La risposta è "uno", ma tu hai letto distrattamente.

 apro quella porta.
Il mio funzionava ancora, almeno fino a un anno fa :-)
Però era uno ZX-80 con le ROM dell'"81". 1K espanso a 2.5, sigh...
Un Paperino "fratelli :-))"

 :-)
    Pensavo che questa persona fosse unicamente un parto della mia fantasia,
finche' non ho letto il 3d "[NET] Opzione Typeless". :-)
