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
Sunday, May 06, 2007
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)