Newsgroup: it.comp.lang.visual-basic
Titolo: VB.NET: Se e quando?

Ciao a tutti,
vorrei riprendere un tema che sembra abbastanza d'attualita' in queste
settimane, leggendo anche i diversi commenti.
Innanzitutto qualcuno sa quando sara' rilasciato sul mercato 
VB.NET
.
C'e' una indicazione precisa della MS?
Altra faccenda: mi appresto a realizzare un'applicazione del tutto
nuova che richiede uno svilupppo di circa 9 mesi e che avra' una
"vita" (si spera) di svariati anni. Dal '97 sviluppo in VB5 (ho
tralasciato il passaggio a VB6, ma mi sono fatto i vari VB2, VB3,
VB4...), ma ora mi sto chiedendo cosa e' giusto fare, se salpare per
le incertezze di un .NET oppure restare al sicuro con VB5.
La scelta di .NET incidera' di certo sui tempi di sviluppo e
sull'affidabiltia dell'applicativo, e quindi alla fine sui costi
complessivi, dove va incluso anche l'acquisto di 
VB.NET
.
Scegliere ora VB5 (al limite anche VB6) e' di certo la via piu'
comoda, ma alla lunga potrebbe risultare controproducente.
Be', io sarei orientato a passare a 
VB.NET
, ma qualcuno di voi
potrebbe convincermi del contrario?
Grazie per i vostri commenti.
Ciao,
 Giovanni 
  ( Ing...@XYZweb.de )
To reply please remove 'XYZ'

"Ingo.NA" <Ing...@XYZweb.de> ha scritto nel messaggio
news:qckdmtooksd2pcbfn...@4ax.com...

Se proprio vuoi un investimento per il futuro passa a C#, perchè secondo il
mio modesto parere MS lascerà VB, naturalmente non avverrà da un giorno
all'altro, quindi il mio consiglio è sviluppa in VB che comunque è
compatibile con .NET e impara il C#

 ha scritto nel messaggio
news:YzA97.65030$Qf6.5...@news2.tin.it...


 nuova che richiede uno svilupppo di circa 9 mesi
Per curiosità: cosa fa l'applicazione in cantiere?
Curiosità penso legittima: 9 mesi sono tanti!!
Ciao, Simone

 più perchè generalemte le prime uscite sono clamorasamente bacate.
Bel problema questo :-)
Ciao, Simone

Curiosità penso legittima: 9 mesi sono tanti!!
Sono stato impreciso, perche' il lavoro e' un progetto completo, di
cui lo sviluppo del software e' solo una parte.
Si tratta di un LIMS client/server per laboratori chimici
Oltre agli applicativi utenti, ai database ed ai componenti server
devono essere sviluppati tutti i driver e i firmware (per i vari
microcontroller impiegati) per l'interfacciamento ed il controllo
delle apparecchiature da laboratorio, ognuna delle quali ha una logica
ed un hardware differente.
Dunque la parte VB e' solo un 40-50% dell'intero progetto.
Ciao,
   Giovanni


Viste le tue esigenze senza alcun dubbio VBNet, le nuove caratteristiche OOP
e,ad esempio, il Mulithreading, console applications e i Servizi NT credo
possano essere due validi motivi,(non cito le potenzialità Web e il
debug/tracing...)
Visto che i drivers/firmwares verranno senz'altro sviluppati in C,
certamente ci sarà dello skill C oriented nel team che può essere facilmente
integrato nella applicazione VB attraverso moduli scritti in C# (oppure in
moduli C# che sfruttano il codice VBNet se preferisci)
Non ascoltare chi dice che MS abbandonerebbe VBNet per C# oppure chi dice
che è meglio imparare C# che VBNet, sono due linguaggi talmente simili
(nelle potenzialità) che possono interagire uno con l'altro tranquillamente,
tutto sta nelle tuo background, se vieni dal C passa a C# se invece provieni
da VB passa a VBNet e,semmai, impara nuove tecnologie tipo SOAP/XML che ti
verranno senz'altro utili. Non sono un profondo conoscitore del C, ti posso
però assicurare che non ho mai avuto problemi a 'tradurre' un listato C# in
VBNet.
Buon Lavoro!
Corrado
"Ingo.NA" <Ing...@XYZweb.de> ha scritto nel messaggio
news:11rdmt8g7o1fn02qc...@4ax.com...


Oltre al tuo modesto parere, hai qualche altra fonte "autorevole" che può
confermare la tua affermazione (e che possibilmente abbia passato parecchi
mesi analizzando entrambi i linguaggi).
Da quello che leggo in rete, nomi autorevoli (primo fra tutti Dan Appleman)
mi sembra che ci sia la massima intesa tra VBNet e C#, sopratutto da parte
MS...
Corrado

Son stato ad una conferenza M$ su .NET e le testuali aprole son state:
"Non importa il liguaggio che userete, questo sarà solo un dettaglio Finale!"
Fai tu!
Ciao SIMO
--
__________________
www.sasim.cjb.net


 sopratutto da parte MS...
Anche io sono convinto (piu' che convinto) che 
VB.NET
 sara' sempre
surclassato dal C# (anche se non abbandonato), non fosse altro che
per la decisa superiorita' del linguaggio.
Ma anche cosi' non fosse direi che bastino questi:
http://www.dotgnu.org/
http://www.southern-storm.com.au/portable_net.html
http://www.go-mono.com
Sono gia' tre i porting non ufficiali (quello ufficiale e' della
Corel) di .NET e del C# su linux. Credo questo vada a rafforzare la
mia ipotesi (come scritto in un altro thread) che il C# dovrebbe
appartenere alla categoria dei linguaggi e non degli ambienti di
sviluppo (come VB, 
VB.NET
, Delphi ed altri) e pertanto una volta
standardizzato di non essere soggetto alle decisioni di un unico
produttore. Cio' gli assicura vita molto piu' lunga e serena, e di
conseguenza lo assicura anche alle applicazioni.
Ciao.

 sarà solo un dettaglio Finale!"
Bisogna pero' valutare attentamente le parole.
E' vero che il linguaggio e' un dettaglio, e si dimostra facilmente
notando che codice uguale "tradotto" nei vari linguaggi viene
compilato nello stesso identico codice IL.
Quindi le prestazioni non dipendono in minima parte dal linguaggio
utilizzato. Ma a parita' di codice. Non tutti i linguaggi .NET (C#,
C++, VB, Perl, Python, Eiffel, JScript, ecc...) hanno le stesse
caratteristiche, e la mancanza di alcune di queste (ed il VB e'
carente in qualche punto) potrebbe rendere impossibile ottenere le
medesime prestazioni di codice scritto in un linguaggio piu'
completo.
Quindi e' vero che il linguaggio e' solo un dettaglio, ma un
dettaglio molto importante.
Ciao.

> 
http://www.go-mono.com
Dalle FAQ:
A compiler for the C# language. In the future we might work on other
compilers that target the Common Language Runtime.
Non si esclude la possibilità di altri linguaggi (ovviamente il tutto
dipenderà dal successo dell'operazione)
Comunque sia credo che la scelta finale, come al solito, la farà il mercato.
Ho già letto queste duatribe, all'inizio tutti davano VBNet già morto e
sepolto prima di nascere, adesso con la Beta2 in mano e dopo aver provato
entrambi i linguaggi, le opinioni non sono più così chiare...
Corrado

 Fai tu!
Be, mi sembra proprio che voglia dire, usa i tuoi skills ovvero C# se vieni
da C o Java ;-) oppure VBNet se vieni da VB...
MS ha sempre sostenuto questo, purtroppo, a differenza della comunità C, i
VB'ers vogliono tutto senza pagare nulla, quindi il fatto di avere un nuovo
linguaggio con tutto (o quasi) quello che si è sempre richiesto, ripulito
dalle varie schifezze del vecchio basic pagando il prezzo della 'poca'
compatibilità verso il basso non è piaciuto. Quindi MS ha dovuto far marcia
indietro e, come al solito, introdurre delle modifiche che, per chi
programma 'seriamente' fanno un poco irritare (leggi: Array,BitOr/BitAnd,
True,Array,Option Strict Off...,Casting...)
Corrado


Io credo che l'unica cosa che SICURAMENTE Microsoft abbandonerà sarà VB6.
Quindi piuttosto aspetta qualche mese in piu' per iniziare la fase di
sviluppo, ma inizia con .NET
Io ho lo stesso problema. Dobbiamo riscrivere una serie di applicazioni
ormai superobsolete (hanno più di 5 anni), anche se per il nostro cliente
medio forse vanno ancora bene cosi'.
A settembre andro' ad un corso su 
VB.NET
, passero' i mesi che mancheranno
all'uscita della versione definitiva facendo prove e tentando di impararlo
il meglio possibile, e poi sviluppero' con quello.
Purtroppo io non ho a disposizione un team di sviluppo, dovro' fare tutto
... o quasi tutto ... da solo.
L'unica mia speranza (vana?!?) e' che la prima versione definitiva di 
VB.NET
non sia troppo bacata.
Per quanto riguarda il passaggio a C#, citando le parole di GioLib (che
secondo me VB se lo sposerebbe anche!)... abbiamo aspettato tutto questo
tempo perche' VB diventasse un linguaggio "Serio" e adesso che finalmente ci
hanno messo tutte le cose che chiedevamo cosa succede? Lo tradiamo con C#?
Tra l'altro qualcuno mi sa spiegare quali strabilianti funzioni possa avere
in piu' questo C# che possano essere gradite alla maggior parte degli
sviluppatori?
Ciao.
Skysurfer

 contenuti.
Marketing lingo. Non si può negare che C# sia il linguaggio di .Net...
Detto questo come sviluppare un'applicazione da zero se devi partire ora?
Dipende dall'applicazione, per quello che mi riguarda (applicazioni
pesantemente basate sul database) io le farei in VB6 dividendo per bene le
cose ed usando XML per tutti gli scambi di dati (no recordset), poi il
porting o il "mixing" di pezzi VB6 e pezzi .Net mi dovrebbe venire più
semplice.
Saluti
Massimo


Cerchiamo di capire che Dan Appleman ha da vendere un decennio di esperienza
in VB e quindi avrebbe delle difficoltà a riciclarsi come esperto C#....
Io non ci ho passato "parecchi mesi" ma qualche settimana sì e, almeno
secondo me, la produttività di C# è nettamente più alta di VB.Net. Poi
(sempre secondo me) è un linguaggio molto più bello, ma probabilmente
dipende dal fatto che dopo 4 anni di VB inizio ad averne un po le palle
piene...
Saluti
Massimo


E perchè non Delphi più facile e comq potente????
Ciao
Fabio


Delphi 6 ha anche la set next statement.
Non facile come quella di VB ma con un po' di sforzo si riesce a acvarla
fuori...
Ora, se mi mettono anche la edit&continue ci siamo quasi...
Ciaotutti,
*

 piene...
Può darsi, io lo uso da 10 anni e onestamente ero abbastanza annoiato da
VB6...
Corrado

 non credo che abbia certi problemi.
Io invece credo proprio di sì, considerando che il 90% delle sue utility,
dei suoi libri e dei suoi corsi è fatto su VB e che ha scritto un libro
dedicato al passaggio da VB a VB.Net. Se permetti non lo reputo una fonte
neutrale, mi piacerebbe leggere il suo ebook sulla comparazione tra C# e
VB.Net, ma non ho voglia di spendere 10 dollari.
Poi nulla in contrario sul personaggio, ho imparato dai suoi libri, l'ha
anche conosciuto di persona ad una PDC ed è una persona gradevolissima e,
tra i vari guru che conosco certamente sta nella top 5 (anche perchè alla
fine se la mena veramente poco), dico solo che ci sono una serie di fattori
che mi fanno pensare che i suoi commenti su VB.Net non siano imparziali.
Come altro commento teniamo anche presente che tutti questi "evangelist" o
guru che sono a stretto contatto con MS hanno una libertà di parola tutto
sommato limitata, devono alla fine dire quello che Microsoft vuole si
dica...
Saluti
Massim

 dell'operazione)
Certo, C++.NET (Managed C++), Perl.NET, Python.NET, Eiffel.NET.
Dubito 
VB.NET
 (spero di sbagliarmi), non perche' VB sia da
considerare meno, ma semplicemente perche' VB e' un linguaggio
proprietario, e quindi le cose si complicano un po'.
Ciao.

 cicli di 1 mese))...
Dipende molto dall'esperienza del programmatore e del materiale che riesce a
*riciclare* :-)
Nella fattispecie mi pare che siano tempi in linea con la complessità del
lavoro.
Ciao, Simone

Già che ci sono vi pongo qualche domanda da veri igniiiiioranti:
Ma il c# sarà il linguaggio di un tool visuale (come lo è quella specie di
basic per il vb)?
Visual Studio .Net conterrà anke i pacchetti del Vs 6 (sempre modificati e
con il nome terminante con un ".net") ?
Il VS .net sostituerà in pratica il Vs normale? Se sì, non uscirà il Vs 7,
giusto?
Sarà la fine del Vb (e VC++) come lo conosciamo?
Grazie a tutti e scusate per le troppe domande.
BelthaZor

 potrebbe convincermi del contrario?
Per i discorsi tecnici hai già sentito gli altri, io vorrei concentrarmi
sull'aspetto commerciale..
I motivi per passare a un altro linguaggio per un consulente-sviluppatore
possono essere 3:
1) Ti obbliga il mercato
2) Puoi fare delle cose che altrimenti non potresti fare
3) Guadagni di più.
Nel caso specifico al momento non viene soddisfatta nessuna delle 3
casistiche suddette.
Finora chi ha fatto da apripista per nuove tecnologie ha avuto almeno il 50%
di possibilità di restare scottato. Col passare del tempo arrivano strumenti
e documentazione che facilitano la migrazione, e nel frattempo capisci se
effettivamente vale la pena di cambiare. Se hai già cambiato e non valeva la
pena, o se lo hai fatto faticando il doppio di chi cambia dopo, nessuno ti
rimborsa.
Se per assurdo 
VB.NET
 permettesse di risparmiare tempo di sviluppo (e al
momento non è così) sarebbe addirittura da evitare la migrazione e da
sconsigliarlo al cliente. Certo, il cliente risparmierebbe, ma il consulente
di contro ci smenerebbe.
Se invece la tua applicazione che richiede 9 mesi di sviluppo, entro i suoi
5 anni di vita richiedesse un porting verso 
VB.NET
 per manifesta
obsolescenza di VB6, il fatto di non averla sviluppata subito in VBNet ti
consentirebbe di avere un lavoro (pagato) in + che non se lo avessi
sviluppato direttamente in 
VB.NET
. Un po' come è successo con i programmi
vittime del baco del millenio, che ad averci pensato prima continuavo anche
io a usare 2 cifre per gli anni fino al 1999, invece di cominciare a migrare
alle 4 cifre fin da 5 anni prima.
Facci caso. Al momento quelli che studiano i nuovi ambienti hanno dei
clienti che glielo chiedono specificatamente, oppure sono assunti e
stipendiati, o fanno parte del gruppo dei programmatori hard-core, quelli
cioè che oltre a campare col computer ne fanno anche una scelta di vita.
Just my 2 cents, obviously. E mi aspetto pure tegole a non finire. ;-)
Ciao
*Roby*
P.S.
Sto facendo la parte dell'avvocato del diavolo. Io stesso seguo (o meglio:
"sono vittima di" ) una deontologia professionale che spesso mi spinge a
fare gli interessi del cliente a scapito dei miei.
Spesso, ma non sempre. Alcuni clienti proprio se le meritano....

 di contro ci smenerebbe.
ammiro la tua onesta'. appena faccio 5+1 e ho l'occasione ti assumo.
come top-programmatore, non come consulente, of course :)

 nessuna delle 3 casistiche suddette.
Fare OOP non soddisfa forse il punto n° 2?
Ciao.

 Fare OOP non soddisfa forse il punto n° 2?
Non ho ancora trovato nessun caso in cui un programma non si possa scrivere
senza OOP.
E' come la ricorsione. Comoda per casi specifici, ma non è la panacea di
tutti i mali e se ne può anche fare a meno.
Ciao
*Roby*

 tutti i mali e se ne può anche fare a meno.
Non dico assolutamente che la OOP sia una panacea, questo e' ovvio
(e l'avevo gia' detto). Nello sviluppo di sw realmente buono
concorrono molti fattori, e certamente la sola giusta scelta di un
paradigma puo' fare molto poco.
Pero' la OOP e' *spesso* comoda e *spesso* l'approccio migliore,
anche se ci saranno sicuramente casi specifici in cui potrebbe
rivelarsi controproducente (in effetti, pero', non me ne viene in
mente neppure uno).
In caso di *grossi* progetti e' poi praticamente d'obbligo.
Perche' la OOP e' generalmente l'approccio migliore?
Perche' e' un investimento a lungo termine. Puoi pagare forse di
piu' all'inizio (maggior lavoro), ma ne sarai ripagato sicuramente
in seguito con una leggibilita' del codice migliore, con maggior
robustezza, con facilita' di manutenzione, estendibilita' e modifica
del codice molto, molto maggiori, con una possibilita' di riuso del
codice in progetti successivi che altrimenti sarebbe possibile con
il copia-incolla, ecc... Ed il riutilizzo del codice (evidentemente
gia' testato nei lavori precedenti) porta una ancora maggiore
robustezza dei progetti futuri. Perche' quindi farne a meno?
Ciao.

 il copia-incolla, ecc...
Io lavoro praticamente solo a grossi progetti, che spesso si basano su
famiglie di eseguibili diversi che lavorano su una base dati unica, e tutto
quello che tu elenchi viene reso anche senza utilizzare OOP, semplicemente
con l'uso di moduli di base condivisi e con la scrittura di OCX e classi che
fanno riferimento a quelle stesse funzioni di base.
Tutto ovviamente con VB6, che con la OOP ha ben poco a che spartire.
Sinceramente al momento della OOP non sento l'esigenza. Vedremo in futuro.
Ciao
*Roby*

 l'esigenza. Vedremo in futuro.
Perdonami, per quanta stima io abbia in te (e ne ho molta, viste le
tue capacita', che dimostri scrivendo su questo NG), il mio concetto
di progetti grossi non prevede la possibilita' dell'utilizzo del VB6
per la loro stesura. Il discorso in questo punto era generale e non
riferito (solo) a 
VB.NET
.
In effetti il mio concetto di progetti grossi non prevederebbe
neppure la possibilita' dell'utilizzo di 
VB.NET
 (a causa - come
spiegato in un altro post - della garbage collection), anche se
grazie all'essere finalmente OO e soprattutto grazie ad una gestione
delle eccezioni finalmente seria, le cose sono migliorate
infinitamente.
Ciao.

 riferito (solo) a 
VB.NET
.
Prima di tutto ti ringrazio per la stima, che è ovviamente reciproca come
dimostra il numero di messaggi tuoi salvati nella directory
"\visualbasic\messaggi_interessanti" del mio disco.
Comunque, se la metti da questo punto di vista, non posso che essere
d'accordo con te.
Però a questo punto (tornando al tema della discussione), visto che almeno
il 90% dei partecipanti all'area e degli sviluppatori in genere non
rientrano nella casistica dei "grandi progetti", per la maggioranza degli
utilizzatori VB non sembra esserci bisogno nè della OOP, nè del passaggio a
VB.NET
. ;-)
Ciao
*Roby*

tutti i mali e se ne può anche fare a meno.
...il confronto, a dire il vero, mi sembra un pochino
azzardato.
Oggigiorno tutti (o quasi) gli ambienti di sviluppo sono
orientati agli oggetti.
Il problema e' che della OOP se ne puo' fare a meno,
finquando non la si conosce bene.
--
Naquern Yansbetevn
naquern.y...@africamail.com

Certo che quando la conosci bene farne a meno è dura...
Corrado

 passaggio a 
VB.NET
. ;-)
Tralasciando a questo punto l'OOP, trovo l'avere una seria gestione
degli errori (chi non si e' guadagnato l'inferno almeno una volta
tentando di gestire seriamente gli errori in VB) ed una libreria di
classi che copra praticamente qualsiasi possibile necessita', due
validissimi motivi per il passaggio a 
VB.NET
 (o meglio al C#).
Ciao.

 Touchè. :-)
se e' per questo, non ho ancora trovato nessun caso in cui un programma
non possa essere svolto direttamente a manina, o al piu' con carta e
penna.
ciao, m.
--
mara...@tieni.mo

 Certo che quando la conosci bene farne a meno è dura...
ROTFL! questo singolo messaggio, avulso dal contesto, è aperto a 
innumerevoli interpretazioni :)))
Dimostrazione pratica della necessità di citare (e non "quotare", o 
bruti! :) parti del messaggio originale :)

 innumerevoli interpretazioni :)))
lol
--
Fibia "Sakamoto" FBI

 due validissimi motivi per il passaggio a 
VB.NET
 (o meglio al C#).
Contrastati da due validissime obiezioni. ;-)
Ciao
*Roby*

 penna.
Tu scherzi, ma mi sono spesso chiesto come mai, se lo scopo
dell'informatizzazione č far risparmiare tempo, serva cosě tanta gente che
lavori nel settore.
Mah, c'č qualcosa che non quadra!
Ciao
*Roby*


Lo scopo dell'informatizzazione e' far risparmiare tempo a chi USA il
prodotto... Dato pero' che nulla si crea e nulla si distrugge la somma dei
tempi rimane invariata :)
Ciaotutti,
Asterix

 problema è già superato.
Vogliamo fare un confronto di prestazioni? ;-)
Ciao.

 Vogliamo fare un confronto di prestazioni? ;-)
Quasi quasi...
Di solito tutto ciò che è + nuovo è anche più lento. Hai mai fatto test
comparativi tra ADO e DAO in modalità monoutente locale? E hai mai testato
le differenze di velocità tra una query SQL e una buona vecchia Seek? ;-)
Comunque le prestazioni non sono un problema. O almeno questo è quello che
ha sempre detto M$.
Ciao
*Roby*

Onde evitare 'incomprensioni' sottolineo il fatto che il mio messaggio si
riferiva alla programmazione OOP :-) Questa volta effettivamente avrei
dovuto 'quotare' il messaggio, mea culpa ;-)
Corrado

 ha scritto nel messaggio
news:8ECb7.139814$Pb6.7...@news1.tin.it...


 le differenze di velocità tra una query SQL e una buona vecchia Seek?
;-)
:) <-------------- ENORME smile
sotto il codice, per non infierire con un post da 40k, metto solo i
tempi finali.
Option Explicit
Dim fNum As Integer, fName As String
Dim db As Database, rs As Recordset
Dim time1, j As Byte, jj As Byte
Private Sub cmdSeek_Click()
    time1 = Timer
    fNum = FreeFile
    fName = App.Path & "\test_seek.txt"
    Open fName For Output As #fNum
    Print #fNum, Now
    Set rs = db.OpenRecordset("file")
    With rs
        .Index = "filname"
        .MoveLast
        Print #fNum, "TABELLA FILE: SCHEDE " & CStr(.RecordCount)
        Print #fNum, "--------------> " & Format(Timer - time1,
"###,###,##0.00")
        For j = 97 To 122
            Caption = Chr(j)
            .Seek ">=", Chr(j)
            If Not .NoMatch Then
                For jj = 0 To 9
                    Print #fNum, !filname & " :: " & !filsize & " :: " &
!fildate
                    .MoveNext
                Next
            Else
                Print #fNum, Asc(j) & " ---> NON TROVATO"
            End If
        Print #fNum, "--------------> " & Format(Timer - time1,
"###,###,##0.00")
        Next
    End With
    rs.Close: Set rs = Nothing
    Print #fNum, Now
    Print #fNum, "--------------> " & Format(Timer - time1,
"###,###,##0.00")
    Close #fNum
End Sub
Private Sub cmdSql1_Click()
    time1 = Timer
    fNum = FreeFile
    fName = App.Path & "\test_sql1.txt"
    Open fName For Output As #fNum
    Print #fNum, Now
    Set rs = db.OpenRecordset("select count(*) from file",
dbOpenDynaset)
    Print #fNum, "DYNASET FILE: SCHEDE " & CStr(rs.Fields(0))
    Print #fNum, "--------------> " & Format(Timer - time1,
"###,###,##0.00")
    For j = 97 To 122
        Caption = Chr(j)
        Set rs = db.OpenRecordset("select top 10 * from file where
filname like '" _
                & Chr(j) & "*'", dbOpenDynaset)
        With rs
            For jj = 0 To 9
                Print #fNum, !filname & " :: " & !filsize & " :: " &
!fildate
                .MoveNext
            Next
        End With
    Print #fNum, "--------------> " & Format(Timer - time1,
"###,###,##0.00")
    Next
    rs.Close: Set rs = Nothing
    Print #fNum, Now
    Print #fNum, "--------------> " & Format(Timer - time1,
"###,###,##0.00")
    Close #fNum
End Sub
Private Sub cmdSql2_Click()
    time1 = Timer
    fNum = FreeFile
    fName = App.Path & "\test_sql2.txt"
    Open fName For Output As #fNum
    Print #fNum, Now
    Set rs = db.OpenRecordset("select count(*) from file",
dbOpenDynaset)
    Print #fNum, "DYNASET FILE: SCHEDE " & CStr(rs.Fields(0))
    Print #fNum, "--------------> " & Format(Timer - time1,
"###,###,##0.00")
    For j = 97 To 122
        Caption = Chr(j)
        Set rs = db.OpenRecordset("select top 10 * from file where
filname like '" _
                & Chr(j) & "*' order by filname, fildate, disknum",
dbOpenDynaset)
        With rs
            For jj = 0 To 9
                Print #fNum, !filname & " :: " & !filsize & " :: " &
!fildate
                .MoveNext
            Next
        End With
    Print #fNum, "--------------> " & Format(Timer - time1,
"###,###,##0.00")
    Next
    rs.Close: Set rs = Nothing
    Print #fNum, Now
    Print #fNum, "--------------> " & Format(Timer - time1,
"###,###,##0.00")
    Close #fNum
End Sub
Private Sub Form_Load()
    Set db = OpenDatabase(App.Path & "\diskcat.mdb")
End Sub
seek:
--------------> 1.40
sql1 (record ordinati alla come viene va bene):
--------------> 24.76
sql2 (record ordinati come l'indice del seek):
--------------> 689.65
db:
 Directory di D:\diskcat
20/05/2001  15:21          491'112'448 DiskCato.mdb
10/05/2001  12:37          528'320'512 DiskCat_.mdb
20/05/2001  15:34          482'248'704 DiskCat.mdb
               3 File  1'501'681'664 byte
               0 Directory   4'889'739'264 byte disponibili
dati presi con select count(*):
DB SIZE: 482'248'704 :: 0.01
DISK: 682 :: 0.03
DIR: 174'924 :: 0.09
FILE: 4'464'250 :: 2.00
celeron 500, ram 256, ibm 30g, fat32.
forse con uno snapshot le query qualcosa migliorano, ma mentre faccio
seek posso anche modificare, andare avanti e indietro, e se sono sveglio
anche modificare la chiave su cui lavora l'indice. un mio clipper lo fa
da anni in mano a utenti normali e se dio vuole non ha perso un bit. in
sql...
detto questo, solita storia: di li' si dovra' passare. si dovra'
consumare meno acqua. si dovra' inquinare di meno. ecc. ecc. -- sulla
terra siamo tanti, e tutti ansiosi di guardare contemporaneamente lo
stesso db :)
ma per favore non ditemi che e' meglio.
ciao, a.

 wrote in message
news:N5Fb7.84561$%7.60...@news6.giganews.com...

Ecco, peccato che che non si capisca di quale messaggio parli visto che non
l'hai quotato :P
Ciaotutti,
*


Eheh... Lo zio e' sempre impeccabile :P
Stessa storia sara' con 
VB.NET
, tanto le prestazioni non sono un problema...
Solo che guarda caso oggi con i processori a non-sai-quanti GHz ottengo le
stesse prestazioni che dieci anni fa ottenevo con pochi MHz da un 386...
Vero, ci faccio cose diverse, ma mi pare strano lo stesso, che dite?
Ciaotutti,
*

 fino all'istruzione che ha generato l'errore.
Beh, finalmente qualcosa di nuovo. ;-)
Resta da capire se basti per giustificare il passaggio ad un linguaggio
nuovo. Non sarebbe difficile modificare il postprocessore di cui parlavo
alcuni messaggi fa per fargli scrivere una riga di log ogni volta che si
entra in una routine, in modo da generare una modalità di debug che soddisfi
anche questo requisito.
Ciao
*Roby*

 Vero, ci faccio cose diverse, ma mi pare strano lo stesso, che dite?
toh ! un altro che prova la mia stessa identica sensazione !
:)

 anche questo requisito.
Credo che la gestione delle eccezzioni C++ (e Java) like sia solo uno dei
tanti motivi percui credo valga la pena dare un occhio a VBNet, poi in base
alle varie 'reazioni' ognuno prenderà la propria decisione...
Ciao
Corrado

 toh ! un altro che prova la mia stessa identica sensazione !
Beh, ma oggi le stesse cose le facciamo con molti piů colori, e per
spiegarne il funzionamento abbiamo a disposizione un sacco di acronimi di
tre lettere in piů.
Vuoi mettere? ;-)
Ciao
*Roby*
P.S.
Non staremo mica diventando tutti dei vecchi bacucchi reazionari, eh?

 alle varie 'reazioni' ognuno prenderà la propria decisione...
E' tutto il thread che sto cercando di capire quali siano queste features
veramente indispensabili che possano giustificare il passaggio ad un nuovo
linguaggio. Vuoi provare a spiegarmelo tu?
Però, parlo di features veramente indispensabili, non di somma di
funzionalità comode ma facilmente emulabili, come ad esempio la possibilità
di agganciare i controlli ai bordi per gestire automaticamente i resize
delle form.
Ciao e grazie
*Roby*
P.S.
Oltretutto neppure in questa versione mi hanno messo il controllo
ortografico dei commenti. Sono 3 versioni che lo richiedo a M$ sicuro che
sia una feature abbastanza stupida da essere inserita in cima al ToDo di
progetto, eppure anche stavolta mi è andata buca... ;-)
Però un mio conoscente in M$ Italia dice che si può emulare con una macro di
Word...

 Vuoi provare a spiegarmelo tu?
Dovrei sapere il tipo di applicazione che abitualmente sviluppi, potrei
dirti Console Applications, NT Services, ASP Net,
ADO.NET
,WebServices,
supporto nativo a XML.
Ma forse anche solo il fatto che non devi più diventare matto a registrare
le DLL ma basta un XCOPY oppure il fatto che se vuoi creare un timer non hai
più bisogno del controllo..., se ti piace andare a basso livello, puoi
semplicemente intercettare la WndProc del form (senza nessun controllo
oppure AddressOf) puoi ereditare e 'customizzare' i controlli 'nativi' di
windows tipo textbox/combobox....
Puoi lavorare con GDI+ in modo facile e senza diventare matto con Brushes,DC
e handle che restano in memoria.
Se ti piace OOp hai finalmente l'ereditarietà con tutti annessi e connessi
(vedi Shadows,Overridable,Overloads...)
Se sei un amante del multithreading puoi crearti applicazioni 'veramente
multithread' e non 'apartment threaded' come VB6.
Puoi intercettare tutti i vari messaggi di windows (tipo
PowerState,shutdown) senza diventare matto con controlli oppure API, hai un
menu editor (decente) hai la print preview dei documenti...
Se parliamo di Web puoi crearti un applicazione che gira sotto IIS e
interroga un database in circa 10 righe...
Quando crei un nuovo componente non devi più diventare matto che le nuove
interfacce vadano in conflitto con quelle vecchie (references) oppure che
qualcuno installi una versione incompatibile del tuo componente...
Finalmente la famosa ETC è andata (o quasi), i vari controlli
listbox,listview,treeview sono stati potenziati (puoi avere elementi con
colori e font diversi, e immagini di sfondo...)
Se vuoi durante il debug puoi vedere il disassemblato che sta girando (se
proprio vuoi...) Puoi mettere delle istruzioni di debug tipo
debug.WriteLineIf(condizione)
Cosa hai perso?
La possibilit di brekkare il programma, modificare il codice e continuare
(questo mi manca molto!) ma però mi sto abituando.
Ciao
Corrado


 O almeno questo è quello che ha sempre detto M$.
E' quello che dico anche io, ma dovevo pur trovare qualcosa per
contestarti :-P
Comunque un confronto l'avevo fatto in passato. Per la lettura di un
file di 50 MB circa VB impiegava sul mio PC (PII 400) 40 s
utilizzando le funzioni native, e 13 s utilizzando il File System
Object. 
VB.NET
 impiegava 3 s, al pari di un equivalente in C++.
In questo caso la differenza e' troppo elevata perche' non sia
importante.
Ciao.

 MsgBox ("Finally viene sempre eseguita")
L'esempio era semplice e banale, pero' non e' corretta
questa gestione degli errori.
Se ci sono piu' righe di codice che possono causare errori,
verrebbero normalmente eseguite tutte (per via del Resume Next),
cosa che, in caso valori errati (come nel caso della divisione per
zero), potrebbe portare a successivi errori (pensa in caso di
chiamate ad altre funzioni passando parametri errati), e/o quasi
sicuramente ad un malfunzionamento del programma.
Quindi, per sospendere ad ogni errore
On error GoTo ErrHandler
    'istruzioni che possono creare delle eccezioni
    fRatio=CInt(5/Value)
ErrHandler:
    Select case Err
    ....
    End Select
Finally:
    MsgBox ("Finally viene sempre eseguita")
In questo caso hai in parte anche una migliore separazione della
gestione degli errori dal codice normale. In parte, perche'
non si comprende a prima vista che la clausola "Finally"
venga eseguita anche in caso di assenza di errori.
Tutto il blocco select viene pero' comunque valutato, anche in
assenza di errori.
A questo punto sorge un altro problema. Se il codice in questione
fosse all'interno di una funzione che deve restituire un valore,
come notificare ai chiamanti che i valori restituiti potrebbero non
essere validi (perche' si sono verificati errori)? Oltretutto la
funzione, essendo (e dovendo essere) generica difficilmente potra'
prevedere essa stessa la soluzione (per es. un valore di default),
ma dovranno essere i vari chiamanti a gestire l'errore.
sub sub1()
On error GoTo ErrHandler
    dim a as integer
    a = function1
ErrHandler:
    Select case Err
    ...
    'le informazioni che avro' qui sugli errori saranno poche
    End Select
Finally:
    MsgBox ("Finally viene sempre eseguita")
end sub
function function1() as integer
dim Value as integer
Value = 0
On error GoTo ErrHandler
    'istruzioni che possono creare delle eccezioni
    function=CInt(5/Value)
ErrHandler:
    Select case Err
    Case 11
        'gestisce in qualche modo l'errore
        Err.Raise 11
    ....
    End Select
Finally:
    MsgBox ("Finally viene sempre eseguita")
end function
Cosi' pero' si perde l'utilizzo della clausola Finally, non c' e' la
possibilita' di aggiungere nuove informazioni all'errore senza
perdere quelle vecchie e, soprattutto, per cercare di creare una
gestione degli errori che sia il piu' generale possibile e realmente
valida si finisce per ottenere qualcosa veramente illeggibile e
difficile da modificare in seguito.
La gestione degli errori con try...catch, rende tutto molto piu'
semplice.
sub sub1()
    dim a as integer
    try
        a = function1
        ....
    catch ex as exception
        'gestisce l'errore.
    end try
end sub
function function1() as integer
dim Value as integer
Value = 0
try
    'istruzioni che possono creare delle eccezioni
    function=CInt(5/Value)
catch ex as DivideByZeroException
    ....
    throw new exception("Mi_sono_inventato_un_errore", ex)
catch ex as exception
    ....
    throw 'rilancia la stessa eccezione
finally
    MsgBox ("Finally viene sempre eseguita")
end function
Ciao.

 costante.
No, DivideByZeroException non e' una costante, ma e' classe
(ereditata da Exception).
Ciao.


E la compatibilita' con tutto il codice precedente... Chiariamo una cosa, a
parte le quattro genialate M$ (itemdata, SNS, E&C, immediate) 
VB.NET
 non e'
una brutta piattaforma, solo che essendo incompatibile con VB6 io
personalmente non lo usero' se non saro' costretto.
Piuttosto passo a Delphi, con il quale sono riuscito a ricompilare in 6 un
programma scritto per il 3, senza problemi...
Ciaotutti,
*


Io ho provato ad aprire un'immagine compressa con un 286: ci mette una
vita...
Ora con un qualunque processore di fascia bassa la stessa immagine la apro
in un secondo o due.
Questo e' giusto.
Meno giusto e' che un vecchio 286 bootasse in trenta secondi e un nuovo win
2000 booti in due minuti...
Ciaotutti,
*



Ecco, vorrei capire come sia possibile che un codice VB legga un file in
tempo X e un codice 
VB.NET
 lo legga in tempo Y DIECI VOLTE piu' piccolo...
Va bene tutto ma c'e' qualcosa che non quadra da qualche parte...
Ciaotutti,
*

 > Non staremo mica diventando tutti dei vecchi bacucchi reazionari,
eh?
quanto a me temo di si'. almeno per la comatosa lingua nazionale :)


Ma per carita', continua cosi' che vai solo bene...
Pero' ogni tanto un paio di anglicismi te li tiro in giro :)
Ciaotutti,
*

 programma scritto per il 3, senza problemi...
Premessa:
Rispondendo al tuo messaggio ho cercato di farti capire cosa può fare VBNet,
se poi lo userai o meno, francamente poco mi importa.
L'unica cosa che posso consigliarti è: ma perche (finalmente) non passi a
Delphi?
Corrado

 qualche parte...
Certamente, quello che non va e' l'accesso ai file di VB, che in
caso di file di grosse dimensioni si dimostra semplicemente penoso.
Ciao.

 E la compatibilita' con tutto il codice precedente...
La piattaforma .NET non nasce per essere compatibile con il passato.
Le applicazioni VB dovranno continuare ad essere mantenute in VB e
solo quelle nuove saranno sviluppate sotto .NET.
Ciao.

 Nel primo caso il linguaggio e' VBScript o JScript
Ovviamente ho scritto una stupidata. Ovviamente non sei legato a
questi due soli linguaggi, ma al fatto che siano linguaggi di
scripting e pertanto interpretati.
Ciao.

 supporto nativo a XML.
Se penso al mio caso specifico, sono praticamente certo che non passerò a
VB-NET.
Attualmente faccio pacchettizzati multimediali per il grande pubblico, che
accedono ad internet solo marginalmente (non scendo nel particolare per
evitare di fare pubblicità).
Praticamente il più grande ostacolo è che devo fare i conti con la
configurazione hardware dell'utente e con la limitatezza del supporto fisico
su cui distribuisco il programma. Ad esempio non passo neppure ad ADO per
evitare di dover installare MDAC, che mi occupa spazio e sul supporto, e mi
diminuisce sensibilmente le prestazioni rispetto al DAO.
Se penso all'eventualità di distribuire il layer di base di 
VB.NET
bruciandomi 1/6 dello spazio del CD mi viene semplicemente da ridere.
Ma io non volevo fare un discorso personale. Il tutto è iniziato da
considerazioni commerciali (vai un po' indietro nel thread, magari con Deja
e trovi il messaggio originale) e sono passato al campo tecnico addirittura
controvoglia.
Comunque, tanto per affrontare anche quest'ultimo argomento, prima di tutto
grazie per la lista delle feature che hai postato. Devo dire che sono
parecchie le cose che mi piacciono in 
VB.NET
, soprattutto GDI+ e la
soluzione del problema del "DLL Hell", ma è una soluzione tardiva (ormai
abbiamo imparato a girare intorno ai problemi) e che mi presenta un conto da
pagare troppo oneroso in termini di riscrittura del codice e di
aggiornamento personale. Per quel che mi riguarda starò alla finestra
(window ? ;-))ancora per un bel po', in attesa che siano i miei clienti a
chiedermi di cambiare linguaggio.
Fino a che questo non succede, si tratterebbe di un investimento inutile e
di un rischio troppo grande, visto la estrema facilità con cui M$ cambia
idea sull'indirizzo dei suoi prodotti nuovi. Quando succederà, passare al
nuovo linguaggio (se sarà ancora quello il linguaggio di scelta) sarà +
semplice a causa della quantità di documentazione e sorgenti che
circoleranno.
Ciao
*Roby*


Vedi sopra :P
Solo che ho qualche anno di skill in VB che per un po' mi tornera' comoda...
Certo e' che VB e' morto.
Ciaotutti,
*

 Delphi?
Ribadisco, il messaggio a cui hai risposto era mio, non di Alessandro. Io
non passo a Delphi per lo stesso motivo per cui non passo a 
VB.NET
: pur
essendo migliore di VB6, non è abbastanza diffuso e richiesto, e se sono
fortunato non lo sarà mai. ;-)
Ciao
*Roby*
P.S.
Non ti accalorare, stiamo qui per passare il tempo tra amici parlando di
argomenti comuni, mica per litigare. :-)


Mmm... Io leggevo il file con una singola ReadAll / Get #f, s ... In questo
caso VB era piu' veloce.
Ciaotutti,
*

 essere validi (perche' si sono verificati errori)?
Beh, è buona norma che qualunque funzione restituisca, oltre al valore
richiesto, anche un codice di errore se non è stato possibile eseguire
l'operazione. Normalmente per funzioni complesse si inserisce anche un
parametro booleano che stabilisce se il messaggio di errore deve essere
trattato localmente alla funzione, oppure se basta che venga restituito il
codice di errore in uscita.
Forse non abbiamo la stessa concezione della gestione di errori. Per me gli
errori più importanti da trappare sono quelli che vengono generati da agenti
esterni al programma. Ad esempio finisce la carta della stampante, oppure
finisce lo spazio su disco, o il database che si cerca di aprire è bloccato
da un altro utente che "furbamente" lo ha aperto con access in modalità
struttura, oppure è caduta la connessione  ametà di un trasferimento dati.
I casi di errori "di programma" come la division by zero, possono anche non
essere trattati, se non con un avviso che servirà al programmatore per
mettera una pezza al codice scritto evidentemente male.
Ora, gli errori da eventi "esterni" è meglio che vengano gestiti da una
funzione generalizzata perchè, pur non essendo prevedibili, presentano
sempre le stesse caratteristiche. Es: "E' finito lo spazio su disco. Cosa
vuoi fare? Svuoti il cestino, riprovi perchè hai cancellato qualcosa a mano,
o termini il programma?"
La gestioni errori residua si riduce a qualche "on error resume next" usata
nelle funzionalità di resize delle form, per evitare che i controlli
assumano dimensioni inferiori a 0, o a robe simili.
Se poi esce un errore diverso, viene comunque trappato dalla funzione
generica, che lo scrive in un log su disco (in modo che l'utente che si
dimentica sempre l'errore abbia modo di comunicartelo comunque) e si
modifica il programma in modo che non si verifichi + l'errore nel futuro.
In questo senso dico che la gestione errori attuale va già bene così com'è.
Certo, la Try Catch è meglio perché ti da più informazioni, ma a parte
quello, probabilmente finirei per utilizzarla allo stesso modo della
gestione errori attuale.
Ciao
*Roby*


E su questo ho qualche dubbio :P
Cmq condoglianze vivissime :PP
Ciaotutti,
*

      Loop
La prova č interessante, ma saranno almeno 3 anni che non uso piů una line
input. Cosa te ne fai?
Se hai a che fare con grosse moli di dati, immagino che si usi un database
piů serio che non un semplice file di testo, e se invece i dati sono
ragionevolmente pochi (come ad esempio nel trattamento dei files RTF),
conviene caricarsi in memoria tutto in un colpo solo (e immagino che in
questo caso la differenza di prestazioni sia decisamente inferiore).
Se anche si trattasse di una importazione di dati partendo da una sorgente
diversa, ad esempio un altro sistema operativo, č molto meglio usare come
file intermedio un archivio con record a struttura fissa, e anche qui sono
convinto che la differenza di prestazioni sia decisamente minore.
Ciao
*Roby*

 milioni...
Complimenti! ;-)
Comunque se ti può essere d'aiuto io uso lo Spread della FarPoint, che costa
decisamente meno, ha almeno due distinte funzionalità di stampa, e ha anche
una limitata compatibilità con Excel.
Lo trovi qui: 
http://www.fpoint.com/
Io l'ho usato fino alla 3.0. Ora sta uscendo la 3.5, ma non la conosco. Se
vuoi informazioni, chiedi pure.
Ciao
*Roby*


Mi sarebbe stato molto utile tipo sei mesi fa :PP
Ormai il CD e' fuori e a Dio piacendo non lo rivedro' per un annetto :P
Cmq grazie :-)=
Ciaotutti,
*

avevo bisogno...
Voglio fare una precisazione, le costanti Vbxx... sono ancora presenti nel
namespace Microsoft.Visualbasic.constants
quindi se scrivi (o meglio lo fai fare al wizard di conversione)
Imports Microsoft.VisualBasic.Constants
Le righe:
Dim s as string
s="Uno" & vbcrLf $ "Due"
sono valide in VBNet.
Notizia dell'ultim'ora (non confermata): Sembra che nella RTM di VBNet verrà
reinserito Edit & Continue.
Corrado


Ecco, gia' questa notizia mi riporta molto vicino a VB.NET...
A questo punto probabilmente ci sara' anche la set next statement, che e'
requisito minimo per la E&C...
Benebenemoltobene...
Ciaotutti,
*

 requisito minimo per la E&C...
La Set Next Statement esiste già adesso, l'unica cosa che non puoi fare è
modificare il codice mentre sei in debug mode.
Corrado

 va già bene così com'è.
Non dico che cio' che si fa con la gestione delle eccezioni non
possa essere fatto senza, pero' e' sempre lo stesso discorso: il
risultato e' codice poco leggibile, di difficile manutenzione e
modifica, e' piu' facile commettere errori, ed alla fine per
ottenere codice di buona qualita' e' necessario un tempo maggiore;
con il risultato che, con la cronica mancanza di tempo, la qualita'
del sw non e' mai come potrebbe essere, anche a parita' di tempo,
utilizzando strumenti piu' adatti.
Ciao.

 E su questo ho qualche dubbio :P
Sinceramente ognuno sceglie gli strumenti piu' adatti al lavoro che
deve svolgere. E farebbe male a non fare cosi'.
Ciao.

 ReadAll / Get #f, s ...
Stiamo gia' parlando di un file di quasi 50 MB.
Leggerlo tutto in una singola ReadAll mi pare un'ottima maniera di
portare il SO al limite.
Ciao.

 solo
Se puoi avere la certezza che i dati siano sempre e comunque pochi.
Ma non e' detto che la si possa sempre avere.
Ciao.

"H.P.L." <u...@vaila.ble> wrote in message
news:NACc7.1720$Xf5....@news.infostrada.it...

Il mio era di 3M: per leggerlo tutto co una ReadAll ci metteva tipo dieci
minuti.
Penso che legga un byte, verifichi l'EOF, riallochi la stringa, legga un
altro byte ecc...
Ciaotutti,
*


Avevo letto che avevano tolto pure quella...
A 'sto punto quando esce la definitiva gli do' almeno un'occhiata,
quantomeno per parlarne con delle certezze in mano...
Ciaotutti,
*

 avvii senza dare schermo blu :P
eddaje. il club dei prevenuti (cogitus interruptus?) con ms si allarga
:)
almeno quello ( quello che dici qui sopra -- cosa ti credevi ? :P ) _e'_
ovvio.
se non si avvia, come fa a darti schermo blu ?

 utilizzando strumenti piu' adatti.
Ma se per imparare ad usare gli strumenti adatti ci metto più del tempo che
mi farebbero risparmiare, c'è qualcosa che non quadra in questo
ragionamento.
Ciao
*Roby*
P.S:
Scusa per il ritardo nella risposta. Non mi ero accordo che il thread era
proseguito.

 c'è qualcosa che non quadra in questo ragionamento.
Se li dovessi utilizzare una volta sola il ragionamento sarebbe
valido, ma in una visione a lungo termine no.
Ciao.

 valido, ma in una visione a lungo termine no.
Al momento di visioni a lungo termine non ce ne sono. Qui i linguaggi
passano di moda fin troppo in fretta per i miei gusti, e fino a che non avrò
la certezza matematica che VB6 sarà abbandonato da tutti a favore di VB.Net,
me ne sto tranquillo a guardare.
Ciao
*Roby*

 Qui i linguaggi passano di moda fin troppo in fretta...
[cut]
Si ritorna alle differenze che evidenziavo in un post precedente fra
linguaggi ed ambienti di sviluppo.
Ciao.