Visual Basic 6 - Visual Basic 6 e Windows 7/10

Vedi che sei scortese? Forse non te ne rendi conto.

Rispondi in maniera impersonale, con mezza frase, in modo arrogante, senza dialogare, mezza frase che, fra l'altro, non ha senso.

In alto a sinistra c'è il PERCORSO ... dal Forum --- alla sezione Visual Basic 6 ---

Il Forum si occupa di tanti linguaggi (prova fare click su Forum !)
Poi vai nella sezione Visual Basic 6 e qui proponi un problema VB6

Cosa che tu NON hai fatto, parlando di un confronto con VB.NET che era meglio proporre in una sezione più generale.

Comunque, secondo me questo thread è veramente diventato OT all'interno di questa sezione.
Segnalo al moderatore per la chiusura dato che non esiste un vero problema.

Non è mio costume ma mi ripeto:

In questa sezione si discute di VB6, ho postato una domanda semplice: qualche programmatore usa ancora VB6?

Per ora sembra che solo Carlos condivide con me la gioia di usare questo stupendo linguaggio, gli altri lo fanno solo perchè costretti a mantenere vecchi obsoleti applicativi e ne prendo atto.

Quando ho nominato VB.net in questa sezione, l'ho fatto in riferimento alla velocità di esecuzione (é giusto di un solo Thread) ed ho anche postato del codice che riempie una listbox ed aggiorna una label.
Non ho fatto una cosa astratta, mi aspettavo che qualcuno mi dicesse: "guarda che in VB.net non si programma così, stai usando VB.net con la logica di VB6 ed è sbagliato".

Un esempio serebbe stato gradito, invece di scagliarvi contro di me come se volessi attaccare VB.net.

Tornado al codice e all'efficienza nel ciclo di for dove riempio la listbox ho inserito l'istruzione:

label1.refresh

un errore poichè è inutile aggiornare la label migliglia di volte, infatti modificando la riga in:

if Ciclo mod 100 = 0 then label1.refresh

si aggiorna la label 1 volta ogni 100 cicli con un guadagno in velocità di esecuzione del 100% sia in VB6 che in VB.net

No ... non hai posto questa domanda. Rileggi bene il tuo primo post.
Hai fatto solo "affermazioni" come fossero verità universali.



La "gioia" non c'entra nulla. Questo "è stato" uno stupendo linguaggio calato nel suo tempo e nel suo contesto.
Ma adesso è obsoleto, c'è poco da difendere, al di là del tuo entusiasmo.
E te lo dice uno che è stato, per un po' di anni, MVP per VB6 e che quindi una certa esperienza ce l'ha.



Se si ha onestà intellettuale e preparazione nel campo (mi dispiace, ma sembra che tu non sia del campo, come io non sono del tuo e per questo non mi azzardo a giudicare migliore una telecamera di 15 anni fa rispetto ad una di questi tempi ...), si DEVE prendere atto che è necessario utilizzarlo solo per progetti attivi e non per altro.



Quindi non hai fatto quella domanda di cui parli. Ma hai proposto un confronto tra le piattaforme. E' un'altra storia.

Il confronto non si fa sul riempimento di una listbox ma sulle caratteristiche globali, come ti ho già detto.
Gestione della sicurezza, gestione della memoria, possibilità di scrivere codice a 32/64 bit, possibilità di scrivere applicazioni client (non solo Windows Form ... c'è altro ...), ma anche web e app per smartphone (con possibilità di gestire diversi tipi di smartphone, vedi Xamarin) .... Insomma, un confronto tra due piattaforme non si fa così. Se non sei d'accordo, me ne farò una ragione ...



Nessuno si scaglia contro di te. Ci sono state risposte di gente che ci lavora con queste cose e che ti ha spiegato come stanno le cose ma tu hai (scortesemente, confermo) snobbato tutti indicando che doveva rispondere solo chi era d'accordo con te ... andiamo ...





E non solo ... anche l'assegnazione del dato nella label deve stare nella if, perché non serve finché non si vede ...

E dovresti aggiungere una SuspendLayout / ResumeLayout per la Listbox dato che il ridisegno durante il ciclo non ha senso.
E dovresti eliminare il riferimento di compatibilità Microsoft.VisualBasic in modo da usare classi e modalità di lavoro propri del VB.Net e non del VB6. Ricorda che un Long per il VB.Net è a 64 bit e non a 32 come per il VB6 ... (e l'Integer è a 32 non a 16...) ...

E devi tenere presente che la compilazione per il codice .NET avviene JustInTime ...

Insomma, se non ci lavori, puoi continuare ad utilizzare VB6 (o anche il Quick Basic se vuoi ...).

Se sei nel campo, allora devi solo gestire i tuoi progetti in produzione e iniziare i nuovi con .NET e gli "affetti" non c'entrano nulla. Io avevo, fino a qualche anno fa una grande e delicata applicazione VB6 ... l'ho riscritta (con calma e pazienza) in C# (che preferisco) e adesso sono libero da tanti problemi che NON mi portava il VB6 ma l'avanzare della tecnologia e degli ambienti in cui il programma veniva eseguito. Però ho anche tratto giovamento da .NET le prime volte che ho risolto problemi in pochi minuti, con poche linee, invece che con mille API e il VB6 ...

Ho anche scritto una grande parte di codice (in C++) collegata di un'altra applicazione VB6 (scritta da altri) che attualmente è in produzione in diversi paesi del mondo. Quella NON può essere migrata facilmente (non dipende solo da me) perché prevede investimenti e tempi notevoli, che non si sono voluti fare. Adesso ci sono ENORMI problemi a fare girare il tutto e si devono trovare PC appositi con configurazioni ad hoc molto traballanti per poter continuare a produrre. E tra qualche anno, quando veramente qualcosa bloccherà completamente il suo funzionamento, l'azienda in questione si troverà nei guai ... gli darò il tuo indirizzo per risolvere ... :-)

Concordo anch'io sul fatto che VB6 sia un linguaggio superato, ma possiede tuttavia ancora enormi vantaggi in termini di sviluppo con debug interattivo di applicazioni commerciali e scientifiche anche di centinaia di migliaia di istruzioni.
Faccio un esempio: applicazione commerciale per la gestione direzionale di una certa attività, codice legacy in VB6, alcune centinaia di migliaia sia di istruzioni che di contratti. Qualcosa di simile è andato a gara per trasformare l'applicativo VB6 in web application, alla modica cifra di 3,9 milioni di euro!

Personalmente avevo già risolto la cosa 15 anni fa, in ASP puro, business layer con DLL Active X, che funzionava perfettamente sia su EXE locale, che su web server remoto o locale. Col tempo ho perfezionalo la tecnica, abbandonato l'ASP puro, e passato ad un presentation layer preferibilmente su pagine ASPX, ma che può essere qualsiasi altra cosa, visto che il dialogo avviene semplicemente tramite request URL e response JSON.

Bene, finisco presto, il codice è scritto in VB6/VB.NET con poche istruzioni di compilazione condizionale, i dolori nascono - in NET - quando devo effettuare il debug ed avrei voglia di provare a cambiare qualcosa al volo, ma usando ASPX sono obbligato ad interrompere l'esecuzione, sperare di aver scritto bene le modifiche e rilanciar.
Allora, sempre in NET, posso usare dei form che simulano le URL trasmesse e sanno cme fare il parsing della risposta JSON, ed in tal caso posso fare più modifiche, ma prima o poi VB,NET si stufa e mi obbliga a riavviare.
Quando il gioco si fa duro i duri cominciano a giocare, ed ecco che il tanto bistrattato VB6 si prende la sua bella rivincita, consentendo al programmatore di fare al codice quello che vuole, senza perdere tempo inutile e la concentrazione, riuscendo così a risparmiare ore, se non giorni, nello sviluppo di applicazioni di notevole complessità e delicatezza.
Anche per il data layer è possibile scrivere delle funzioni che creino le istruzioni SQL parametriche in funzione del RDBMS, eseguendo e rieseguendo query senza dover stoppare/riavviare n volte.

P.S. Oltre 3 milioni per ribaltare un codice VB6 con N prodotti di terze parti,quando basterebbe semplicemente separare il business layer dal presentation layer e dal data layer, e poi adeguare solo alcune istruzioni...

Con un computer modesto si può lavorare in VB6.
Visual Studio 2017, si aspetta almeno un i5, anche perchè esegue una miriade di compiti, poco importa se questi compiti poi sono utilizzati dal programma che si sta sviluppando.
E' anche vero che Visual Studio 2017 si può configurare per ottimizzare la sua performance, poco importa se per configurarlo bisogna studiare più di apprendere il linguaggio stesso.
Sto lavorando in VB.NET e studiando C#, sono anche soddisfatto, ma quando per lavoro riapro progetti in VB6, la fantastica velocità di risposta mi lascia sconcertato.

Ho un computer di 15 anni fa in cui faccio girare programmi in GWBASIC e QUICKBASIC e vanno velocissimi ...

Vi sembra che siano discorsi da fare per gente che lavora in questo mondo? Capisco chi si occupa d'altro nella vita, può dire quello che vuole, ma in un forum di programmatori, in teoria addetti ai lavori, certe cose non si possono leggere ...

VB6 si basa sul Component Object Model e COM è una tecnologia superata e piena di problemi (uno per tutti, il problema "DLL hell" ...).

La tecnologia .NET li supera e semplifica enormemente gli strati sottostanti, restando integrata col sistema operativo.

Ma c'è chi vede solo come funzionava veloce VB6 ... mah.

Io sviluppo programmi bellissimi in assembly per 8086, per CPU in real mode, perché ca veloce anche sul mio i386, mentre il tuo vb6 non funziona in windows 3.1.....

Veroo!!
Non ti posto contro dicendoti, ma che scrivi!

Perché non si possono leggere?
Gli addetti ai lavori non hanno problemi a valutare e ponderare quanto scritto!