Friday, September 26, 2014
Wednesday, February 22, 2012
Ubuntu 11.10 e Lazarus
Grazie a questo post sono finalmente riuscito a compilare ed eseguire un applicazione in Lazarus su Ubuntu 11.10.
Dopo aver installato VM Player ed aver creato una macchina virtuale Ubuntu, l'esecuzione di Lazarus dava alcuni problemi di focus e di controllo del Mouse.
L'arcano svelato nel post sopra.
Dopo aver installato VM Player ed aver creato una macchina virtuale Ubuntu, l'esecuzione di Lazarus dava alcuni problemi di focus e di controllo del Mouse.
L'arcano svelato nel post sopra.
Wednesday, February 01, 2012
Accesso via JDBC ad Oracle 8
Dopo un po' di patimento sono riuscito a connettermi ad un DB Oracle versione 8.0.5 via Netbeans.
Per far ciò ho scaricato dal sito di Oracle il driver ojdbc14.jar; infatti con le versioni più recenti (5 e 6) la connessione non era possibile. La modalità usata è Oracle Thin.
Tra l'altro il deploy dell'applicazione è molto semplice non richiedendo il client Oracle installato.
Per far ciò ho scaricato dal sito di Oracle il driver ojdbc14.jar; infatti con le versioni più recenti (5 e 6) la connessione non era possibile. La modalità usata è Oracle Thin.
Tra l'altro il deploy dell'applicazione è molto semplice non richiedendo il client Oracle installato.
Friday, August 12, 2011
Friday, July 15, 2011
Problema accesso ad AS/400 via JDBC
Il metodo
DriverManager.getConnection richiamato da un programma Console funziona correttamente e recupera la connessione.
Lo stesso codice inserito in una azione in Netbeans all'interno di una desktop application SWING ritorna null e non recupera la connessione.
Dopo tanto patire ho scoperto che il problema nasce dal fatto che il proxy era abilitato (come è giusto che sia) all'interno di IE.
Disattivando il proxy anche il codice Swing funziona.
Per evitare di disattivare il proxy tutte le volte è stato sufficiente aggiungere la seguente chiamate PRIMA della getConnection:
ProxySelector.setDefault(null);
DriverManager.getConnection richiamato da un programma Console funziona correttamente e recupera la connessione.
Lo stesso codice inserito in una azione in Netbeans all'interno di una desktop application SWING ritorna null e non recupera la connessione.
Dopo tanto patire ho scoperto che il problema nasce dal fatto che il proxy era abilitato (come è giusto che sia) all'interno di IE.
Disattivando il proxy anche il codice Swing funziona.
Per evitare di disattivare il proxy tutte le volte è stato sufficiente aggiungere la seguente chiamate PRIMA della getConnection:
ProxySelector.setDefault(null);
Friday, July 25, 2008
Delphi: Lettura dati da seriale
Lettura dati dalla porta seriale.
function Leggi(PortaCOM:String; Comando:String):String;
var str:string;
cmd, Buffer: Pchar;
hCom:Thandle;
ComStat: TComStat;
lpdcb:Tdcb;
bw,br:Dword;
Errors: DWORD;
begin
//Apro la porta
str := '';
hCom := CreateFile (pchar(PortaCOM),
GENERIC_READ + GENERIC_WRITE,
0, // comm devices must be opened w/exclusive-access*/
nil, // no security attrs */
OPEN_EXISTING, //* comm devices must use OPEN_EXISTING */ 0, //* not overlapped I/O */
0); //* hTemplate must be NULL for comm devices */ );
if (hCom = INVALID_HANDLE_VALUE) then
MessageBox(0, pChar('Impossibile aprire la porta seriale'), 'ATTENZIONE', MB_ICONSTOP or MB_OK)
else
if GetFileType( hCom ) <> FILE_TYPE_CHAR then
MessageBox(0, 'Attenzione errore apertura file', 'ATTENZIONE', MB_ICONSTOP or MB_OK)
else
Begin //Se tutto ok imposto i settaggi della porta: 9600:7:E:1
GetCommState(hCom, lpdcb);
lpdcb.BaudRate := Settaggi.BaudRate;
lpdcb.ByteSize := Settaggi.ByteSize;
lpdcb.Parity := Settaggi.Parity;
lpdcb.StopBits := Settaggi.StopBits;
SetCommState(hCom, lpdcb); //costruisco il comando da inviare alla porta
cmd := pchar(Comando);
bW := 0;
bR := 0;
str := ''; //Scrivo il comando sulla porta
WriteFile(hCom,cmd^,Length(Comando),bW,nil);
//Attendo 2 sec.
sleep(2000);
//Leggo i bytes nel buffer di input
ClearCommError(hCom, Errors, @ComStat);
if ComStat.cbInQue > 0 then
begin
//Alloco la memoria necessaria per memorizzare i bytes letti
GetMem(Buffer, ComStat.cbInQue);
//Leggo i bytes
ReadFile(hCom,Buffer^,ComStat.cbInQue,br,nil);
//trasferisco il buffer in Str
setLength(str, br);
Move(Buffer^, PChar(str)^, br);
//libero la memoria occupata dal buffer
FreeMem(Buffer);
end;
end;
closeHandle(hcom);
result:=str;
end;
Inseressante la funzione ClearCommError che consente di sapere i byte in attesa di essere scaricati. Questa funzione aspetta che sulla COM siano presenti i Byte riportati dalla funzione prima di uscire dal ReadFile.
function Leggi(PortaCOM:String; Comando:String):String;
var str:string;
cmd, Buffer: Pchar;
hCom:Thandle;
ComStat: TComStat;
lpdcb:Tdcb;
bw,br:Dword;
Errors: DWORD;
begin
//Apro la porta
str := '';
hCom := CreateFile (pchar(PortaCOM),
GENERIC_READ + GENERIC_WRITE,
0, // comm devices must be opened w/exclusive-access*/
nil, // no security attrs */
OPEN_EXISTING, //* comm devices must use OPEN_EXISTING */ 0, //* not overlapped I/O */
0); //* hTemplate must be NULL for comm devices */ );
if (hCom = INVALID_HANDLE_VALUE) then
MessageBox(0, pChar('Impossibile aprire la porta seriale'), 'ATTENZIONE', MB_ICONSTOP or MB_OK)
else
if GetFileType( hCom ) <> FILE_TYPE_CHAR then
MessageBox(0, 'Attenzione errore apertura file', 'ATTENZIONE', MB_ICONSTOP or MB_OK)
else
Begin //Se tutto ok imposto i settaggi della porta: 9600:7:E:1
GetCommState(hCom, lpdcb);
lpdcb.BaudRate := Settaggi.BaudRate;
lpdcb.ByteSize := Settaggi.ByteSize;
lpdcb.Parity := Settaggi.Parity;
lpdcb.StopBits := Settaggi.StopBits;
SetCommState(hCom, lpdcb); //costruisco il comando da inviare alla porta
cmd := pchar(Comando);
bW := 0;
bR := 0;
str := ''; //Scrivo il comando sulla porta
WriteFile(hCom,cmd^,Length(Comando),bW,nil);
//Attendo 2 sec.
sleep(2000);
//Leggo i bytes nel buffer di input
ClearCommError(hCom, Errors, @ComStat);
if ComStat.cbInQue > 0 then
begin
//Alloco la memoria necessaria per memorizzare i bytes letti
GetMem(Buffer, ComStat.cbInQue);
//Leggo i bytes
ReadFile(hCom,Buffer^,ComStat.cbInQue,br,nil);
//trasferisco il buffer in Str
setLength(str, br);
Move(Buffer^, PChar(str)^, br);
//libero la memoria occupata dal buffer
FreeMem(Buffer);
end;
end;
closeHandle(hcom);
result:=str;
end;
Inseressante la funzione ClearCommError che consente di sapere i byte in attesa di essere scaricati. Questa funzione aspetta che sulla COM siano presenti i Byte riportati dalla funzione prima di uscire dal ReadFile.
Thursday, May 08, 2008
Tuesday, April 22, 2008
Friday, April 04, 2008
Eval e Persistenza in Delphi
Ho affrontato un progetto in ACCESS molto interessante e per il quale ho usato la funzione Eval. Per chi non lo sapesse, questa funzione riceve una stringa e ne fa la valutazione. Per esempio Eval("2 + 3") ritorna 5.
Come stringa si può passare anche il nome di una funzione scritta da noi purchè con visibilità Public.
A questo punto mi sono chiesto come si potesse fare una cosa simile in Delphi, cioè chiamare una funzione usando il suo nome.
Ho trovato un esempio molto pertinente su About.com. Funziona a queste condizioni:
1. La procedura/funzione deve essere un metodo di una classe
2. Deve essere published (vedi punto 3)
3. La classe deve essere derivata da TPersistent o deve essere compilata con la direttiva {M+}
In Delphi è necessario che la classe abbia le informazioni di runtime (RTTI) per i metodi che si vogliono richiamare usando il loro nome. Le informazioni recuperabili tramite RTTI sono altrettanto utili per implementare la Persistenza, cioè la capacità di salvare lo stato degli oggetti creati all'interno di un programma.
Altri link interessanti sulla RTTI:
1. IMetal
2. Delphi Power Unleashed
3. Vari post sul Hallvard's Blogs come questo.
Come stringa si può passare anche il nome di una funzione scritta da noi purchè con visibilità Public.
A questo punto mi sono chiesto come si potesse fare una cosa simile in Delphi, cioè chiamare una funzione usando il suo nome.
Ho trovato un esempio molto pertinente su About.com. Funziona a queste condizioni:
1. La procedura/funzione deve essere un metodo di una classe
2. Deve essere published (vedi punto 3)
3. La classe deve essere derivata da TPersistent o deve essere compilata con la direttiva {M+}
In Delphi è necessario che la classe abbia le informazioni di runtime (RTTI) per i metodi che si vogliono richiamare usando il loro nome. Le informazioni recuperabili tramite RTTI sono altrettanto utili per implementare la Persistenza, cioè la capacità di salvare lo stato degli oggetti creati all'interno di un programma.
Altri link interessanti sulla RTTI:
1. IMetal
2. Delphi Power Unleashed
3. Vari post sul Hallvard's Blogs come questo.
Friday, November 23, 2007
Linguaggi di scripting e linguaggi compilati
Il rilascio di un programma non può mai essere considerato completamente a prova di bugs. Come si sa errori possono comparire anche dopo molto tempo e possono essere difficili da individuare nei cicli di test. In effetti molti errori possono non dipendere direttamente dal programma scritto in maniera non corretta, ma possono essere causati da dati non conformi alle aspettative.
Succede così che programmi che sono in esecuzione da anni, si blocchino improvvisamente su certi input.
Un ulteriore elemento di aleatorietà è rappresentato dalle interconnessioni che un certo programma deve avere con l'esterno (altri programmi, altri database). In questo caso può essere utile modificare la condotta del programma in base alla variazione del contorno.
Tutto quanto ho scritto sopra evidenzia come la possibilità di entrare in debug non appena si verifica un errore (difficilmente riproducibile) e di risolverlo all'istante per non bloccare un certo processo sia presupposto essenziale.
Gli approcci sono diversi a seconda che si adotti una soluzione compilata o una soluzione interpretata.
Nel primo caso, la correzione dell'errore comporta la disponibilità dei sorgenti, la disponibilità delle configurazioni per il compilatore e la possibilità di usare un ambiente conforme a quando il programma era stato sviluppato. Nel secondo caso ciò che è sufficiente è disporre dei diritti di aprire il file dei sorgenti (che deve essere presente perchè interpretato); se inoltre si dispone di un ambiente in cui il programma è in esecuzione allora le attività di debug sono veramente semplici.
Non voglio dire che l'approccio compilato sia sbagliato: per certi programmi è l'unica soluzione possibile e per programmi da pacchettizzare forse l'unica; voglio solo mettere in evidenza che nel caso in cui si sviluppi all'interno di un'azienda la soluzione da preferire (soprattutto per programmi che accedono a DBMS) è la seconda.
Ho già scritto in passato sulla differenza tra Delphi e MS Access e questo post vuole fornire ulteriori spunti alla discussione.
Succede così che programmi che sono in esecuzione da anni, si blocchino improvvisamente su certi input.
Un ulteriore elemento di aleatorietà è rappresentato dalle interconnessioni che un certo programma deve avere con l'esterno (altri programmi, altri database). In questo caso può essere utile modificare la condotta del programma in base alla variazione del contorno.
Tutto quanto ho scritto sopra evidenzia come la possibilità di entrare in debug non appena si verifica un errore (difficilmente riproducibile) e di risolverlo all'istante per non bloccare un certo processo sia presupposto essenziale.
Gli approcci sono diversi a seconda che si adotti una soluzione compilata o una soluzione interpretata.
Nel primo caso, la correzione dell'errore comporta la disponibilità dei sorgenti, la disponibilità delle configurazioni per il compilatore e la possibilità di usare un ambiente conforme a quando il programma era stato sviluppato. Nel secondo caso ciò che è sufficiente è disporre dei diritti di aprire il file dei sorgenti (che deve essere presente perchè interpretato); se inoltre si dispone di un ambiente in cui il programma è in esecuzione allora le attività di debug sono veramente semplici.
Non voglio dire che l'approccio compilato sia sbagliato: per certi programmi è l'unica soluzione possibile e per programmi da pacchettizzare forse l'unica; voglio solo mettere in evidenza che nel caso in cui si sviluppi all'interno di un'azienda la soluzione da preferire (soprattutto per programmi che accedono a DBMS) è la seconda.
Ho già scritto in passato sulla differenza tra Delphi e MS Access e questo post vuole fornire ulteriori spunti alla discussione.
Tuesday, November 20, 2007
Saturday, November 10, 2007
Tutti contro tutti
Leggendo questo articolo mi sono reso conto che le sensazioni da me provate al pensiero di usare una piattaforma al termine del suo ciclo di vita come Delphi, siano in realtà condivise da chi usa Java per sviluppare.
Nei commenti all'articolo sopra risulta interessante carpire i seguenti segnali:
Java sta diventando sempre più complesso
Java ha necessità di troppi pezzi software che devono essere messi assieme e configurati
Java richiede troppe risorse sulla macchina
Jave deve essere studiato a fondo per diventare produttivo.
I nuovi linguaggi di scripting come Ruby, PHP, Perl, hanno necessità di Apache e di un editor.
Un ragazzo che inizia ora a programmare, non può imparare una "valanga" di aspetti legati al framework e al contorno per poter essere produttivo e cominciare a vedere i risultati del suo lavoro.
Da questo punto di vista sicuramente Delphi è più avvantaggiato di Java: un ambiente unico, un solo produttore, componenti divisi per funzionalità, grande quantità di librerie e documentazione e soprattutto, come risultato, un programma compilato da trasferire semplicemente sul computer del cliente.
Nei commenti all'articolo sopra risulta interessante carpire i seguenti segnali:
Java sta diventando sempre più complesso
Java ha necessità di troppi pezzi software che devono essere messi assieme e configurati
Java richiede troppe risorse sulla macchina
Jave deve essere studiato a fondo per diventare produttivo.
I nuovi linguaggi di scripting come Ruby, PHP, Perl, hanno necessità di Apache e di un editor.
Un ragazzo che inizia ora a programmare, non può imparare una "valanga" di aspetti legati al framework e al contorno per poter essere produttivo e cominciare a vedere i risultati del suo lavoro.
Da questo punto di vista sicuramente Delphi è più avvantaggiato di Java: un ambiente unico, un solo produttore, componenti divisi per funzionalità, grande quantità di librerie e documentazione e soprattutto, come risultato, un programma compilato da trasferire semplicemente sul computer del cliente.
Thursday, August 30, 2007
Excel: VLookup + DSum insieme
Il problema del VLookup è che ritorna il primo valore che ritrova.
Il problema del DSum è che è necessario avere il range con i criteri.
La mia necessità è invece questa: fare la somma dei valori di una tabella che hanno il valore di ricerca (= valore prima colonna) uguale a quello indicato da me.
Ho creato questa UDF che consente di scandire la tabella e fare la somma dei valori della colonna indicata:
Parametri ricevuti:
- Lookup_Value = Valore da cercare
- Lookup_Table = Tabella dei valori (la prima colonna contiene la chiave di ricerca
- Column_Index = Colonna contenente i valori da sommare
Valore ritornato:
- Somma dei valori corrispondenti alla chiave passata
- Errore (#VALUE) (se il valore non è individuato)
Public Function TotRange(Lookup_Value As Variant, Lookup_Table As Range, Column_Index As Integer) As Variant
Dim riga As Integer
Dim tot
Dim trovato As Boolean
tot = 0
trovato = False
For riga = 1 To Lookup_Table.Rows.Count
If Lookup_Table.Cells(riga, 1) = Lookup_Value Then
trovato = True
tot = Lookup_Table.Cells(riga, Column_Index) + tot
End If
Next
If trovato Then
TotRange = tot
Else
TotRange = CVErr(10)
End If
End Function
Il problema del DSum è che è necessario avere il range con i criteri.
La mia necessità è invece questa: fare la somma dei valori di una tabella che hanno il valore di ricerca (= valore prima colonna) uguale a quello indicato da me.
Ho creato questa UDF che consente di scandire la tabella e fare la somma dei valori della colonna indicata:
Parametri ricevuti:
- Lookup_Value = Valore da cercare
- Lookup_Table = Tabella dei valori (la prima colonna contiene la chiave di ricerca
- Column_Index = Colonna contenente i valori da sommare
Valore ritornato:
- Somma dei valori corrispondenti alla chiave passata
- Errore (#VALUE) (se il valore non è individuato)
Public Function TotRange(Lookup_Value As Variant, Lookup_Table As Range, Column_Index As Integer) As Variant
Dim riga As Integer
Dim tot
Dim trovato As Boolean
tot = 0
trovato = False
For riga = 1 To Lookup_Table.Rows.Count
If Lookup_Table.Cells(riga, 1) = Lookup_Value Then
trovato = True
tot = Lookup_Table.Cells(riga, Column_Index) + tot
End If
Next
If trovato Then
TotRange = tot
Else
TotRange = CVErr(10)
End If
End Function
Tuesday, August 07, 2007
Introduzione all'IDE di Delphi
Versione gratuita Turbo Explorer per Win32
Una volta avviato, l'IDE presenta sei zone distinte:
1. Menu e toolbar
2. Structure
3. Object Inspector
4. Project Manager
5. Tool Palette
6. L'area centrale
Descrizione delle zone
1. Menu e toolbar
Rappresenta, come per ogni programma Windows, la zona contenente l'insieme dei comandi e delle opzioni che è possibile usare all'interno di Delphi.
2. Structure
Contiene l'albero dell'attuale Form/Unit aperta. Per albero si devono intendere due cose distinte a seconda che si stia lavorando al disegno visuale della form oppure all'interno del codice. Nel primo caso sarà visualizzato l'insieme dei controlli visuali connessi tramite la relazione Parent; nel secondo caso sarà mostrata la struttura della unit del codice organizzata per categoria sintattica (funzioni, campi, etc.)
3. Object Inspector
Diviso in 2 zone contiene le proprietà e gli eventi che è possibile impostare per il componente selezionato sulla form. Da qui è possibile indicare il valore delle proprietà (nel caso di proprietà complesse esistono degli editor appositi) e degli eventi associati al componente. Da un evento si va direttamente alla finestra del codice tramite doppio click.
4. Project Manager
Rappresenta la struttura dei file del progetto. In neretto è indicato il progetto attivo. Possono essere mantenuti aperti più progetti all'interno dell'IDE e ciò risulta molto comodo durante lo sviluppo di applicazioni complesse che usano diversi moduli (dll o eseguibili).
5. Tool Palette
Contiene l'insieme degli elementi che è possibile creare. Se non è stato ancora creato alcun progetto contiene le voci che sono presenti anche all'interno del menù FileNewOther; se invece siamo sulla form contiene i componenti visuali che è possibile inserire nella form.
6. L'area centrale
All'avvio contiene la Welcome page, durante lo sviluppo contiene la grafica della form su cui stiamo lavorando, il codice associato alla form e l'History della form. Questi tre elementi sono visualizzabili uno alla volta selezionando il tab corrispondente.
Struttura di un semplice programma
Pur consentendo lo sviluppo di un insieme di programmi molto vasto (da un Web Service ad un servizio per Windows) generalmente Delphi viene usato per lo sviluppo di applicazioni VCL Form. In pratica queste applicazioni rappresentano programmi Windows (32 bit attualmente) costituiti da una o più finestre (forms) su cui sono collocati gli elementi della VCL (libreria dei componenti usata in Delphi) necessari alla realizzazione dell'interfaccia grafica. A ciascun elemento della interfaccia sono poi agganciati gli eventi necessari alla realizzazione della logica applicativa. Una volta creato un programma VCL Form, Delphi automaticamente crea i seguenti files:
- il file principale di progetto (visibile richiamando il menù contestuale View Source) dalla finestra del Project Manager o premendo Control + V una volta selezionato il nome del progetto;
- il file del codice associato alla form il cui nome è generalmente Unit1.pas
- il file contenente la definizione della form il cui nome è Unit1.dfm
In genere il file su cui si interviene maggiormente è il file Unit1.pas che conterrà tutto il codice associato ai componenti della Form1.
Nel caso che venga aggiunta una nuova form al programma, Delphi creerà due nuovi file dal nome Unit2 .pas e Unit2.dfm.
All'interno del file Unitn.pas Delphi colloca il codice Object Pascal necessario alla definizione della form. Ricordiamo che Delphi sfrutta l'Object Pascal come linguaggio di programmazione (estensione ad oggetti del Pascal). Per questo, ogni form che viene creata è derivata dalla classe della VCL TForm. L'aggiunta di nuovi componenti visuali e di nuovi eventi, rendono poi la Form creata propria del nostro programma.
Ogni Unit creata da Delphi risente delle modifiche apportate graficamente alla form. In particolare:
- l'aggiunta di un componente visuale alla form, inserisce la dichiarazione di un campo nella definizione del nuovo tipo (la classe TForm1)
- l'inserimento di un nuovo evento inserisce un metodo sempre a livello della classe TForm1 che conterrà il codice di gestione dell'evento stessoNel caso in cui il componente sia incluso in una libreria NON inserita di default all'atto della creazione della form, viene inserito dopo la parola chiave uses il nome della libreria che comprende il componente.
La variazione dei dati a livello di proprietà sulla form, può rispecchiarsi anche sulla definizione della classe TForm1. Per esempio se cambiamo il nome di un componente inserito nella form, il nome viene cambiato anche nella definizione della form stessa.
NOTA IMPORTANTE:La variazione manuale del nome di un campo precedentemente inserito nella form direttamente dal codice comporta la perdita dell'allineamento automatico tra codice e designer e ciò può creare problemi in fase di compilazione.
Per esempio:
- inserire un componente Button sulla form
- spostarsi sul codice e modificare il nome dal default Button1 a Test
eseguendo il programma sarà segnalato un primo errore di Test non trovato tra i componenti inseriti sulla form e qualora si provveda alla rimozione un successivo errore in fase di creazione della form di Class TButton non trovata.
Se invece la modifica viene fatta dall'Object inspector questa si rispecchia all'interno del codice in maniera automatica sia a livello di nome del campo che a livello di nome dei vari eventi creati.
Una volta avviato, l'IDE presenta sei zone distinte:
1. Menu e toolbar
2. Structure
3. Object Inspector
4. Project Manager
5. Tool Palette
6. L'area centrale
Descrizione delle zone
1. Menu e toolbar
Rappresenta, come per ogni programma Windows, la zona contenente l'insieme dei comandi e delle opzioni che è possibile usare all'interno di Delphi.
2. Structure
Contiene l'albero dell'attuale Form/Unit aperta. Per albero si devono intendere due cose distinte a seconda che si stia lavorando al disegno visuale della form oppure all'interno del codice. Nel primo caso sarà visualizzato l'insieme dei controlli visuali connessi tramite la relazione Parent; nel secondo caso sarà mostrata la struttura della unit del codice organizzata per categoria sintattica (funzioni, campi, etc.)
3. Object Inspector
Diviso in 2 zone contiene le proprietà e gli eventi che è possibile impostare per il componente selezionato sulla form. Da qui è possibile indicare il valore delle proprietà (nel caso di proprietà complesse esistono degli editor appositi) e degli eventi associati al componente. Da un evento si va direttamente alla finestra del codice tramite doppio click.
4. Project Manager
Rappresenta la struttura dei file del progetto. In neretto è indicato il progetto attivo. Possono essere mantenuti aperti più progetti all'interno dell'IDE e ciò risulta molto comodo durante lo sviluppo di applicazioni complesse che usano diversi moduli (dll o eseguibili).
5. Tool Palette
Contiene l'insieme degli elementi che è possibile creare. Se non è stato ancora creato alcun progetto contiene le voci che sono presenti anche all'interno del menù FileNewOther; se invece siamo sulla form contiene i componenti visuali che è possibile inserire nella form.
6. L'area centrale
All'avvio contiene la Welcome page, durante lo sviluppo contiene la grafica della form su cui stiamo lavorando, il codice associato alla form e l'History della form. Questi tre elementi sono visualizzabili uno alla volta selezionando il tab corrispondente.
Struttura di un semplice programma
Pur consentendo lo sviluppo di un insieme di programmi molto vasto (da un Web Service ad un servizio per Windows) generalmente Delphi viene usato per lo sviluppo di applicazioni VCL Form. In pratica queste applicazioni rappresentano programmi Windows (32 bit attualmente) costituiti da una o più finestre (forms) su cui sono collocati gli elementi della VCL (libreria dei componenti usata in Delphi) necessari alla realizzazione dell'interfaccia grafica. A ciascun elemento della interfaccia sono poi agganciati gli eventi necessari alla realizzazione della logica applicativa. Una volta creato un programma VCL Form, Delphi automaticamente crea i seguenti files:
- il file principale di progetto (visibile richiamando il menù contestuale View Source) dalla finestra del Project Manager o premendo Control + V una volta selezionato il nome del progetto;
- il file del codice associato alla form il cui nome è generalmente Unit1.pas
- il file contenente la definizione della form il cui nome è Unit1.dfm
In genere il file su cui si interviene maggiormente è il file Unit1.pas che conterrà tutto il codice associato ai componenti della Form1.
Nel caso che venga aggiunta una nuova form al programma, Delphi creerà due nuovi file dal nome Unit2 .pas e Unit2.dfm.
All'interno del file Unitn.pas Delphi colloca il codice Object Pascal necessario alla definizione della form. Ricordiamo che Delphi sfrutta l'Object Pascal come linguaggio di programmazione (estensione ad oggetti del Pascal). Per questo, ogni form che viene creata è derivata dalla classe della VCL TForm. L'aggiunta di nuovi componenti visuali e di nuovi eventi, rendono poi la Form creata propria del nostro programma.
Ogni Unit creata da Delphi risente delle modifiche apportate graficamente alla form. In particolare:
- l'aggiunta di un componente visuale alla form, inserisce la dichiarazione di un campo nella definizione del nuovo tipo (la classe TForm1)
- l'inserimento di un nuovo evento inserisce un metodo sempre a livello della classe TForm1 che conterrà il codice di gestione dell'evento stessoNel caso in cui il componente sia incluso in una libreria NON inserita di default all'atto della creazione della form, viene inserito dopo la parola chiave uses il nome della libreria che comprende il componente.
La variazione dei dati a livello di proprietà sulla form, può rispecchiarsi anche sulla definizione della classe TForm1. Per esempio se cambiamo il nome di un componente inserito nella form, il nome viene cambiato anche nella definizione della form stessa.
NOTA IMPORTANTE:La variazione manuale del nome di un campo precedentemente inserito nella form direttamente dal codice comporta la perdita dell'allineamento automatico tra codice e designer e ciò può creare problemi in fase di compilazione.
Per esempio:
- inserire un componente Button sulla form
- spostarsi sul codice e modificare il nome dal default Button1 a Test
eseguendo il programma sarà segnalato un primo errore di Test non trovato tra i componenti inseriti sulla form e qualora si provveda alla rimozione un successivo errore in fase di creazione della form di Class TButton non trovata.
Se invece la modifica viene fatta dall'Object inspector questa si rispecchia all'interno del codice in maniera automatica sia a livello di nome del campo che a livello di nome dei vari eventi creati.
Tuesday, May 29, 2007
REFLECTION in .NET
La possibilità di estendere un programma con dei moduli esterni che ne aumentino le funzionalità è resa possibile grazie ai potenti meccanismi della Riflessione: la capacità di introspezione messa a disposizione da .NET.
ESTENDERE UNA GERARCHIA DI CLASSI
Supponiamo di avere un programma che fa uso di una gerarchia di classi per gestire i propri dati. Supponiamo di voler dare a chiunque la possibilità di estendere la gerarchia con classi proprie. Il programma fungerà da "creatore" degli oggetti inseriti nella gerarchia delle classi.
STABILIRE LE INTERFACCE
Evidentemente le classi che dovranno essere utilizzate all'interno del programma dovranno avere un'interfaccia comune (in termini di metodi, campi e proprietà). E' necessario stabilire a priori gli elementi comuni per non dover modificare il programma successivamente. Esistono due possibili strade per stabilire gli elementi comuni alle classi:- definire una interfaccia all'interno di una libreria di classi (interfaccia che poi sarà implementata da chi vorrà realizzare una nuova classe nella gerarchia)- definire una classe radice che elenchi metodi, campi e proprietà. Tale classe può eventualmente essere una classe astratta
I PASSI DELLA IMPLEMENTAZIONE
1. Crere una Class Library (MasterLibrary) contenente la classe astratta o la definizione di interfaccia:
//CLASSE ASTRATTA
public abstract class TRoot
{
public int DatoInt;
public string DatoString;
public abstract int MetodoInt(int a);
public abstract string MetodoString(string s);
}
//INTERFACCIA
public interface IRoot
{
int MetodoInt1(int a);
string MetodoString1(string s);
}
2. Farne il Build per creare la dll. In questo modo abbiamo l'assembly contenente gli elementi essenziali per creare librerie di classi per estendere il programma
3. Nel programma che realizzeremo si dovranno utilizzare 2 metodi della System.Reflection (LoadFile e CreateInstance). Questi 2 metodi servono rispettivamente per recuperare l'assembly contenente le classi da noi definite e per creare l'istanza della classe presente all'interno dell'assembly stesso.
Il nome dell'assembly e della classe possono essere recuperati da un file di parametri usato dal programma.
ESTENDERE LA GERARCHIA DELLE CLASSI
1. Creare una Class Library includendo come Reference la MasterLibrary.dll;
2. Derivare ogni classe dalla TRoot (nel caso si usi la Classe Astratta) o dalla IRoot (nel caso si usi l'Interfaccia);
3. Implementare i metodi secondo la logica prevista;
4. Creare un file di configurazione contenente il nome dell'Assembly (.dll) completo di path ed il nome delle classi incluse al suo interno che vogliamo mettere a disposizione nel programma;
PER FINIRE
In pratica:
1. Nella MasterLibrary vengono definiti gli elementi (in termini di metodi e campi) che saranno implementati in tutte le classi che estenderanno la classe base
2. In tutte le estensioni si dovrà far riferimento alle classi definite nella MasterLibrary ereditando da quest'ultime
3. Nel programma si potrà far riferimento alle classi grazie ai metodi previsti a livello di Reflection, creando nuovi oggetti dalle classi definite all'esterno.
ESTENDERE UNA GERARCHIA DI CLASSI
Supponiamo di avere un programma che fa uso di una gerarchia di classi per gestire i propri dati. Supponiamo di voler dare a chiunque la possibilità di estendere la gerarchia con classi proprie. Il programma fungerà da "creatore" degli oggetti inseriti nella gerarchia delle classi.
STABILIRE LE INTERFACCE
Evidentemente le classi che dovranno essere utilizzate all'interno del programma dovranno avere un'interfaccia comune (in termini di metodi, campi e proprietà). E' necessario stabilire a priori gli elementi comuni per non dover modificare il programma successivamente. Esistono due possibili strade per stabilire gli elementi comuni alle classi:- definire una interfaccia all'interno di una libreria di classi (interfaccia che poi sarà implementata da chi vorrà realizzare una nuova classe nella gerarchia)- definire una classe radice che elenchi metodi, campi e proprietà. Tale classe può eventualmente essere una classe astratta
I PASSI DELLA IMPLEMENTAZIONE
1. Crere una Class Library (MasterLibrary) contenente la classe astratta o la definizione di interfaccia:
//CLASSE ASTRATTA
public abstract class TRoot
{
public int DatoInt;
public string DatoString;
public abstract int MetodoInt(int a);
public abstract string MetodoString(string s);
}
//INTERFACCIA
public interface IRoot
{
int MetodoInt1(int a);
string MetodoString1(string s);
}
2. Farne il Build per creare la dll. In questo modo abbiamo l'assembly contenente gli elementi essenziali per creare librerie di classi per estendere il programma
3. Nel programma che realizzeremo si dovranno utilizzare 2 metodi della System.Reflection (LoadFile e CreateInstance). Questi 2 metodi servono rispettivamente per recuperare l'assembly contenente le classi da noi definite e per creare l'istanza della classe presente all'interno dell'assembly stesso.
Il nome dell'assembly e della classe possono essere recuperati da un file di parametri usato dal programma.
ESTENDERE LA GERARCHIA DELLE CLASSI
1. Creare una Class Library includendo come Reference la MasterLibrary.dll;
2. Derivare ogni classe dalla TRoot (nel caso si usi la Classe Astratta) o dalla IRoot (nel caso si usi l'Interfaccia);
3. Implementare i metodi secondo la logica prevista;
4. Creare un file di configurazione contenente il nome dell'Assembly (.dll) completo di path ed il nome delle classi incluse al suo interno che vogliamo mettere a disposizione nel programma;
PER FINIRE
In pratica:
1. Nella MasterLibrary vengono definiti gli elementi (in termini di metodi e campi) che saranno implementati in tutte le classi che estenderanno la classe base
2. In tutte le estensioni si dovrà far riferimento alle classi definite nella MasterLibrary ereditando da quest'ultime
3. Nel programma si potrà far riferimento alle classi grazie ai metodi previsti a livello di Reflection, creando nuovi oggetti dalle classi definite all'esterno.
Sunday, May 06, 2007
Sui bravi programmatori
Riporto in inglese una frase estratta da un forum su VB estratto da Codeproject
"There are not bad languages, there are bad programmers, whatever language they use."
traduco: "Non ci sono linguaggi non buoni, ci sono programmatori non buoni, indipendentemente dal linguaggio che usano".
Vorrei riportare qui alcuni punti essenziali:
- VB ha permesso a molti (anche non professionisti) di sviluppare programmi
- VB ha indotto molti a credere che per scrivere un buon programma fosse sufficiente mettere alcuni controlli su una form senza avere alcun tipo di background scientifico per risolvere correttamente determinati problemi
- VB è stato ed è (VB.NET) un linguaggio come tanti altri che, se usato professionalmente può consentire di sviluppare ottimi programmi.
Per esperienza diretta:
- esistono linguaggi (Java per primo) che impongono dei paradigmi di programmazione che per essere compresi necessitano di una buona preparazione teorica
- qualunque linguaggio si usi la "strutturazione del codice" è fondamentale per una buona gestione dei progetti
"There are not bad languages, there are bad programmers, whatever language they use."
traduco: "Non ci sono linguaggi non buoni, ci sono programmatori non buoni, indipendentemente dal linguaggio che usano".
Vorrei riportare qui alcuni punti essenziali:
- VB ha permesso a molti (anche non professionisti) di sviluppare programmi
- VB ha indotto molti a credere che per scrivere un buon programma fosse sufficiente mettere alcuni controlli su una form senza avere alcun tipo di background scientifico per risolvere correttamente determinati problemi
- VB è stato ed è (VB.NET) un linguaggio come tanti altri che, se usato professionalmente può consentire di sviluppare ottimi programmi.
Per esperienza diretta:
- esistono linguaggi (Java per primo) che impongono dei paradigmi di programmazione che per essere compresi necessitano di una buona preparazione teorica
- qualunque linguaggio si usi la "strutturazione del codice" è fondamentale per una buona gestione dei progetti
Campi statici e variabili di classe
Ho letto questo blog e mi sono venuti alcuni dubbi che ho poi fugato facendo alcuni esempi.
Java ha sempre avuto i campi static, cioè le variabili globali a livello di classe. In Delphi questa caratteristica è stata introdotta (per rispettare .NET) dalla versione 8 (solo .NET) poi riportata nella versione per Win32.
Il dubbio che mi è sovvenuto è il seguente:
cosa succede nel caso che una classe derivi da un'altra che ha un campo static pubblico?
La risposta è la seguente:
il campo static (cioè la variabile di classe) è condivisa tra tutte le sottoclassi della classe che ha dichiarato quel campo come static. In pratica se ho queste classi:
T1 = class
class var a:integer;
...
end;
e
T2 = class(T1)
...
end;
T1.a e T2.a riferiscono la stessa variabile.
Se voglio differenziare T2.a da T1.a DEVO dichiararla nuovamente.
Questo è lo stesso comportamento di Java.
Come indicato nel post da me citato, la precedente possibilità era di quella di usare una variabile globale a livello di unit.
La situazione è ora molto più object oriented (anche per Delphi).
Java ha sempre avuto i campi static, cioè le variabili globali a livello di classe. In Delphi questa caratteristica è stata introdotta (per rispettare .NET) dalla versione 8 (solo .NET) poi riportata nella versione per Win32.
Il dubbio che mi è sovvenuto è il seguente:
cosa succede nel caso che una classe derivi da un'altra che ha un campo static pubblico?
La risposta è la seguente:
il campo static (cioè la variabile di classe) è condivisa tra tutte le sottoclassi della classe che ha dichiarato quel campo come static. In pratica se ho queste classi:
T1 = class
class var a:integer;
...
end;
e
T2 = class(T1)
...
end;
T1.a e T2.a riferiscono la stessa variabile.
Se voglio differenziare T2.a da T1.a DEVO dichiararla nuovamente.
Questo è lo stesso comportamento di Java.
Come indicato nel post da me citato, la precedente possibilità era di quella di usare una variabile globale a livello di unit.
La situazione è ora molto più object oriented (anche per Delphi).
Friday, March 16, 2007
I Miei Blogs futuri
Vorrei, tempo permettendo, publicare una serie di blogs sui seguenti argomenti:
1- Perchè Delphi?
Perchè scegliere Delphi per programmare
2- Delphi ed MSAccess
Le differenze e i vantaggi di una scelta piuttosto che dell'altra
3- Access ed i Template di Outlook (.OFT)
Come aprire da Access un Mail Template di Outlook
4- Migrazione da Access a SQL Server
Alcune indicazioni sulla migrazione dei dati da Access a SQL server
5- Le ultime novità di Delphi
Delphi 2007 oramai è alle porte
6- Lettura del pensiero
La sera avevo un problema. La mattina trovo un Post che fa al caso mio. Incredibile.
1- Perchè Delphi?
Perchè scegliere Delphi per programmare
2- Delphi ed MSAccess
Le differenze e i vantaggi di una scelta piuttosto che dell'altra
3- Access ed i Template di Outlook (.OFT)
Come aprire da Access un Mail Template di Outlook
4- Migrazione da Access a SQL Server
Alcune indicazioni sulla migrazione dei dati da Access a SQL server
5- Le ultime novità di Delphi
Delphi 2007 oramai è alle porte
6- Lettura del pensiero
La sera avevo un problema. La mattina trovo un Post che fa al caso mio. Incredibile.
Wednesday, January 03, 2007
RISOLTO!
Dopo una quindicina di giorni di lavoro ho risolto, con l'aiuto di tutta la famiglia Mystery Case Files - Prime Suspects. Grande e coinvolgente gioco!
Divertentissimo il finale.
Divertentissimo il finale.
Monday, January 01, 2007
Cast e ListView in Delphi
In molte applicazioni si ha la necessità di dare all'utente la possibilità di creare più oggetti della stessa classe. Questi oggetti hanno una propria vita e l'utente deve poterli selezionare per lavorare su di essi.
Una situazione classica è quella di avere una lista di tali oggetti da cui selezionare quello su cui si vuole lavorare. Sorge il problema di passare dalla selezione sulla lista all'oggetto associato.
In Win32 una lista ha una sua rappresentazione come ListView. Una riga della ListView (ListItem) è un oggetto che ha, tra le proprietà, un puntatore (Data). Questo puntatore consente di memorizzare, tra le altre cose, il riferimento all'oggetto che noi associamo alla riga della lista.
L'uso del cast consente di "leggere" il puntatore come l'oggetto che abbiamo associato alla riga.
Ecco un esempio:
Creazione dell'oggetto
var
lv:TListItem;
p:TOggetto;
begin
lv:=lvElenco.Items.add;
lv.Caption:='Oggetto '+inttostr(lvElenco.Items.Count);
//creazione dell'oggetto
p:=TOggetto.create;
//associazione dell'oggetto all'Item appena creato
lv.Data:=p;
end;
Recupero dell'oggetto associato alla riga della lista (Item):
var
obj:TOggetto;
begin
//recupero l'oggetto tramite il casting
obj:=TOggetto(Item.Data);
...
end;
Una situazione classica è quella di avere una lista di tali oggetti da cui selezionare quello su cui si vuole lavorare. Sorge il problema di passare dalla selezione sulla lista all'oggetto associato.
In Win32 una lista ha una sua rappresentazione come ListView. Una riga della ListView (ListItem) è un oggetto che ha, tra le proprietà, un puntatore (Data). Questo puntatore consente di memorizzare, tra le altre cose, il riferimento all'oggetto che noi associamo alla riga della lista.
L'uso del cast consente di "leggere" il puntatore come l'oggetto che abbiamo associato alla riga.
Ecco un esempio:
Creazione dell'oggetto
var
lv:TListItem;
p:TOggetto;
begin
lv:=lvElenco.Items.add;
lv.Caption:='Oggetto '+inttostr(lvElenco.Items.Count);
//creazione dell'oggetto
p:=TOggetto.create;
//associazione dell'oggetto all'Item appena creato
lv.Data:=p;
end;
Recupero dell'oggetto associato alla riga della lista (Item):
var
obj:TOggetto;
begin
//recupero l'oggetto tramite il casting
obj:=TOggetto(Item.Data);
...
end;
Felix Colibri: Documentazione su Delphi
Ulteriore documentazione sull'uso di Delphi.
Molto ben fatta la gestione delle basi dati.
Molto ben fatta la gestione delle basi dati.
Wednesday, December 13, 2006
Blogs tecnici italiani
Un link da annotare tra quelli da controllare giornalmente:
http://blogs.ugidotnet.org/
http://blogs.ugidotnet.org/
Tuesday, December 05, 2006
Interfacce, Garbage collection e COM
Leggendo un capitolo gratuito su Delphi per .NET di Marco Cantù dove vengono analizzate le modifiche effetuate al linguaggio per adattarlo a .NET, ho riflettuto su un passaggio lì riportato riguardante le interfacce. In pratica e finalmente il concetto di Interfaccia si sgancia da COM: non è più necessario associare ad un interfaccia un GUID.
Il passaggio che mi ha interessato di più è quello in cui si fa riferimento al "reference counting".
In pratica se un oggetto espone un interfaccia può essere acceduto da parte di altri oggetti attraverso questa interfaccia. La domanda che sorge spontanea è la seguente: chi distrugge l'oggetto originario?
In un ambiente COM dove non esiste un Garbage collector la cosa viene gestita tramite il meccanismo del conteggio dei riferimenti (reference counting): ogni volta che un oggetto A accede ad un altro B tramite l'interfaccia, B incrementa di uno il numero di riferimenti. Quando l'oggetto A termina di riferire B il numero dei riferimenti è decrementato.
Tutto ciò ha senso se non esiste (come in JAVA e in .NET) un sistema automatico di gestione dei riferimenti che automaticamente distrugge gli oggetti non più riferiti da nessuno.
Per quanto riguarda il reference counting in COM suggerisco quest'altro articolo oltre che l'onnipresente Wikipedia
Il passaggio che mi ha interessato di più è quello in cui si fa riferimento al "reference counting".
In pratica se un oggetto espone un interfaccia può essere acceduto da parte di altri oggetti attraverso questa interfaccia. La domanda che sorge spontanea è la seguente: chi distrugge l'oggetto originario?
In un ambiente COM dove non esiste un Garbage collector la cosa viene gestita tramite il meccanismo del conteggio dei riferimenti (reference counting): ogni volta che un oggetto A accede ad un altro B tramite l'interfaccia, B incrementa di uno il numero di riferimenti. Quando l'oggetto A termina di riferire B il numero dei riferimenti è decrementato.
Tutto ciò ha senso se non esiste (come in JAVA e in .NET) un sistema automatico di gestione dei riferimenti che automaticamente distrugge gli oggetti non più riferiti da nessuno.
Per quanto riguarda il reference counting in COM suggerisco quest'altro articolo oltre che l'onnipresente Wikipedia
ACCESS e le classi
Ho già avuto modo di dire in passato che Access ha una serie di notevoli caratteristiche che lo rendono molto buono per la realizzazione di prototipi.
In questi giorni ho avuto modo di usare Access in maniera molto spinta ed ho dovuto strutturare il codice in modo da renderlo modulare. Poichè non avevo particolare necessità di creare Oggetti a runtime ho pensato di poter risolvere la cosa con le classi statiche. Questo purtoppo non può essere fatto poichè mancano sia metodi che campi statici (nel senso "vero" del termine). Quindi dopo qualche test ho optato per una strutturazione del codice tramite l'uso dei moduli (non di classe). In pratica questi moduli si comportano a tutti gli effetti come classi statiche ed anche il meccanismo di chiamata con i punti di separazione modulo.funzione o modulo.campo rende il codice molto leggibile.
In questi giorni ho avuto modo di usare Access in maniera molto spinta ed ho dovuto strutturare il codice in modo da renderlo modulare. Poichè non avevo particolare necessità di creare Oggetti a runtime ho pensato di poter risolvere la cosa con le classi statiche. Questo purtoppo non può essere fatto poichè mancano sia metodi che campi statici (nel senso "vero" del termine). Quindi dopo qualche test ho optato per una strutturazione del codice tramite l'uso dei moduli (non di classe). In pratica questi moduli si comportano a tutti gli effetti come classi statiche ed anche il meccanismo di chiamata con i punti di separazione modulo.funzione o modulo.campo rende il codice molto leggibile.
Sunday, November 19, 2006
Tuesday, November 14, 2006
CodeGear
CodeGear è la nuova società (sempre all'interno di Borland) che sarà focalizzata esclusivamente sugli ambienti di sviluppo.
Esce finalmente una notizia che mette un po' di sicurezza a tutti gli sviluppatori Delphi che si erano affidati ultimamente ad una strenua difesa del loro ambiente. Anche il DTG (Developers Tools Group) ha ultimamente mostrato un incredibile propensione alla diffusione di documentazione (soprattutto video) per l'uso di BDS2006 e Turbo Explorer.
A questo punto spero che venga messo anche un po' di ordine sui vari siti (ora sono 3) in modo che sia dato un riferimento unico agli sviluppatori.
W Delphi!
Esce finalmente una notizia che mette un po' di sicurezza a tutti gli sviluppatori Delphi che si erano affidati ultimamente ad una strenua difesa del loro ambiente. Anche il DTG (Developers Tools Group) ha ultimamente mostrato un incredibile propensione alla diffusione di documentazione (soprattutto video) per l'uso di BDS2006 e Turbo Explorer.
A questo punto spero che venga messo anche un po' di ordine sui vari siti (ora sono 3) in modo che sia dato un riferimento unico agli sviluppatori.
W Delphi!
Monday, November 06, 2006
Morfik
Ho scoperto per caso questo ambiente di sviluppo molto simile ad Access.
Lo scopo del progetto è lo sviluppo di un ambiente che consenta di realizzare un programma sia per l'esecuzione "stand alone" che per l'esecuzione via server web. Viene sfruttato AJAX per ottimizzare i tempi di risposta.
Mi è piaciuta molto l'interfaccia di sviluppo che consente tra le altre cose di scegliere il linguaggio di programmazione (che comprende anche il Pascal). E' un'interfaccia molto simile ad Access e per questo diventa immediatamente familiare.
Seguiamo questo interessante prodotto.
Introduzione a DELPHI
Se stai leggendo questa pagina probabilmente hai qualche interesse in Delphi.
Cosa è Delphi?
Delphi è un ambiente di sviluppo inventato da Borland a metà degli anni 90.
Un ambiente di sviluppo (IDE in breve) è una collezione di strumenti che consentono una gestione centralizzata di tutte le attività di sviluppo. In particolare:
- Disegno delle Form (maschere dell'applicazione)
- Scrittura del codice
- Esecuzione del codice
- Attività di Debug
Il linguaggio di Delphi
La scrittura del codice in Delphi avviene usando una estensione ad oggetti del Pascal denominato Object Pascal (ora anche Delphi). In pratica così come avvenuto a suo tempo per il C++, estensione ad oggetti del C, l'Object Pascal è l'estensione ad oggetti del Pascal.
Cosa posso fare con Delphi
Delphi consente di creare programmi per Windows (nella sua attuale versione a 32 bit) e per Linux per cui è stata prodotta una versione chiamata Kylix. Una delle caratteristiche più importanti (se non la più importante) è la sua universalità. In pratica chi conosce Delphi può realizzare sia programmi di basso livello (cioè che richiamano le funzionalità basiche del sistema operativo o di interfacciamento all'hardware) sia programmi per internet (programmazione di Web Service o siti web dinamici). Delphi è veramente General Pourpose.
Le versioni di Delphi
Come già detto Delphi esiste sia per la realizzazione di programmi Windows che per la realizzazione di programmi per Linux. Nel mondo Windows, in particolare, è stata da qualche anno introdotta una nuova tecnologia di programmazione denominata .NET. Delphi ha saputo differenziarsi ed attualmente è uno dei pochi strumenti che consente di realizzare programmi per Windows alla "vecchia maniera" cioè Nativi che programmi "managed" cioè che sfruttano .NET. Da qualche mese inoltre Delphi esiste anche in una modalità gratuita (Turbo Delphi Explorer).
La potenza di Delphi
Delphi è un IDE molto potente ed è abbinato ad un linguaggio molto espressivo utilizzato da anni nelle università per esporre i concetti informatici di base. Gli strumenti usati per lo sviluppo su piattaforme complesse (come Windows) devono rendere il più semplice e nel contempo potente l'accesso ai servizi offerti dal sistema operativo. Delphi ottiene questo risultato tramite la VCL (visual component library), una potente libreria ad Oggetti estendibile dal programmatore che mette a disposizione un insieme di componenti che virtualizzano ed incapsulano le chiamate ai servizi delle API di Windows. La VCL è stata estesa per coprire ogni tipo di esigenza di programmazione ed oggi è possibile trovare componenti (nella maggior parte dei casi gratuiti) che assolvono ai compiti di programmazione più disparati. Delphi deve quindi gran parte della sua potenza alla VCL.
Dove procurarsi Delphi
Delphi è disponibile in versione gratuita sul sito Turbo Explorer. Sono presenti in questo sito le due versioni di Delphi: Delphi per Windows 32 (Turbo Delphi Explorer) e Turbo Delphi per .NET. Consiglio inizialmente di scaricare la versione per Windows 32.
Delphi su Internet
Sono più di dieci anni che Delphi calca le scene. Per questo motivo è facile reperire su internet molta documentazione e soprattutto suggerimenti (tips) sulla risoluzione di problemi quotidiani di programmazione. I principali link da tenere presenti sono:
Tuesday, October 10, 2006
Sharp Develop 2
Ho aspettato e poi ho riprovato.
Ho seguito l'evoluzione di SharpDevelop dal suo limbo per Net1.1.
Ho scaricato ed installato la release corrente la 2.0.0 e devo dire che l'IDE è veramente maturo e ben fatto. Mi ha stupito l'Help (F1 sulla parola), il sistema di reporting e la scrittura del codice fila molto rapida.
Complimenti per l'ottimo lavoro.
Ho seguito l'evoluzione di SharpDevelop dal suo limbo per Net1.1.
Ho scaricato ed installato la release corrente la 2.0.0 e devo dire che l'IDE è veramente maturo e ben fatto. Mi ha stupito l'Help (F1 sulla parola), il sistema di reporting e la scrittura del codice fila molto rapida.
Complimenti per l'ottimo lavoro.
E 100
Ho raggiunto 100 Post in questo Blog. Non so se qualcuno mi legge con costanza e non so nemmeno se chi mi legge trova interessante ciò che dico. Comunque sono 100. Complimenti Luca!
Sunday, October 08, 2006
Gli sviluppatori Delphi
Leggendo i commenti agli ultimi post di Nick Hodges e di Marco Cantù, mi è storta spontanea questa osservazione: prima dell'avvento di .NET, esisteva Delphi (anche come CBuilder) come solo ambiente di sviluppo veramente produttivo per Windows (VB non era compilato e VC troppo complesso).
L'avvento di .NET ha provocato una rivoluzione: fornire a tutti la produttività di Delphi.
Unendo l'avvento di .NET alla mancata rapida risposta di Borland nel modificare Delphi per la nuova piattaforma, gli sviluppatori di Delphi si sono trovati per la prima volta a non poter rispondere rapidamente alle richieste dei clienti dal loro ambiente. In pratica sono dovuti uscire da Delphi e, guardandosi intorno hanno visto che tutto ciò che era avvenuto per Delphi (con la VCL e le sue molteplici estensioni) stava accadendo per FCL: Delphi aveva perso il primato.
In effetti Delphi, almeno attualmente, non è più e non può più essere l'unico ambiente cui si possono rivolgere gli sviluppatori. Ma forse è ora che la vera potenza di Delphi emerge prepotente. DevCo deve quanto prima colmare il gap e fornire il supporto per .NET2 e per lo sviluppo nativo a 64 bit!
L'avvento di .NET ha provocato una rivoluzione: fornire a tutti la produttività di Delphi.
Unendo l'avvento di .NET alla mancata rapida risposta di Borland nel modificare Delphi per la nuova piattaforma, gli sviluppatori di Delphi si sono trovati per la prima volta a non poter rispondere rapidamente alle richieste dei clienti dal loro ambiente. In pratica sono dovuti uscire da Delphi e, guardandosi intorno hanno visto che tutto ciò che era avvenuto per Delphi (con la VCL e le sue molteplici estensioni) stava accadendo per FCL: Delphi aveva perso il primato.
In effetti Delphi, almeno attualmente, non è più e non può più essere l'unico ambiente cui si possono rivolgere gli sviluppatori. Ma forse è ora che la vera potenza di Delphi emerge prepotente. DevCo deve quanto prima colmare il gap e fornire il supporto per .NET2 e per lo sviluppo nativo a 64 bit!
Tuesday, September 26, 2006
Thursday, September 21, 2006
TURBO DELPHI
Inserisco un pò di links utili:
- Sito Ufficiale
- Elenco siti per il download
- Download da sito TurboExplorer
- VIDEO CORSO IN INGLESE
- Blogs tecnici
- Wiki (enciclopedia) su Delphi
Monday, September 11, 2006
Prime impressioni su Turbo Delphi Explorer per Win32
Avevo già avuto modo di usare Delphi 2006 nella versione Demo.
L'ambiente Turbo è lo stesso di Delphi 2006 ed ha tutte le caratteristiche innovative rispetto ai vecchi Delphi.
In particolare mi piacciono:
Il prodotto è veramente molto valido considerando anche il fatto che è gratuito e che probabilmente sarà usato da molte persone alle prime armi.
L'ambiente Turbo è lo stesso di Delphi 2006 ed ha tutte le caratteristiche innovative rispetto ai vecchi Delphi.
In particolare mi piacciono:
- L'editor: molto ben fatto
- La finestra Code Insight che risulta molto veloce rispetto alle precedenti versioni
- L'inclusione dei componenti per l'accesso ai dati: dbExpress, BDE ed ADO
Il prodotto è veramente molto valido considerando anche il fatto che è gratuito e che probabilmente sarà usato da molte persone alle prime armi.
Thursday, August 31, 2006
Application.ProcessMessages in Delphi
Nel mio ultimo programma mi sono imbattuto sul metodo in oggetto: per evitare il blocco del programma ho inserito, in diversi punti (soprattutto in loop di attesa) un bel ProcessMessages.
Il programma che aveva mostrato una certa stabilità, ha iniziato ad avere una serie di scompensi e di blocchi anomali.
Ho iniziato a verificare in debug ed ho scoperto che altri ProcessMessages erano presenti nel codice del componente da me utilizzato.
Fondamentalmente la questione è così riassumibile:
nel caso in cui in una procedura evento sia usata una particolare risorsa (esempio una porta COM), e durante l'uso della risorsa si esegue un Application.ProcessMessages è necessario garantire che non si possa generare alcun evento che magari vada a riaprire la porta COM. Detta così la cosa sembra chiara e semplice, in realtà in progetti complessi dove gli eventi possono generarsi in più parti (magari nemmeno dall'interfaccia utente), è necessario conoscere bene l'uso che il programma fa della risorsa.
Usate Application.ProcessMessages con oculatezza e, se proprio non potete farne a meno, disabilitate gli eventi che possono generare "rientro" (ovvero richiamo della stessa procedura) o introducete il concetto di stato della risorsa (in altri termini se la risorsa è nello stato x non si può effettuare la operazione di nuovo).
Il programma che aveva mostrato una certa stabilità, ha iniziato ad avere una serie di scompensi e di blocchi anomali.
Ho iniziato a verificare in debug ed ho scoperto che altri ProcessMessages erano presenti nel codice del componente da me utilizzato.
Fondamentalmente la questione è così riassumibile:
nel caso in cui in una procedura evento sia usata una particolare risorsa (esempio una porta COM), e durante l'uso della risorsa si esegue un Application.ProcessMessages è necessario garantire che non si possa generare alcun evento che magari vada a riaprire la porta COM. Detta così la cosa sembra chiara e semplice, in realtà in progetti complessi dove gli eventi possono generarsi in più parti (magari nemmeno dall'interfaccia utente), è necessario conoscere bene l'uso che il programma fa della risorsa.
Usate Application.ProcessMessages con oculatezza e, se proprio non potete farne a meno, disabilitate gli eventi che possono generare "rientro" (ovvero richiamo della stessa procedura) o introducete il concetto di stato della risorsa (in altri termini se la risorsa è nello stato x non si può effettuare la operazione di nuovo).
Subscribe to:
Posts (Atom)