[VB6] Migrazione a [VB.NET] DataGrids !!!

[matt_vb6]

Ciao a tutti ,
ho iniziato a migrare un progetto di 600 forms da circa 3 anni (!!!) .
Dopo aver speso un mare di tempo a migliorare il codice , togliere variant , Any ,a DAO ad ADO ecc ecc mi succede ancora questo :

1) che griglie si possono usare in VB6 che poi possano essere convertite in VB.net senza rimettere tutte le colonne e tutti i campi ? (allego foto prima e dopo la migrazione) .
Notare che : perde la definizione dei campi , perde l'altezza riga , l'altezza riga Head...
Tenete conto che ho 600 forms ... non le voglio ricambiare tutte
Il tipo di griglia è TrueDbGrid 8.0

2) Crystal Reports , i file DSR integrati nel progetto non sono convertibili ... ma era l'unica soluzione , anzi E' l'unica soluzione possibile se volete interagire run-time con le immagini (resize , location ecc .. anzi location è stato risolto ma size non tanto..)

Grazie a tutti per le eventuali dritte .


p.s. un piccolo sfogo ...
dopo la migrazione del progetto (già in corso dal 2008 e durerà altri anni) sarà amaro accorgersi che funzionava meglio in VB6 ...

Se Microsoft decide di abbandonare ActiveX e quant'altro perchè ci devono rimettere tutte le software house del pianeta ? Dateci uno strumento di conversione efficace e non obbligateci a spendere tempo , risorse e soldi per rimanere vostri clienti ... cosa che ad oggi farei davvero a meno ... Beato chi ha scelto la strada della programmazione Java , li non ti prendono per il

[matt_vb6]

prima della migrazione Wizard Visual Studio 2008

[gibra]

Per curiosità ho fatto una prova ed a me la TrueDBGrid OLE DB 8 funziona perfettamente con VS2010 (VB.NET), come vedi dall'immagine allegata.



Evidentemente stai commettendo qualche errore.

Io ho impostato tutto da codice:

Public Class Form1
    Dim CN As ADODB.Connection
    Dim rs As ADODB.Recordset
    Dim sql As String
    Dim DBPath As String
    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        CN = New ADODB.Connection
        DBPath = "D:\BIBLIO\NWIND.MDB"
        sql = "SELECT * FROM orders"
        Dim ConnectionString As String = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + DBPath + ";Persist Security Info=False"

        CN.Open(ConnectionString)
        rs = New ADODB.Recordset
        rs.Open(sql, CN, ADODB.CursorTypeEnum.adOpenStatic, ADODB.LockTypeEnum.adLockReadOnly)

        AxTDBGrid1.Caption = sql + "  (" + DBPath + ")"
        AxTDBGrid1.CaptionStyle.Font.Bold = True
        AxTDBGrid1.FilterBar = True
        AxTDBGrid1.DataSource = rs

    End Sub
End Class

[matt_vb6]

Ciao Gibra,
la TrueDbGrid funziona perfettamente ... ma il wizard migration che legge il progetto VB6
e lo converte a .NET ammazza tutte le grid ...
Non ho capito come mai mette altezza riga 0 e cancella tutte le colonne .
Ho provato anche io a mettere la grid da Visual Studio e funziona 'abbastanza' bene ,
l'edit sembra non funzionare più in modo visivo , bisogna passare dalle proprietà .
Io non mi voglio rassegnare a rifarmi le grid una per una ....

[gibra]

Ma che versione hai di VS? Il Wizard l'hanno tolto nelle ultime versioni.

Assolutamente non usare il Wizard (altra ciofeca pazzesca di MS).
E' noto da un pezzo che la migrazione di un progetto da VB6 a VB.NET o C# va fatta 'a mano'.
In caso contrario otterrai solo codice-porcheria ed un sacco di errori.
Se migri a NET 'in quel modo' ti troverai sempre con un'applicazione scritta con vecchio VB6, ma eseguita in NET.

E dove sta il vantaggio in questo? Nessuno!
Non otterrai alcun serio vantaggio né dalla piattaforma, né dal linguaggio perchè non ha proprio senso usa COM in NET, alla fine otterrai un'applicazione COM che è 'wrappata' in NET. Non è cambiato niente.

Non so a che punto sei, quindi no so cosa consigliarti.

Ma prima di migrare a NET un progetto con 600 forms (ed immagino chissà quante classi, moduli, etc.) hai analizzato il costo di risorse (ore, uomo, soldi, ecc.) necessarie?
Una seria migrazione, richiede anche l'acquisto di nuovi componenti aggiornati appunto per la nuova piattaforma.
Nel tuo caso, ad esempio che usi controlli COM di ComponentOne, dovresti anche prevedere l'acquisto degli stessi controlli per la versione NET.

L'unico vero motivo per cui si rende necessaria una migrazione è quello che la vecchia applicazione ha bisogno di essere integrata con funzionalità che VB6-COM non può fornire.

Ma queste le puoi sempre integrare, dato che è possibile usare entrambi 'insieme'.

Oppure, se proprio vuoi, allora prova a vedere il VB-Migration di F. Balena.
Sembra (sembra!) che faccia miracoli...
Non so i costi, ma non saranno rose e fiori, visto che è un mistero conoscerli...

[matt_vb6]

ciao Gibra ,
effettivamente la paura è che Microsoft tolga completamente il supporto a VB6 ,
quindi nelle prossime versioni di Windows i programmi compilati con VB6 magari non
si potranno ne installare ne usare .
A quel punto ti trovi tagliato fuori dal business senza rimedio .

Anche le soluzioni del XP virtuale non so quanto regga e cmq
ad un cliente nuovo che ti acquista un software non puoi dirgli che gira
con un emulatore di windows obsoleti ....

Ecco perchè la decisione di migrare su una piattaforma che ti permetta
di compilare per i nuovi OS Windows ...

Mi sbaglio ?

[matt_vb6]

p.s. il migration wizard integrato in VS2008
è quello della Artinsoft ... proprio quelli che ti promettono
una migrazione indolore .

In VS2010 hai la possibilità di migrare 10.000 righe di codice
con il famoso VBUC Artinsoft che dovrebbe essere di F. Balena

[oregon]

Originariamente inviato da gibra
Oppure, se proprio vuoi, allora prova a vedere il VB-Migration di F. Balena.
Sembra (sembra!) che faccia miracoli...
Non so i costi, ma non saranno rose e fiori, visto che è un mistero conoscerli...

Non mi fido di questi tool, anche se di Balena ...

[gibra]

Originariamente inviato da matt_vb6
ciao Gibra ,
effettivamente la paura è che Microsoft tolga completamente il supporto a VB6 ,
quindi nelle prossime versioni di Windows i programmi compilati con VB6 magari non
si potranno ne installare ne usare .
A quel punto ti trovi tagliato fuori dal business senza rimedio .

Anche le soluzioni del XP virtuale non so quanto regga e cmq
ad un cliente nuovo che ti acquista un software non puoi dirgli che gira
con un emulatore di windows obsoleti ....

Ecco perchè la decisione di migrare su una piattaforma che ti permetta
di compilare per i nuovi OS Windows ...

Mi sbaglio ?

Per me sì.
Prima che venga eliminato il supporto runtime di VB6 ne passerà acqua sotto i ponti.
Tieni presente che quando, e se lo farà, allora saranno tagliate fuori tutte le applicazioni Office (!)
Tu che dici? Microsoft farà fuori sé stessa?
Tutto è possibile, ma io penso proprio che non avverrà mai.
Intanto il supporto è già assicurato anche per Windows 8...

Infatti NON supportare VB6 vorrebbe dire non supportare nemmeno più VBA, per non parlare poi delle innumerevoli applicazioni di terze parti che includo il support VBA al loro interno.

Ora, dato che i programmi VB6 girano senza alcun problema, quale sarebbe l'idea vincente di non supportarlo più? A che pro?
Tra l'altro non è che Microsoft debba fare tutta 'sta gran fatica a continuare a supportarlo: basta che sia presente la virtual machine di VB6 (1 libreria!).


Riguardo a quanto promesso dai tool di migrazione, concordo con oregon.
Le promesse servono a vendere, punto!
Qualcuno si ricorda quanto veniva sbandierato da MS alla nascita del NET?
In particolare, mi ricordo certe affermazioni di persone che 'oggi' (guarda caso) sono diventati MVP, del tipo:

"Non è cambiato niente!"
"Scrivere in VB.NET è come scrivere in VB6."
"Anzi! E' tutto più facile... Incredibile... Fantastico..."

Salvo poi a scoprire che invece... è tutta un'altra cosa.
Stop! Mi fermo qui....

Ammesso, e non concesso, che esistano tool di migrazione che fanno più o meno il loro dovere, ma poi che te ne fai?
Niente, perchè quando è ora di mettere le mani nel codice, se non conosci il linguaggio... buonanotte suonatori!

Invece ritengo, che la migrazione (quando serve ed è giustificata) possa essere anche una fase che ti permette di studiare ed imparare il linguaggio, potendo così rendersi conto dei veri vantaggi.

Lo sai che esiste un libro:
Visual Basic 6.0 Aggiornare le applicazioni a Visual Basic .NET e Visual Basic 2005.
un 'tomo' di 600 pagine (ed è in edizione I Portatili!!!)
indovina scritto e pubblicato da chi?
- F. Balena
- Microsoft Press
- ArtinSoft
Editore: Mondadori Informatica

Poi mi fanno davvero ridere quelli che 'buttano' lì la solita frase dall'alto della loro sapienza (del menga):

Migra tutto a .NET!

e lo dicono come se fosse una passeggiata (Ma dai! Eccheccevò?!)

[matt_vb6]

Attenzione Gibra ... è pericoloso rimanere ancorati al passato quando si parla di informatica...

E le notizie non sono buone :

Fine supporto VB6 su Windsows 8

E poi hai installato VB6 su Windows 7 64 bit ?
Non è stato facilissimo ...

Io credo che la vita delle applicazioni win32 e ActiveX sia ancora molto breve
e gli articoli sche si trovano su Internet supportano questa mia idea .

Purtroppo chi , come me , ha un gestionale sviluppato in anni e anni di lavoro
si troverà prima o poi ad affrontare la questione in modo inevitabile .