Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Il modo migliore di programmare / convertire

Nell'azienda in cui lavoro, stiamo cercando di convertire i vecchi programmi
fatti in VB3 a VB6.
Dopo una lotta nel vero senso della parola, sono riuscito a far capire
l'importanza di rimanere aggiornati, se non altro per poter utilizzare le
nuove e future tecnologie disponibili, che ogni giorno vedo che si rendono
necessarie, almeno nella mia realtà; per ottenere più stabilità, ecc. (Si
continuava a fare nuovi programmi con vb3, pretendendo di aggiornare tutto
il resto, windows, hardware, internet e di integrarli tra loro)
Non sono solo io che seguo il lavoro ma, e soprattutto, l'autore dei vecchi
programmi.
Lo stesso, ha appena 'sfornato' la conversione di un vecchio programma e,
per la gioia del mio capo (!), ma la mia disperazione, ho notato che sono
stati inserite i più svariato ocx di produttori noti.
Personalmente non sono molto d'accordo con questo e, per come la vedo io,
preferisco rimanere sullo standard ed utilizzare ocx esterni solo quando
STRETTAMENTE E REALMENTE necessari.
Penso che la possibilità di migrare al futuro progetto .net o altro sia
molto più facile, se si utilizzano componenti inclusi in vb6.
Che senso ha sprecare soldi e tempo per acquistare una box che mi scrive i
numeri da destra a sinistra mantenendomi fissa la posizione della virgola in
quel punto, oppure utilizzare un pulsante che mantenendolo premuto continua
ad attivarsi per navigare tra i record (es: posso sostituirlo con lo spider
o qualche altro sistema) ?
La mia 'paura' è di rimanere legato a troppi produttori e quindi di
adattarmi alla velocità di crescita di quello più lento, se non addirittura
dover rimanere 'fermo' perché quella particolare cosa non viene pìù prodotta
o è incompatibile.
Non ho molta esperienza in fatto di aggiornamenti a nuove versioni di
programmi, ma chiedo a voi, che cosa è meglio tenere conto in fase di
riscrittura di un programma considerando la possibilità di crescita e
upgrade dello stesso, la possibilità di essere più standardizzati possibile
mantenendo una buona usabilità (ossia funzioni utili all'utilizzatore).
..oppure: usa tutto quello che esiste di 'carino', tanto non è possibile
conoscere il futuro ed al limite si riscrive tutto un'altra volta ?
Grazie a chi vorrà partecipare con una opinione.
Luca.
 
-- 
Posted from [212.131.31.148] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

STRETTAMENTE E REALMENTE necessari.
[SNIP]
Sono d'accordo al 100%
ti racconto l'esperienza della mia società:
Ad un certo punto dello sviluppo dei nostri vecchi programmi in VB3 decidemmo di
"potenziare" un po' l'interfaccia utente adottando il pacchetto degli allora
VBTOOLS (collezione di VBX dei tipi piu' disparati), anche dietro imbeccata di
un cliente che all'epoca li utilizzava gia' per il suo sviluppo interno.
Quando uscì VB4 non guardammo neanche la versione a 16 bit ma ci dedicammo
subito a quella a 32 bit per poter abbandonare la comunicazione DDE che usavamo
per i nostri moduli in favore di COM (allora "OLE Servers"); ovviamente al
momento della conversione Common Dialog & C. furono rimpiazzati dai
corrispondenti OCX ma per i VBTools non potemmo far nulla, visto che solo molti
mesi dopo uscì la versione a 32 bit, che esiste tuttora ("OleTools").
Per fortuna i pochi controlli della serie che avevamo usato riuscimmo a
rimpiazzarli con i nuovi Common Controls di VB (il ListView su tutti) mantenendo
un interfaccia tutto sommato coerente con la vecchia ma dovemmo riscrivere non
poco codice per riadattare tutte le form dei nostri progetti (al momento, tra
tutti, sono più di 500 ma all'epoca non saranno state meno di 200!)
Da quel momento, però, abbiamo cercato di rimanere "sullo standard" anche noi,
tanto piu' che VB offriva e offre un set di controlli più completo e soprattutto
la possibilita' di crearsi in proprio nuovi controlli per le esigenze
particolari; fatto sta che tutti i successivi passaggi di versione, a livello di
GUI, sono sempre stati indolori e sono molto fiducioso anche per l'imminente
VB.NET
 (sempre per quanto riguarda l'interfaccia grafica, of course; sul codice
penso che qualche mal di pancia tocchi a tutti)
Bisogna già stare dietro alle bizze del proprio codice, di mamma Microsoft, dei
DBMS, dei server e dei browser Web... risparmiati almeno le finestre!
Puoi citarmi come testimone ;-)
Ciao
--
Luca Dormio
luca....@tin.it

 ha scritto





Luca.
--
personalmente apprezzo molto il codice, e uso i controlli (anche le dll),
come dici tu, solo se "STRETTAMENTE E REALMENTE necessari". ce ne sono,
peraltro.
se trovo un sito come vbnet che spiega passo passo come gestire le cose di
vb _via codice_, me lo tengo stretto.
1. in caso di casini sul codice ci rimetti le mani, sui controlli devi
pregare che il produttore sia disponibile e non sia andato a fare il
pescatore di ostriche alle maldive.
2. studiarsi il codice (di gente tosta) apre parecchio la testa, usare i
controlli semplifica la vita ma lascia tonti :)
detto questo, per motivi e tecnici e borsistici tutto cambia e tutto
cambiera', quindi bisogna pregare comunque. se portano .net su linux, hai
voglia a riciclare le chiamate all'api...
ciao, a.

voglia a riciclare le chiamate all'api...
"usa la compilazione condizionale, jedi, usa la compilazione condizionale..."
Il Delphi, ad esempio, ti insegna a pensare platform-independent: la struttura
dei programmi Delphi prevede una serie di moduli (Unit) contenenti il codice
vero e proprio, inclusi ("usati") dal programma principale, che non fa altro che
richiamarne metodi (sì, è una struttura rigida e a tratti tediosa. Il Modula è
pure peggio. Ma serve al suo scopo). Il programma centrale quindi raramente
dovrai modificarlo, semmai le Unit potrebbero aver bisogno di un pesante
riadattamento, ma solo se fanno direttamente uso intensivo di funzioni del
sistema operativo. In quei casi basta un $IFDEF WIN32 ... $ELSE ... $ENDIF
attorno al codice "problematico", e nell'$ELSE poi il responsabile del porting
metterà il codice per la nuova piattaforma supportata. Così si dovrebbe fare
anche in VB. Attorno a qualsiasi cosa faccia direttamente riferimento a funzioni
specifiche del sistema operativo, un bel #If Win32 Then... #End If. Non si sa
mai, qualche vecchio appassionato di Basic potrebbe, mosso a tenerezza (e
soprattutto incazzatissimo per la carenza di compilatori decenti e soprattutto
di implementazioni soddisfacenti), farsi il suo compilatore multi-piattaforma e
donarlo a noi poveri mortali. Che figura ci faremmo?
-- 
Posted from 
smtp.technorail.com
 [195.103.144.19] (may be forged) 


 "usa la compilazione condizionale, jedi, usa la compilazione
condizionale..."
grazie del jedi, anche se mi sento piu' yoda :)
ifdef e' giusto, e in genere consiglierei la tua impostazione a uno che
comincia, ma il problema e' che appena tenti qualcosa di complesso -- se non
e' complesso si fa prima a riscrivere di pacca, su qualunque ambiente -- hai
bisogno dell'api. e finche' i simpaticoni di redmond non mettono una
tux32.dll ...
quanto al compilatore multipiattaforma, mi sembrava di avere visto qualcosa,
anche se non evolutissimo. forse l'avevi segnalato proprio tu ? seno' te lo
cerco.
ciao, a.

 cerco.
io conoscevo un sito di compilatori Basic gratuiti o addirittura Open, mi pare
segnalato proprio qui sul NG. Uno era multi-piattaforma, XBasic mi pare si
chiamasse, ma è francamente lontano dall'essere proponibile seriamente come
strumento di sviluppo. E' comunque pesantemente diverso da Visual Basic come
linguaggio


 ha scritto nel messaggio
news:033a01c0b6ff$113eadd0$419c953e@aldebaran...

[...]

 $ENDIF
Il problema e' che tutto cio' rende il codice difficile da leggere e da
mantenere.
Ciao.