Questo sito utilizza cookies, anche di terze parti, per mostrare pubblicità e servizi in linea con il tuo account. Leggi l'informativa sui cookies.
Username: Password: oppure
Visual Basic 6 - Visual Basic 6 e Windows 7/10
Forum - Visual Basic 6 - Visual Basic 6 e Windows 7/10 - Pagina 3

Pagine: [ 1 2 3 4 5 ] Precedente | Prossimo
Avatar
Carlo (Member)
Pro


Messaggi: 191
Iscritto: 29/01/2018

Segnala al moderatore
Postato alle 22:27
Martedì, 06/02/2018
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


In programmazione tutto è permesso
PM Quote
Avatar
nessuno (Normal User)
Guru^2


Messaggi: 5620
Iscritto: 03/01/2010

Segnala al moderatore
Postato alle 10:04
Mercoledì, 07/02/2018
Testo quotato

Postato originariamente da Carlo:

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



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

Testo quotato

Per ora sembra che solo Carlos condivide con me la gioia di usare questo stupendo linguaggio



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.

Testo quotato

gli altri lo fanno solo perchè costretti a mantenere vecchi obsoleti applicativi e ne prendo atto.



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.

Testo quotato

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".



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 ...

Testo quotato

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



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 ...

Testo quotato

Tornado al codice e all'efficienza nel ciclo di for



Testo quotato

un errore poichè è inutile aggiornare la label



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 ... :-)

Ultima modifica effettuata da nessuno il 07/02/2018 alle 10:10


Ricorda che nessuno è obbligato a risponderti e che nessuno è perfetto ...
PM Quote
Avatar
ingeinfo (Normal User)
Newbie


Messaggi: 1
Iscritto: 14/05/2018

Segnala al moderatore
Postato alle 23:52
Lunedì, 14/05/2018
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...

Ultima modifica effettuata da ingeinfo il 15/05/2018 alle 0:17
PM Quote
Avatar
Carlo (Member)
Pro


Messaggi: 191
Iscritto: 29/01/2018

Segnala al moderatore
Postato alle 1:06
Martedì, 15/05/2018
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.


In programmazione tutto è permesso
PM Quote
Avatar
nessuno (Normal User)
Guru^2


Messaggi: 5620
Iscritto: 03/01/2010

Segnala al moderatore
Postato alle 9:38
Martedì, 15/05/2018
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.

Ultima modifica effettuata da nessuno il 15/05/2018 alle 10:56


Ricorda che nessuno è obbligato a risponderti e che nessuno è perfetto ...
PM Quote
Avatar
TheDarkJuster (Member)
Guru^2


Messaggi: 1507
Iscritto: 27/09/2013

Segnala al moderatore
Postato alle 10:57
Martedì, 15/05/2018
Testo quotato

Postato originariamente da Carlo:
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.



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.....

PM Quote
Avatar
Carlo (Member)
Pro


Messaggi: 191
Iscritto: 29/01/2018

Segnala al moderatore
Postato alle 11:11
Martedì, 15/05/2018
Testo quotato

Postato originariamente da nessuno:
Ho un computer di 15 anni fa in cui faccio girare programmi in GWBASIC e QUICKBASIC e vanno velocissimi ...


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

Postato originariamente da nessuno:
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 ...


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


In programmazione tutto è permesso
PM Quote
Avatar
nessuno (Normal User)
Guru^2


Messaggi: 5620
Iscritto: 03/01/2010

Segnala al moderatore
Postato alle 12:24
Martedì, 15/05/2018
Testo quotato

Postato originariamente da Carlo:

Testo quotato

Postato originariamente da nessuno:
Ho un computer di 15 anni fa in cui faccio girare programmi in GWBASIC e QUICKBASIC e vanno velocissimi ...


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



E invece dovresti, ma vedo che non hai afferrato ...

Testo quotato

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



Se non capisci perché non si possono leggere, è ovvio che non sei un addetto ai lavori.
Nulla di male, ma le argomentazioni banali come "è più veloce e gira con un pc di 10 anni fa", senza una argomentazione del contesto tecnologico e di quello che è avvenuto negli ultimi 20 anni nel mondo dell'informatica, sono veramente assurde.

E questo vale, a maggior ragione per ingeinfo, suppongo ingegnere informatico, utente appena (e stranamente) iscritto proprio per fornire un commento assurdo, se crediamo veramente che sia un ingegnere informatico.

Ultima modifica effettuata da nessuno il 15/05/2018 alle 12:26


Ricorda che nessuno è obbligato a risponderti e che nessuno è perfetto ...
PM Quote
Pagine: [ 1 2 3 4 5 ] Precedente | Prossimo