Newsgroup: it.comp.lang.delphi
Titolo: delphi 8

Salve a tutti,
qualcumo mi sa dire se con delphi 8 professional , è possibile 
importare un progetto fatto con delphi 6 enterprise che usa ADO per
gestire un DB di access e compilare a 32 bit.
grazie per l'aiuto
rox

gestire un DB di access e compilare a 32 bit.
Non e' possibile. 
Il problema e' che (al momento) in D8 mancano i componenti ADO. Forse Borland
li mettera' piu' avanti :-/ ma al momento non puoi convertire i progetti, devi
mettere mano al codice e sostituire le tue adotable con altri dataset.
-- 
Morde. 
(
mo...@despammed.com
)
M-List di icld: 
http://it.groups.yahoo.com/group/icld/

)

 importare un progetto fatto con delphi 6 enterprise
mi sa che non hai ben chiaro il fatto che D8 non ha *NIENTE* a che vedere
con D7 e precedenti. E' un sistema completamente diverso, e cosi' lo sono
componenti, librerie, ecc. La classe 
VCL.NET
 e', nei fatti, inutilizzabile
per fare "porting" di vecchi progetti, dal momento che solo un pazzo, con la
pletora di componenti disponibili per D7 e precedenti, avrebbe sviluppato
applicazioni con la VCL standard.

 standard.
Io sono riuscito a portare nella VCL for .NET gli elementi di base di un
programma gestionale creato con Delphi 7.
L'applicazione in esame utilizza vari Data Control, la piattaforma per
l'accesso ai dati dbExpress, i componenti ClientDataSet e
DataSetProvider nonchè il componente DataAccess, i Frame a livello
estremo (quanto mi piacciono...), altri controlli standard e specifici
di Win32, Dialogs (per selezione file da caricare/salvare).
Ho dovuto modificare un paio di righe che contenevano dei cast
cosiddetti "unsafe".
Alcune modifiche sono da apportare anche ad alcuni controlli custom che
ho realizzato.
Quando i membri dell'Indy Team completeranno il loro lavoro riguardo a
"Indy for .NET", magari potrò continuare, dato che mancano tutti i
componenti server. :-)
Avendo organizzato molta della "business logic" in frame di base
codificati in linguaggio Delphi, il porting è abbastanza facilitato, ma
si tratta comunque di un'operazione *non automatica*, da seguire
attentamente passo per passo dopo aver appreso le caratteristiche del
framework...nonostante ciò, non è per nulla un processo impossibile da
portare a termine, e comunque c'è sempre da ribadire che non è
obbligatorio farlo ora, anzi magari non c'è pure bisogno di farlo
(dipende essenzialmente dall'applicativo).


 obbligatorio farlo ora, anzi magari non c'è pure bisogno di farlo
sono d'accordo. Il porting di vecchi progetti e' semplicemente
improponibile. E' preferibile rifare tutto da zero, quando e se sara' il
caso, tra un po' di anni. Immagino quanto saranno contenti i clienti di
dover pagare i salatissimi costi di "upgrade" dei loro gestionali sotto
BlackComb che non supportera' piu' Win32.

 gestionali sotto BlackComb che non supportera' piu' Win32.
Uhm... io a dire la verità ho scritto righe e righe di testo proprio per
dimostrare che il porting non è assolutamente una soluzione
improponibile, o almeno non lo è in assoluto.
Che sia preferibile rifare tutto da zero, non credo proprio. L'unico
suggerimento che mi sento di dare è quello di tenere sempre d'occhio
l'evoluzione del .NET Framework indagando sulle intenzioni delle case
produttrici degli ambienti di sviluppo e componenti di terze parti per
questa piattaforma, in modo da poter facilitare l'operazione di porting
se sarà necessario.
Felicità dei clienti? Costi di upgrade? Trovo che sia del tutto
normale...trovo che siano problemi con cui si ha a che fare tutt'oggi.
La loro incisione dipende poi solo da come si organizza il lavoro e da
quanto si rimane preparati sui possibili cambiamenti, secondo me.
Come è possibile progettare un software pretendendo che questo rimanga
/in auge/ per 20 anni??
Pure escludendo l'avvento del framework, è normale che i sistemi
operativi vengano aggiornati o che comunque il mondo dell'Information
Technology introduca ogni giorno nuove possibilità inducendo i clienti
ad acquisire nuove esigenze e abitudini che gli sviluppatori devono poi
soddisfare prontamente fornendo strumenti adeguati...rientra nella
deontologia del programmatore, secondo me.
Poi, se si decide volontariamente di rifiutare il porting del proprio
software nella nuova piattaforma fino a quando non si tratta di un
processo strettamente necessario, allora è normale prevedere tempi duri
(soprattutto molto "ristretti") e costi elevati per i clienti, ma questo
non è un problema derivato dall'introduzione del .NET Framework, bensì
da una mancanza dello sviluppatore o da una sua impreparazione.
Dopo aver letto alcuni articoli, credo che - opinione personalissima -
le strade che lasciano maggiori probabilità di manutenzione agevolata
del software siano queste:
1) sviluppare direttamente con Delphi 8, utilizzando "Windows Forms" o
"VCL for .NET" in base alle proprie preferenze e abitudini;
2) sviluppare con Delphi 7 utilizzando componenti il più possibile
«standard», che esistano nella controparte .NET, oppure pacchetti di
terze parti dopo aver interrogato il produttore attraverso il sito o in
email riguardo alle sue intenzioni di apertura verso .NET.
Questo per quanto riguarda le applicazioni desktop; sul lato "sviluppo
Web", direi che ASP .NET al momento domina abbastanza incontrastato. :-)


 email riguardo alle sue intenzioni di apertura verso .NET.
usare la VCL standard per sviluppare applicazioni commerciali, benche'
qualcuno lo faccia, e'  a mio parere un'assurdita', e' troppo limitata e
farragginosa. I componenti di terze parti sono, quindi, indispensabili.
Certo, bisognera' dare il tempo ai produttori di adeguarli al .NET. Ci
vorra' qualche anno. A quel punto si potra' affrontare, anche dal mio punto
di vista, l'ipotesi del porting. Fino ad allora e' una cosa che non prendo
neanche in considerazione, cosi' come, a maggior ragione, e' del tutto
esclusa una qualsivoglia "riscrittura da zero" dei miei applicativi.
Ciao :)

 "riscrittura da zero" dei miei applicativi.
Credo ci vorrà molto meno di qualche anno.
A proposito, anche ReportBuilder è in fase di "migrazione" e sarà presto
disponibile per tutti gli sviluppatori .NET, visto che tra l'altro è uno
dei tool di reporting più utilizzati.
P.S.: queste discussioni sono veramente "gagliarde"...si imparano sempre
cose nuove. ;-)


 BlackComb che non supportera' piu' Win32.
Ho letto in giro per NG che la nuova 
VCL.NET
 servira' per garantire la
compatibilita' con il .Net framework, ed usarlo quindi al posto delle
librerie .net di M$ (come del resto e' sempre stato), sulle quali poi
Borland si appoggia per crear le proprie(almeno cosi' ho capito). Solo
che,almeno per questa volta, .net e' un prodotto completo e ben
articolato, in molti articoli si legge che sia il miglior prodotto di M$.
Ho anche letto che M$, con il nuovo LongHorn, il nuovo S.O. erede di xp,
usera' delle librerie ancora diverse da quelle usate per .net, gia' in
fase di sviluppo. quindi cambieranno ancora le cose, entro un paio d'anni.
Borland, con la sua 
vcl.net
, si pensa che voglia mantenere la
compatibilita' tra queste due nuove librerie di M$ ed assisterci al
passaggio tra le librerie.
Queste sono tutte informazioni che ho letto in un thread su
	delphiedintorni.it.delphi.dotnet
uno dei ng di Cantu'.
Quindi non ho la certezza che sia effettivamente cosi'. Ho verificato
solamente delle previsioni di M$ in materia del nuovo S.O. e delle nuove
librerie, sul sito delle MSDN.
[OT]
Io, nel frattempo, vorrei imparare a capire come fanno i vari produttori
di softwhare cross-platform, come quelli di OpenOffice, per fare
applicazioni che girano su piu' sistemi operativi, in modo da slegarmi
dai produttori.
O addirittura far tutto via web con java o PHP.
Sono molto deluso da come Borland abbia abbandonato gli sviluppatori e
tralasciato addirittura una fase importante, come quella della
migrazione su internet delle applicazioni.
[/OT]
Ciao,
Davide

 passaggio tra le librerie.
E' una cosa che è stata ventilata. Sino ad ora, Delphi è sempre stato di
grande aiuto in questo frangente...speriamo che lo sia di nuovo quando
sarà necessario, se sarà necessario. :-)
