Newsgroup: it.comp.lang.visual-basic
Titolo: conversione  puaaaaah

Sto facendo la conversione  da vb6 a 
vb10.net
e  puaaaaaahh    siamo proprio lasciati nella
cacca da mamma microsoft.
Non c'e' una linea da non ritoccare e già
ci dicono di non lasciare le istruzioni vb6.istruz
che non saranno piu' supportate.
Sto sudando freddo nononstante i 30 gradi

 che non saranno piu' supportate.
C'è un convertitore di Balena che dicono funzioni meglio, per il resto mi
sa che si fa prima a riprogettare.

 wrote in news:i0aei3$mol$1...@news.eternal-
september.org
:

stai cercando di aggiornare codice di 11 anni (vb6 e' del 99) e ti aspetti 
di poterlo fare senza metterci mano pesantemente?
hmm...
capirei se avessi fatto il passaggio vb6 -> .net 1.0, ma saltando 
direttamente all'ultimo nato di casa ms ricontrollare il codice riga per 
riga mi pare il minimo...
come?
facevi prima a riscriverlo?
eh...
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

"Andrea [Work]" <andrea.isw...@gmail.invalid> ha scritto nel 
messaggio news:7fqim950rniy.y1wo1hn0cli$.dlg@40tude.net...

Funziona benino se il progetto era TUTTO standard.
Ho mandato il file progetto è mi hanno risposto che buona parte
degli OCX terzi non è supportato ( ocx distribuiti nel pacchetto VB6 PRO)
e non hanno intenzione di supportarlo.
Per non parlare del codice........o dei Form che si sballano
BELLA CACCA !!!
passero' l'estate in conversione (al buddismo)  :-)


Caro amico
Il progetto è stato creato nel '94 su vb 3 e portato avanti secondo
i mezzi che mamma Merdosoft ci metteva a disposizione.....
Il passaggio l'avevo fatto già con il primo 
vb.net
 (che in standard
non aveva manco il convertitore)  e sono 2 anni che, mntre portavo avanti il 
progetto
avevo in mente di passarlo.
Ma  trovandomi di fronte a RISCRITTURE TOTALI DEL CODICE
e dei form  ci ripensavo sempre.
Ora con W7 64 bit e il futuro WIN 8  sono praticamente COSTRETTO
a riscrivermi tutte le  50.000 linee di codice  senza il minimo aiuto
Grazie BILLL 

 cacca da mamma microsoft.
Abituatici all'idea. !
Pensi che zio Bill faccia beneficenza ??
Zio bill è come i pusher :  prima ti abitua alla bocca buona, poi una 
volta che sei diventato 'addicted' ti alza il prezzo della merce.
  :-))
E una volta che ci sei, compri sempre da lui.
Diciamolo, anche perchè la 'fetta' di mercato Microsoft è troppo grande 
per essere ignorata, anzi è di gran lunga maggioritaria.
D'altronde nessuno sul mercato fa beneficienza. :-)))
Se uno programma per sfizio e per hobby, Java e il runtime di Java sono 
una ottima alternaziva.
Meglio che il Gnu C/C++ perchè poi ti devi preoccupare delle classi GUI.
Invece Java ha tutto.
E tutto gratis.  :-))

 ha scritto nel messaggio 
news:i0ajnm$icr$1...@nnrp.linuxfan.it...

Non è questione di gratis o a pagamento......
E' questione di supporto agli sviluppatori...........Possibile
che per un progetto quasi-standard  ( a parte gli ocx strani ma sempre 
microsoft
e la grafica ) non siano in grado di produrre un converter adeguato ? 

 cacca da mamma microsoft.
da almeno 5 anni :-)
.m
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com
blog @ 
http://milestone.topics.it
whynot [ at ] topics [ dot ] it


Lo so di essere in ritardo ma.......finora
non c'era l'impellente bisogna di trasferirlo
perch� funzionava bene  sia su Xp che su VISTA.
I primi problemi con Win7   e ora con i PC
col 64bit  .... per non parlare del prossimo W8.

 
Puoi provare a cercare qualche converte 'privato'.
Anni fa esisteva un converter Visual Basic to C . si chiamava BCX.
Da un source Visual Basic ti produceva un source in C. C'erano alcune 
regole da rispettare nel source Visual basic, ma in sostanza funzionava 
benissimo.
Il mio primo impatto col VB .NET fu disastroso.
Per vede 'cosa succedeva, com'era l'impatto' facevo leggere un progetto 
VB6 al VB 2008.
Dapprima un messaggio molto amichevole mi informava che si era reso 
conto che si trattava di Visual basic 6 e cercava di convertirlo 
automaticamente.
Poi, dopo un po' ci rinunciava, perchè gli errori dovevano essere almeno 
trecento. Non mi ricordo se rinuncioava spontaneamente o se ci 
rinunciavo io alla fine.
Comunque vale senzaltro la pena riscrivere il progetto in VB .NET ex novo.
Se è un progetto vecchio, vale senzaltro la pena scoprire classi che 
prima non c'erano e riducono di molto il tempo di codifica.
Ad esempio gli open file dialog,  save file dialog, etc.
in VB6 la 'connessione' tra files, directory, drive, dovevi farla 'a mano'.
Meno male che ora 'sta rottura non esiste più.


In tutte le aziende ove sono stato a lavorare, hanno semplicemente
deciso di mantenere i propri gestionali in VB 6.
Tutto il nuovo software verrà scritto in .NET ( o Java a seconda del
"filone" aziendale).
Ma il vecchio  VB6, rimane VB6 .
Ciao
-- 
http://www.codingace.it

 
Scusami, ma secondo me, come ti ho scritto sopra sbagli approccio.
Se si tratta di un gestionale, fai prima a convincere i clienti che già
lo usano ad usarlo in virtuale, su Xp ad esempio.
Ti smadonneranno dietro, ma almeno, ti va...
-- 
http://www.codingace.it/


Io ho provato con un solo progetto, poi ho lasciato perdere. Forse era 
proprio sfigato, perchè utilizzavo degli shape (circolari) per simulare 
dei led. Quindi mi trovavo nel convertito con dei bei quadretti, che se 
non ricordo male erano imagebox al loro posto, sovrapposti ad alcuni 
shape c'erano davvero degli Imagebox, trasparenti che uso per 
intercettare l'evento click che gli shape non hanno. Lasciamo perdere la 
parte del CommControl che usavo per accendere/spegnere gli shape...
Al momento funzia in VB6 e lì lo lascio, poi lo riscriverò da 0 
utilizzando una bella classe che simuli un led click compreso senza 
seghe mentali.
Non sono Molto vecchio (32 anni) ma di passaggi a "nuovi linguaggi" ne 
ho già fatti altri, e in nessuno ho trovato un converitore che 
funzionasse, la cosa migliore è sempre quello con 2 gambe e 2 braccia e 
possibilmente un po' di cervello.
In più vedo il passaggio da VB6 a 
VB.NET
 un po' come voler Passare da 
C++ a Java. Sarà pur simile come sintassi, ma E' UN ALTRO LINGUAGGIO.
EffeGi.


Facciamo anche 8, da quando è uscito il primo .NET
Sin da allora è stato reso chiaro che la conversione non era
ragionevolmente possibile per progetti un minimo complessi (oltre che
essere concettualmente deleteria, perchè per usarlo "alla VB6" tanto
vale non usarlo proprio); adesso che siamo arrivati alla quinta
versione di 
VB.NET
, pur con tutta la comprensione possibile, che cosa
ci si aspettava?

 e non hanno intenzione di supportarlo.
Bhe in questo caso anche solo pensare che ci possa essere una migrazione
non è possibile.

"Andrea [Work]" <andrea.isw...@gmail.invalid> ha scritto nel 
messaggio news:1ao26cz8ay9hz.15o2jz9adwiu9$.dlg@40tude.net...

no no  scusami.....
Se tu distribuisci un'applicazione che utilizza ( e fa utilizzare)
OCX  di una ditta esterna  che HAI COMPRATO
(mi riferisco ai vari threed ocx  grid ocx etc.)  DEVI
supportarli almeno al primo step VB6 > VB 2003.
Ma il massimo  è vedere che sballa pure i FORM 


Certo � gi� quello che faccio.
Ma non � che posso stare a spiegare a tutti come si fa il virtuale
(non � un gestionale) 

 ha scritto nel messaggio 
news:0a0c1b10-cde3-48bc...@c33g2000yqm.googlegroups.com...


Tant'è che mamma microsoft  ha eliminato pure il tool di conversione
con la 2010.
Il problema sta nel fatto che nel 2003  non era INDISPENSABILE
fare il porting ( anche con VISTA)  ora con il W7 64 bit  e il
prossimo W8  è OBBLIGATORIO 

 Ma il massimo  č vedere che sballa pure i FORM
Dove sta scritto?
Se conosci un po' .NET (e io lo conosco poco) saprai anche tu che tutto č
radicalmente diverso come concetto.
Casomai la colpa č di chi fa l'OCX che non gira sotto Win7, ma se non avevi
una certa assistenza non ti puoi rivalere.
Per il resto non so che OCX usi, ma io non ho avuto problemi per ora con
Win7x64, ne uso anche di non piů supportati da anni.

 
avendo chiaro dall'inizio che progetti complessi non erano convertibili in 
maniera semplice (aka il convertitore non avresti potuto usarlo comunque), 
il fatto che l'abbiano tolto a te non cambia niente. 
fare la conversione solo quando sei costretto imho significa aver voluto 
tirar la corda fino all'ultimo per evitare quello che sapevi gia' di dover 
fare: rivedere manualmente gran parte del codice.
se hai voluto tirar la corda avrai avuto i tuoi motivi, ma dar la colpa a 
ms perche' hai voluto aspettare fino ad ora mi pare un po' forzato...
non era indispensabile farlo, ma se tu l'avessi fatto ai tempi adesso 
saresti gia' a posto.


 
'prossimo' W8 ???  Quando ??
Meno male che il mio fiuto non mi inganna mai e che sono ancora con XP.
(installandolo al posto del Windows 2000 Professional solo nel maggio 
del 2009 !!)

 del 2009 !!)
Quando avevi fatto il passaggio dal pallottoliere a Windows 2000 ?
PaF
PS.
Scherzo :-) Anch'io ho saltato a piè pari Windows Vista.

"Andrea [Work]" <andrea.isw...@gmail.invalid> ha scritto nel 
messaggio news:18t837k03qikn$.1fxnzkopcouha.dlg@40tude.net...

Sta scritto nel sito microsoft che con la vers. 64 bit  di W 7
ci sono tutta una serie di OCX  (anche microsoft)  non piu supportati.
Gli ocx che uso sono quelli distribuiti con la vers. vb6 pro
percio' Distribuiti da MICROSOFT stessa.
In piu' molti form convertiti sballano o perdono i dati di vari controlli
tipo le picture e le image. 

 ha scritto nel messaggio 
news:Xns9DA681F6EBE18sp...@193.43.96.1...

Questo non giustifica  non supportare A PIENO  chi ti ha mollato
varie centinaia di Euro !!!
E poi chi giudica quando un progetto è complesso oppure no ?

 percio' Distribuiti da MICROSOFT stessa.
ok, ma converrai che Vb6 e tutto quello che gli sta intorno non sono 
più supportati da mo', pretendere che un sistema operativo a distanza 
di dieci anni continui a essere retrocompatibile con roba non più 
supportata è un po' troppo.
Che poi il problema sia annoso non lo metto in dubbio, ma è tutto 
tranne che colpa di Ms


 .m
Da quel che ne so io il vb6 non è più supportato da poco piu' di 6 mesi
un anno.
Il problema e che neanche nel 2003 col primo 
vb.net
  non si sono
proprio scomodati al riguardo di tool da loro distribuiti.
Io la prima conversione l' ho tentata subito (nel 2003)  ma ho lasciato 
perdere
per i troppi errori 

 proprio scomodati al riguardo di tool da loro distribuiti.
Non hanno mai detto che avrebbero supportato la conversione.


 
chi decide cosa significa 'a pieno'?
che giustificazione serve a una corporation per decdidere le proprie 
politiche?
la tua?
hmm...
manie di grandezza?
parli (l'hai scritto in altro post) di un progetto iniziato in vb3 nel 
'94: oltre 15 anni di vita senza modifiche tecnologiche significative.
il periodo di supporto l'hai avuto (e lungo, anche) e le varie centinaia 
di euro spese hai avuto il tempo di ammortizzarle.


 "Mauro Servienti [MVP]" <mauroservie...@online.nospam> ha scritto nel
abbi pazienza ....ma la cosa che dici è utopia!
La tecnologia avanza e dove commercialmente può mantiene la
retrocompatibilità con il passato!
Altrove no!
Altrimenti avremmo Fallout3 uguale a Fallout2...e nessuno ci
giocherebbe!
Avremmo telefoni non gsm...umts manco per il cavolo etc etc!
QUINDI
tieniti vb6 e continua con quel sistema di sviluppo!
QUANDO
vorrai fare un porting....ti studi il NUOVO liguaggio (VB.net NON E'
una evoluzione di VB6) e RISCRIVI il programma!
Il medesimo problema non lo hai solo con microsoft...lo hai con tutto
quello che avanza e progredisce.
Ho fatto un corso di photoshop (come allievo) con il mio pc con
CS4...e la scuola aveva il cs3...ho sudato parecchio ( e fatto sudare
il docente) c'è roba in più ...e roba in meno!
La tua miopia (permettimi di dirlo) è stata riposare sugli allori!
Mi spiego:
perchè ora vuoi fare un porting in un linguaggio totalmente nuovo?
Perchè VB.net e non Java o F#?
Se hai un esigenza "impellente"... "te tocca da studià!"
altrimenti...
con calma....
orientati verso un linguaggio e fai l'upgrade delle tue
conoscenze....sono ferme a parecchi aggiornamenti fà!...hai
disabilitato l'update automatico!!!
:-)

 a riscrivermi tutte le  50.000 linee di codice  senza il minimo aiuto
Fosse quello il problema! 50.000 linee di codice sono nulla... noi
abbiamo un software con quasi un milione di righe di codice!!!
Pezzi pezzi lo stiamo portando verso .NET, direttamente in WPF.
Nicola

 Non hanno mai detto che avrebbero supportato la conversione.
E allora perchè fare un tool di conversione inefficente ?
Ti ripeto .....  se offri nel 2000 con il vb6 pro dei tool
acquisiti da microsoft stessa (ocx vari  grid threed etc.)
perchè non approntare nel 2002 /2003 col primo Vb.net
un tool anche per questi OCX ? 

>:-)
Non capisco le tue risposte  ''rancorose''.
Mi rispondi a qualsiasi thread sempre in maniera
non proprio gentile.
A differenza tua  per me la programmazione è un hobby
che mi permette di pagarmi computer e sfizi vari.
(non posso proprio permettermi corsi di upgrade specifici)
Compro il visual basic originale dalla versione 3  e ho speso
una barca di quattrini  chiedevo solo di essere supportato
adeguatamente.
In 
vb.net
 ho già fatto alcuni programmi NUOVI   partendo da zero
per il vecchio riscrivermi 50.000 linee senza un bel po' di aiuto
non mi sembra molto corretto .
L' ESIGENZA IMPELLENTE  non è cosi' impellente ovviamente

 Pezzi pezzi lo stiamo portando verso .NET, direttamente in WPF.
/sarcastic mode on
Tranquillo, arriverai alla fine in tempo per sentirti dire da MS che WPF 
è una tecnologia obsoleta :-P
-- 
news:it-alt.comp.software.openoffice : Il newsgroup dedicato a
OpenOffice.org, la suite open source di applicazioni per ufficio.
Scarica "OpenOffice.org 3: Soluzioni a raccolta", molto più di semplici 
FAQ! 
http://it.openoffice.org/doc/manuali/

 di euro spese hai avuto il tempo di ammortizzarle.
E in effetti il programma è passato dal VB3 al vb4 al vb5 al vb6
tutte comprate e pagate salate.....(senza alcun problema di conversione)
Chiedo troppo un supporto un po' piu' preciso su componenti
della microsoft stesa ?


Appunto , non piu' supportata e senza convertitori adeguati 

 è una tecnologia obsoleta :-P
Io toglierei pure il modo sarcastico.
Ora che ho la mia bella libreria per Windows Form e che sono super
produttivo dovrei buttare tutto nel cesso per fare _nel mio caso_
*esattamente* le stesse cose (software gestionali, mica affascinanti
front-end super graficosi) ?
La mia risposta è prrrrrrrrttttt !
PaF

 Pezzi pezzi lo stiamo portando verso .NET, direttamente in WPF.
Una domanda: che vantaggi state trovando o avete trovato usando WPF
piuttosto che Windows Form ? 
PaF

 ha scritto nel messaggio 
news:1hn9d8fat19q2$.1vm1tncxa1k0$.dlg@40tude.net...

Ohhhh  uno che mi comprende 

 Ohhhh  uno che mi comprende
Fino ad un certo punto.
Se tra 10 anni Windows Form sarà obsoleto e non più supportato me ne farò
una ragione e passerò a WPF o a quello che ci sarà, non rimarrò attaccato a
qualcosa che non è più supportato lamentandoneme.
Oggi però WPF non mi serve, Windows Form è tranquillamnete supportato dal
Framework .NET, fin quando ci sarà questo supporto non mi sentirò obbligato
al cambio.
PaF 

 al cambio.
E io che cosa ho fatto di diverso da quest'ultima frase ?
Nel  2003 avrei potuto scrivere
' Oggi però VB.net non mi serve, Windows XP è tranquillamnete supportato dal
 VB6, fin quando ci sarà questo supporto non mi sentirò obbligato
 al cambio.'

 agli OCX vecchi in W7  o W8
Ok, diciamo che non mi lamenterò se nel 2020 non avrò un convertitore da
Windows Form a WPF.
In realtà mi lamenterò del fatto di non aver fatto abbastanza soldi da
poter evitare di preoccuparmi della conversione :-P
PaF

 
finora hai lamentato un po' di cose diverse:
- che tu vorresti continuare a usare vb6 per un periodo indefinito su 
tutti i so che microsoft ha fatto e fara' mentre ms (cattivona) ha fatto 
una scelta (lecita) che non te lo consente
- che ms non ti fornisce un convertitore funzionante da vb6 a .net 
- che ms ha smesso di supportare i suoi antichi componenti
poche idee ma ben confuse?
intanto comincia la conversione del programma, cosi' ti porti avanti ^^


 ha scritto nel ...
zac
ti rispondo cumulativamente qui
"Programmare per hobby"....non è diverso dal programmare per
professione!
Puoi programmare "a cane" sia per hobby che per professione!
Puoi essere un guru sia che tu campi facendo il programmatore che il
pizzaiolo!...non è quello il punto!
Il punto è diverso...e la guerra di schieramento (alias faziosità)
delle proprie impostazioni mentali! Cosa difficilissima in Italia da
superare!
Tradotto significa :
Se una "cosa" è "buona" io non la uso perchè è per me "cattiva" in
quanto appartenente allo <schieramento opposto alle mie convinzioni>
Questa cosa noi la applichiamo in Italia a tutto dalle auto alla
politica, dalle pietanze alle fidanzate.
Se una azienda ha fatto le sue scelte commerciali, si posono
criticare! ma la critica deve parte da una situazione NON preconcetta!
NELLO SPECIFICO si traduce in:
NESSUNO usa un convertitore da un linguaggio all'altro!
Sanno benissimo che i convertitori hanno EVIDENTI limiti tecnici
derivanti dallo loro vocazione generalista!
Allo stesso modo NESSUNO farebbe un metodo in overload BucoNero(ingoio
as Object) as Object...nascerebbero casini infiniti!
PERO' nascerebbero OGGI!
Oggi che è di moda OOP, che viaggiamo nella vita "interconnessi 24h",
che abbiamo il wireless anche in auto, che usiamo servizi e amenità
varie....oggi dicevo, fare un programma OOP è più "produttivo" che
farlo "alla vecchia maniera"
MA IERI
se ci si ricorda, era normale avere i Variant dappertutto!
ADO ci sparava Variant a raffica....
Il mondo va avanti le esigenze sono cambiate
VB.net e C# (dotnet per intenderci) risponde alle esigenze del mondo
attuale!
OVVIO che capire questo nuovo mondo richiede tempo e fatica e mente
aperta.
Un nuovo approccio!
ECCO PERCHE' mi sembra strano che tu abbia voluto convertire 50.000
righe in OOP!
Il prodotto sarà senza dubbio a cazzo di cane! In qualunque pc con
qualunque programmatore!
Perchè tu in realtà non avrai un errore di sintassi ma un errore
IMMENSO logico!
Convertire un programma procedurale
in un programma orientato agli oggetti NON SI PUO' fare in automatico!
Perchè alcune cose si fanno in maniera diversa, si ottimizzano in
maniera diversa, si scrivono addirittura in maniera diversa!
Guarda che non ce l'ho con te....anzi....ti sto aiutando a capire
perchè un convertitore vb6 
vb.net
 è solo un esercizio di
programmazione esistente solo per vendere qualche copia in più....ed
assolutamente deleterio per la comprensione di dotNet!
Solo questo!
Condivido che ad avere inserito questo "coso" hanno contrbuito a darsi
la zappa sui piedi di quanti sostengono che dotNet fa schifo!
Mentre fa schifo solo la scorciatoia!

>Mentre fa schifo solo la scorciatoia!
E io che ho detto scusa.........
Il 
vb.net
 2010  è un ambiente di sviluppo notevole
e avendo già tanta esperienza passata  neanche tanto
difficile da capire.
IL CONVERTITORE PUAHHHHH


E dici la stessa cosa che dico io ...... Visto che per me non è
una professione ma piu' che altro un Hobby mi lamento
di non aver fatto abbastanza soldi da mettere 1 o 2 cinesi
che mi convertano a mano il tutto 

 intanto comincia la conversione del programma, cosi' ti porti avanti ^^
Giò fatto .... Ma posso dire  PUAAAHHHHHH ?


Mah, vantaggi dal punto di vista grafico più che altro.
Ad esempio, personalizzare una toolbar è molto più semplice rispetto a
Windows Form.
E' però un casino gestire i controlli WPF, cambiano davvero molte cose.
Il succo è sempre lo stesso, farsi librerie di controlli standard da
utilizzare lungo tutto l'applicativo.
Dal lato della programmazione di classi o oggetti senza interfaccia
utente, WPF non entra in gioco e le logiche restano le stesse.
Nicola

 E' però un casino gestire i controlli WPF, cambiano davvero molte cose.
Con l'esperienza che state acquisendo secondo te questa maggiore difficoltà
è compensata dai vantaggi ?
Capisco in applicazioni molto "graphic oriented", ma onestamente ai miei
clienti frega poco che la toolbar abbia un colore piuttosto che un altro.
PaF

 clienti frega poco che la toolbar abbia un colore piuttosto che un altro.
Noi facciamo un applicativo utilizzato in ambito bancario. Là tutti gli
applicativi hanno grafica in stile Win 3.X, grigia e brutta da far schifo.
Sembra una sciocchezza, ma dare grafica decente e semplicità d'uso agli
utenti, fa molto. In una presentazione fa una migliore impressione a chi
deve decidere! ;-)
Nicola

 Spiegami come fai a dire questo !!!
zac
Perchè ti ostini a non capire(o non vuoi...o non puoi) che non sbagli
nell'uso...ma nella partenza!
L'errore e nel volere convertire un programma NON NATO
oop...damblè...di schianto in uno oop!
Se fosse possibile andremmo tutti a casa!
Invece grazie a Dio no! Il risultato fa schifo!
Ma tu ti ostini a convertire...ok!
Però poi ti incazzi che una DLL di qualche anno fa NON è compatibile
con il nuovo!
Ndò sta scritto che deve essere compatibile?
DotNet ha tagliato il "vecchio mondo" anche in buona parte proprio per
il noto dll-hell! ...e ora tu vorresti che Microsoft ci facesse
ritornare in quel fantastico mondo di cacca che se cerchi i vecchi
post (di qualche anno fa)in questo NG ne trovi esempi mirabili
(ti risparmio la ricerca
http://groups.google.it/group/it.comp.lang.visual-basic/search?hl=it&group=it.comp.lang.visual-basic&q=dll+hell
)
IO non ci voglio tornare in quel mondo!
Mi riscrivo l'interfaccia in WPF , la svincolo dalla mia
applicazione...la installo con un copia ed incolla!
Abbi pazienza amico mio....ora si rifiata!...prima era un rincorrere
continuo con gli uTonti che facevano di tutto e di più!
Io in questo mondo nuovo mi ci sto adattando...e sono sempre critico
in chi cerca scorciatoie anche illegali (craccare nun se pò).
Se è un hobby non è un buon motivo per rubare!
Però è un hobby per tua ammissione che ti fa guadagnare...e allora che
è?
Un lavoro "oscuro"?
Saluti!
p.s.
Esistevano anche ai tempi del VStudio le versioni student.
Non ci sono scuse!
p.p.s.
Non ti venga in mente di rispondere con la solita solfa "chi non ha un
programma crakkato?"....è già stata usata come risposta da altri
lamer!
;o)

>;o)
Guarda che mettere la faccina  non ti rende piu' simpatico :-( 

 Guarda che mettere la faccina  non ti rende piu' simpatico :-(
Io non ho trovato alcun spunto polemico nei tuoi confronti da parte di
Wodka, anzi sta cercando di spiegarti i motivi per cui ciò che vuoi non è
possibile, anche volendo.
Te lo dico in modo diverso:
1) se l'OCX SSBUTTON ha la proprietà PincoPallo as Integer specifica di
quel controllo, non standard e non presente nei controlli .Net, mi spieghi
come diavolo fa un convertitore a convertirtelo ? Come fa a capire che
quello è un Button e magari non un Tab ? Se non è standard (cioè
compatibile .NET o meglio ancora derivato direttamente da controlli Win32)
non è standard. Punto
2) Ci sono modifiche sostanziali tra l'architettura VB6 e quella .Net, la
prima cosa che mi viene in mente sono gli array di controlli e la gestione
degli eventi, cosa che rende i due mondi *totalmente* diversi. Parlare di
conversione è improprio, bisognerebbe parlare di "porting".
Con il punto 2 non dico che la cosa mi piaccia, anch'io ho un mega
gestionale che continuo a sviluppare in VB6 perché al momento il cliente
non pensa al porting, so bene che quando arriverà il momento dovrò
riscrivere tutta l'interfaccia e parte del codice (almeno quello più
vecchio, non incapsulato in classi con codice compatibile .Net), la cosa
non mi entusiasma ma lo capisco, visto che conoscendo bene i due mondi so
che un convertitore automatico farebbe solo danni.
PaF

 PaF
Auguri  .....
Comunque ti ripeto...... io ho solo  fatto una considerazione su un tool
di MS   che fa decisamente pena  e non voglio denigrare nessuno
e tantomeno uno strumento come il 
vb.net
 (visto che lo uso da anni) 


Forse perchè il Turbo Pascal, glorioso antenato del Delphi era già OOP?
Se programmi in Delphi2, usi una sintassi che in Delphi 7, non cambia.
Non so con le Ultime, ma con Delphi 7 potevi decidere se compilare con 
il framework .net o continuare con il vecchio standard. Proprio perchè è 
già tutto OOP dai secoli dei secoli.

 ora non avrebbe tutti questi problemi di conversione.
Ma probabilmente non li avresti neppure se volessi compilarlo con 
Lazarus, che ï¿œ free software e pure cross-platform :-)
L'object pascal ï¿œ nato bene, mentre VB era giï¿œ alla nascita un brutto 
compromesso foriero di problemi.
-- 
news:it-alt.comp.software.openoffice : Il newsgroup dedicato a
OpenOffice.org, la suite open source di applicazioni per ufficio.
Scarica "OpenOffice.org 3: Soluzioni a raccolta", molto piï¿œ di semplici 
FAQ! 
http://it.openoffice.org/doc/manuali/

 e tantomeno uno strumento come il 
vb.net
 (visto che lo uso da anni)
Nessuno nega che il tool di conversione faccia schifo, ma bisogna capirne i
motivi.
PaF

 compromesso foriero di problemi
amen :-)
.m
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com
blog @ 
http://milestone.topics.it
whynot [ at ] topics [ dot ] it

 e tantomeno uno strumento come il 
vb.net
 (visto che lo uso da anni)
è un dialogo tra sordi!
Ti ostini a non voler capire!
ti faccio un esempio
Io ho la multipla...il freno a mano è a sinistra!
se facessi come te farei un casino perchè l'hanno messo a sinistra...e
direi che la multipla fa schifo...fa cagare...che ci voleva a metterlo
a destra...rincoglioniti gli ingegneri ...bla bla bla
MA la multipla per le famiglie da 4 persone in su è una grande
macchina ed è fatta bene...e se il freno è a sinistra
chissenefrega...c'ho caricato moglie bambine passeggini e valige e ho
fatto 400 chilometri al fresco belli larghi con 20 euro di metano...
chi cazzo se ne frega se il freno a mano è a sinistra!!!
Il punto è questo: ci sono sempre scontenti per un prodotto....va
capito se sono scontenti a ragion veduta o solo rompiballe!
Se io volessi la multipla per fare rally e derapare alla curve...il
freno a mano è nel posto sbagliato...il motore è sbagliato...etc etc
Lo sbagliato in realtà sono io che uso impropriamente un prodotto...il
fatto che abbia le ruote e sia un auto NON la trasforma in una
macchina da rally!
Se ci vuoi fare un rally...accetti le limitazioni...o ti metti ad
upgradare la multipla spendendo un sacco...molto più che comprare una
toyota ed assettarla!
La via non è comunque rubare una toyota!
La realtà è che in Italia ci sono 60milioni di CT...e te pareva che
non trovassimo in questi 60 milioni anche chi usa il tool di
conversione per non stare 1 ora a riscrivere BENE una form? E si
incazza pure della sua pigrizia...ma non con se stesso...con
microsoft???
In toscana da buoni scoglionati che siamo si dice "Facile fare i bui
con il culo degli altri!"
Evabbe.....
Ahloa....
p.s.
nessuna faccina?
chissenefrega io ce la metto!
:)
ti incazzi pure per questa?
e io ce la rimetto!
:o)
LOL
p.p.s.
:oD
rotfl!!!!

 wrote:
APPUNTO TECNICO
Mauro Serventi qui può intervenire nel flame e darti MOLTE  più info
tecniche di me (mi scuso con lui se sono improprio nei termini)
Un programma VB6 spesso è farcito di form con controlli vari.
Se guardiamo il codice vediamo che c'è commistione tra View e
Business.
Non è un male:con vb6 avevamo solo una sorta di OOP con le interfacce
e il massimo che si poteva fare era un po di dll e routine richiamate.
Se anche il convenrtitore ti convertisse avresti comunque uno
spaghetti code con strato view e starto business mischiato!
Il programma funzionerebbe comunque...e probabilmente a te te ne
impiprebbe alquanto e lo continueresti a rivogare al cliente!
MA
avresti buttato via tutto il dotNet...
Fai meno fatica e sei più produttivo se continui ad usare vb6 (e
produrresti anche un eseguibile ALQUANTO più veloce).
Non è un male CONTINUARE ad usare vb6 se il momento e la situazione
contingente lo richiede!
Se viceversa usi dotnet
troveresti molto più produttivo
separare l'interfaccia dalle regole business...e dalla base dati!
Il cliente vuole una form diversa? cambio solo quella
Il cliente vuole una gestione delle commesse con lo scorporo dei
guadagni tra soci? cambio la logica business
Il cliente passa da SQLserver ad Oracle? cambio lo strato DB
scrivendo(derivando) un DAL specifico!
Costo risorse umane?
Non elevato se lo fai per hobby....basta provare...una volta fatto la
prima volta uno dice (come me) "cazzo che coglione a non averlo fatto
prima!"
OVVIO
se ,,,ripeto SE...hai la necessita di una logica distribuita e un
programma che richiede personalizzazioni successive.
Se è un monoutente...monolitico..con pochissimi cambiamenti..con una
base dati piccola....e pc dei clienti datati....VB6+access tutta la
vita!
Questa è la mia esperienza!
ri-Ahloa!
Con la faccina!
:oD

 un tool anche per questi OCX ?
perchè fare un tool che comprenda tutte le casistiche è impossibile e 
perchè fare un tool per la conversione da Vb6 ad altro, altro che è 
radicalmente diverso da Vb6 ha un costo spaventoso ed è ovvio che il 
gioco non vale la candela.
Infine si sono probabilmente resi conto che il tool avrebbe prodotto 
più danni che altro perchè avrebbe portato i programmatori Vb6 ad usare 
Vb.Net allo stesso modo, che è il male assoluto (insieme a tante altre 
cose :-P)


> oD
.m


 perchè più veloce? (considera che non so nulla di Vb6)
Ci puoi scommettere :-). Se non altro perché ha una mezza dozzina
di layer software in meno.
[Questa era la risposta in breve. Segue altro post lungo e
probabilmente noioso per i più :-)]
Bye, G. 

 perchè più veloce? (considera che non so nulla di Vb6)
Perché ha una mezza dozzina di layer software in meno, se non altro [1].
[altro in merito, più specificatamente relativo al VB, qui:
http://groups.google.it/group/it.comp.lang.visual-basic/msg/07edd6628ee59daa
 ma sono concetti che più o meno ripeto sotto.]
Diciamo che è un po' la differenza che c'era tra il VB e il Gwbasic
in ambiente DOS: il secondo s'interfacciava all'hardware tramite le
sole routine del BIOS e del DOS e già questo, per l'hardware dell'epoca,
era una limitazione non da poco in termini di prestazioni, tanto che
i programmi che avevano bisogno di girare con la massima efficienza
erano scritti direttamente in linguaggio macchina o in assembler.
Quando arrivò il VB, che utilizzava le API di Windows, era considerato
lento e pesante, con la sua VM e il runtime da centinaia di KB.
Ma ovviamente il layer software di astrazione dall'hardware dava
dei benefici notevoli: permetteva di usare lo stesso programma
su un PC qualunque, con qualunque scheda grafica, risoluzione,
numero di colori, disco, rete, font eccetera.
Al prezzo, ovviamente, di una lentezza a volte eccessiva, con
l'HW dell'epoca. E ora la storia si ripete, con .NET che è considerato
pesante, il suo runtime (il framework) di "dozzinaia e dozzinaia" (cit.)
di MB, il suo layer di astrazione che isola da blablablabla... ma
la domanda è: serviva veramente ?
Quando la MS iniziò a parlare di .NET, lo definì fra l'altro VB7: fu
una pessima mossa, che lasciava intendere che fosse un'evoluzione
del 6. Ma, per i primi tempi, fu una mossa positiva, perché quello
che i programatori VB desideravano, era proprio un VB6 con un
po' di difetti in meno, e un po' di caratteristiche in più, niente di che.
Da qualche parte devo aver postato anche un elenco dei desiderata
dell'epoca:
http://groups.google.it/group/it.comp.lang.visual-basic/msg/b62f665b25ac6d1f
http://groups.google.it/groups?q=vb7+wish+list
Però, il VB alla sua uscita aveva la capacità unica, per l'epoca,
di lasciarti programmare in modo visuale, semplice ed efficace.
Tre caratteristiche che non esistevano, insieme, in nessun altro
prodotto, Microsoft o della concorrenza che fosse.
Avevo *provato* a fare qualcosa sotto Windows in C, e posso
garantire che era una cosa da impazzire, nonostante con gli
occhi di oggi si trattasse *solo* di un mucchio di chiamate API.
Ma per aprire una finestra, l'equivalente (ma con molte meno
capacità) di un Form, c'era mezza pagina di codice, ed era solo
per disegnare la finestra a video, quasi senza funzionalità.
Ricordo quando ebbi in mano il VB 1.0 per la prima volta...
immaginavo che si trattasse, come avevo già visto in altri prodotti,
di un'integrazione di queste API nel linguaggio Basic; non avrei
mai sperato in quello che vidi e che mi entusiasmò: la possibilità
di disegnare l'intera interfaccia con pochi colpi di mouse.
E quell'interfaccia non era finta, *FUNZIONAVA* ! :-)
Erano cose quasi inaudite, anche se c'era qualche applicazione,
almeno sotto Mac, che ci si avvicinava... da lontano.
Era qualcosa che prima praticamente non esisteva, e che
permetteva cose prima impossibili, almeno in Basic.
Era la prova che la famosa equazione del Wirth,
"Algorithms + Data Structures = Programs", non era più vera
in assoluto, perché mancava del tutto del concetto di interfaccia
utente.
La stessa cosa non si è potuta dire al tempo dell'uscita del .NET.
Per anni ho chiesto, da vecchio programmatore VB, che cosa
si potesse fare con .NET che non si potesse già fare con VB;
nessuno mi ha mai risposto.
Come ho già detto in qualche mezza dozzina di post, dal 2003
ad oggi, dopo essere passato dal Basic dello ZX-80 al VB*, non
è che mi spaventi il cambiamento: è che non ne vedo ancora
la necessità.
Questo fino a qualche tempo fa; adesso comincio a vederla,
ma non è una necessità nel senso che .NET mi permette di fare
cose che non potrei altrimenti fare, cioè per una mia scelta;
è una necessità imposta dalla MS, nel senso che VB non è più
supportato, che non si è più evoluto, che alcune cose potrebbero
smettere di funzionare nelle prossime versioni del S.O, che
l'interfaccia ha dei limiti anche solo estetici... non funzionali.
Ma poi vai a scontrarti con le differenze, fra il Vb e il .NET, che
francamente fanno un tantino riflettere.
C'è una storia che non posso raccontare completamente, su
un lavoro che stavo facendo in VB, e che visto che era ancora
all'inizio, ho pensato di riscrivere in .NET.
Alcune delle caratteristiche più importanti del progetto si basavano
pesantemente su funzionalità del VB che nelle prime versioni
di .NET non esistevano più, o erano pesantemente impraticabili,
o non documentate o tutte e tre le cose.
Per fare qualche esempio, l'autoredraw, le matrici di controlli,
certe chiamate API, gli UDT con string fixed length... tutte cose
per le quali nelle versioni successive sono stati creati dei workaround,
o sono state documentate, sostituite con chiamate al framework,
eccetera. Ma io nel frattempo,ho dovuto finire il programma in VB,
almeno per poterlo presentare ai possibili acquirenti; e adesso
mi tocca riscriverlo da capo in .NET, senza garanzia, nel processo,
di non toppare qualcosa e inserire qualche bug strano, di renderlo
molto più pesante, o tutte e due le cose insieme...
[1] A proposito di layer:
http://blogs.msdn.com/b/philipsu/archive/2006/06/14/631438.aspx
interessante, anche se non c'entra più di tanto col discorso attuale.
Bye, G. 

Il Fri, 2 Jul 2010 00:51:45 +0200, Paperino ha scritto:
[cut]
Uno dei migliori post letti negli ultimi tempi.
Aggiungo alcune note personali.
1) Le prime versioi del framework, oltre alle mancanze che hai elencato,
non avevano il supporto per funzionalità ormai scontate anche nel 2002,
come la gestione della porta seriale, se non erro aggiunta nel framework
2.0
2) Quando mi avvicinai a .Net mi spaventò la pesantezza, per l'hardware
dell'epoca, di applicazioni anche banali: avevo fatto un test con un
programma scritto in C che apriva una finestra, confrontato con lo stesso
programma scritto in 
vb.net
 che apriva un form. Il primo era immediato al
click sull'exe, il secondo macinava per secondi. Il primo occupava pochi
kb, il secondo almeno 10 MB. Fu il motivo della mia lenta transizione a
.net, peraltro non ancora conclusa, visto che ho ancora qualche applicativo
in VB6 che al momento rimarrà ancorato a quell'ambiente di sviluppo (fino a
quando il cliente non sarà d'accordo per la riscrittura).
Ora con macchine da supermercato dual core e 4GB questi problemi si sentono
meno ed i vantaggi in termini di produttività, almeno per me, non mi fanno
più rimpiangere VB6, ma la sensazione che forse all'inizio le cose si
potevano fare meglio, in termini prestazionali, mi è rimasta.
PaF

 deve decidere! ;-)
Questo è vero, tant'è che in in mio applicativo ho curato l'aspetto
grafico, pur con Windows Form, in modo maniacale. Icone carine, tastini
simpatici etc.
PaF

 potevano fare meglio, in termini prestazionali, mi è rimasta.
Da semiprofano, a me più che le prestazioni la cosa che convince meno di 
.NET è il fatto che ovviamente MS lo tiene saldamente ancorato solo a 
Windows.
Tutto questo carrozzone avrebbe molto più senso se fossero supportate 
anche altre piattaforme, altrimenti cosa mi cambia veramente rispetto a 
un compilare nativo con buone librerie di supporto?
Altre implementazioni sono demandate a produttori terzi, con risultati 
tutti da verificare.
-- 
news:it-alt.comp.software.openoffice : Il newsgroup dedicato a
OpenOffice.org, la suite open source di applicazioni per ufficio.
Scarica "OpenOffice.org 3: Soluzioni a raccolta", molto più di semplici 
FAQ! 
http://it.openoffice.org/doc/manuali/

 tutti da verificare.
Conoscendo la storia di Microsoft questa è una scelta inevitabile. 
Già mi aveva incuriosito l'aver formalizzato in modo pubblico le specifiche
del CLI (ECMA)
http://msdn.microsoft.com/en-us/netframework/aa569283.aspx
Per il resto se ti interessa il cross-platform c'è sempre il progetto mono,
che si può usare con soddisfazione a patto di conoscerne i limiti. 
PaF

 potevano fare meglio, in termini prestazionali, mi � rimasta.
Prestazioni a parte, fatemi dire una cosa: se dopo sette/otto anni
dall'uscita del .NET e dall'abbandono del VB c'� ancora chi rimpiange
il VB, c'� continuamente gente che chiede se conviene davvero
impararlo o se � meglio usare VB classico, se dopo sei versioni
del nuovo linguaggio ci sono ancora programmatori (li chiamiamo
miopi, sono d'accordo, ma ci sono) che iniziano nuovi lavori in VB
snobbando il .NET, se dopo questi anni .NET non ha avuto insomma
il successo che forse la MS si aspettava, se, significativamente,
stiamo qui a discuterne, beh... qualche problema evidentemente c'�.
E quando leggo cose del genere:
http://visualstudiomagazine.com/articles/2010/07/01/fated-to-succeed.aspx
beh, mi sembra che l'autoincensamento che ci vedo sia un tot esagerato.
Bye, G. 

 E AFAIK, non funziona ancora sulle versioni a 64 bit.
Non lo so sapevo ... mi tengo stretta la mia macchina virtuale con XP a 32
bit :-)
PaF

 utente.
Sull' Amiga (commodore) c'era già un un programma simil basic
a concetto VISUALE ..... potevi già allora  piazzate textbox
button vscroll etc..  e programmarli con le funzioni relative click
etc. in BASIC.......
Ma l'amiga era 10 anni AVANTI .... era già multitaskin e multithrading
e il PLUG & PLAY reale è stato inventato li.
Ci avevo già pasticciato sul mio A 4000  ( ce' l'ho ancora)
:-) 

 e il PLUG & PLAY reale è stato inventato li.
Eh, sì. Peccato che la Commodore abbia fatto la fine che ha fatto.
Bye, G. 

 Interessante. Hai qualche riferimento, tpo il nome del programma ?
Forse CanDO o Amiga Vision.


tutti da verificare.
Mah, io per le applicazioni multipiattaforma preferisco Python, adesso ha il
supporto anche per l'ambiente grafico QT che  Nokia ha reso disponibili in LGPL.
Python � poco tipizzato e consente di fare le cose in poco tempo, evitando di
dover litigare con oggetti come i Qstring o le Qpixmap in C++ ma di utilizzare
lo stesso le QT, anche se effettivamente non ha ancora i vantaggi dell' IDE di
VB6.
Non ha prestazioni eccelse dal momento che � interpretato, ma � un alternativa
da prendere in considerazione per fare le cose rapidamente.
http://wiki.python.org/moin/PyQt
http://www.pyside.org/
http://qt.nokia.com/
--
ciao
  Stefano

 Conoscendo la storia di Microsoft questa è una scelta inevitabile.
Per rispondere ad entrambi, consiglio la lettura di un po' di roba
di Joel Spolsky. In particolare direi che siano interessanti questi
due articoli:
"How Microsoft Lost the API War"
dove una parte succosa parla proprio di VB6 e .NET:
http://www.joelonsoftware.com/articles/APIWar.html
"Things You Should Never Do, Part I"
sul riscrivere le applicazioni da capo:
http://www.joelonsoftware.com/articles/fog0000000069.html
e, visto l'argomento del NG, aggiungerei anche questo, che è sulle
astrazioni nel software:
"The Law of Leaky Abstractions"
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
Bye, G. 


AMIGA VISION
Micidiale e fenomenale per allora......1990  penso
Niente del genere su MAC  o  pc.
Ma l'Amiga  era il meglio della piazza allora :-)