COMPONENTI DI UN AMBIENTE DI SVILUPPO

Transcript

1 Programmazione GUI PREMESSA Lo scopo di questa traccia di lavoro non è solo saper fare ma anche conoscere quindi prima di iniziare la parte operativa è opportuno definire un piccolo glossario di termini che aiutano la comprensione di quello che si sta facendo. AMBIENTE DI SVILUPPO L informatica ha una caratteristica unica nel campo della tecnologia: gli strumenti per realizzare un prodotto sono dello stesso tipo del prodotto stesso. Un ambiente di sviluppo (DE = Development Environment) è un insieme di programmi che consentono di costruire altri programmi. Per costruire un automobile ci vogliono strumenti specifici (presse, torni ecc ); provate ad immaginare di costruire un automobile con un'altra automobile. Invece in informatica lo strumento per costruire un nuovo programma è un insieme di altri programmi (editor, compilatore ). Ecco il perché di questo termine sviluppo che fa pensare che i programmi non nascano dal nulla ma da altri programmi precedentemente realizzati. Al limite si può pensare che per costruire una nuova versione di un ambiente di sviluppo si può utilizzare una versione precedente dell ambiente stesso! COMPONENTI DI UN AMBIENTE DI SVILUPPO I programmi che compongono l ambiente di sviluppo dipendono dalla tecnologia utilizzata. Gli elementi più comuni sono: Editor per generare i testi sorgente del programma Compilatore per tradurre il sorgente in codice nativo o intermedio Linker per unire le varie parti del programma in un unico eseguibile Debugger per verificare il corretto funzionamento del programma Librerie sono componenti di supporto alla programmazione già compilati Un tipico esempio di ambiente di sviluppo è il JDK (Java Development Kit) distribuito da Sun che è un insieme di programmi a linea di comando e di librerie che consentono di realizzare una applicazione Java. Un altro esempio di ambiente di sviluppo gcc (Gnu Compiler Collection) che consente di sviluppare programmi C e C++ in ambiente Linux AMBIENTE DI SVILUPPO IDE Un ambiente di sviluppo IDE (Integrated Development Environment) è un programma che integra al suo interno tutti i principali programmi necessari per lo sviluppo in un determinato ambiente. Il programma IDE in realtà non fa direttamente le operazioni, ma fa da cornice (Framework) lanciando i programmi che effettivamente sviluppano e che possono provenire da un altro DE in modo da dare allo sviluppatore una unica interfaccia di lavoro in genere di tipo GUI. Il vantaggio di un ambiente IDE consiste nella possibilità di disporre di automazioni che rendono semplice ed affidabile lo sviluppo guidando lo sviluppatore nei vari passi. Spesso un ambiente IDE è dedicato ad uno specifico ambiente di sviluppo ma in molti casi si sfrutta la sua caratteristica di essere una cornice indipendente dall ambiente di sviluppo vero e proprio per rendere disponibili anche altri ambienti diversi da quello principale. E questo il caso dei più famosi IDE per Java (NetBeans ed Eclipse) che oltre a Java possono essere configurati per lo sviluppo anche in molti altri ambienti (C/C++, PHP...). Anche Borland C++Builder nonostante sia apparentemente dedicato al C++ è in grado si sviluppare in altri ambienti come Assembler e Delphi (Pascal-like). In genere i principali valori aggiunti di un IDE rispetto ad un DE sono l editor sensibile al contesto e funzioni avanzate di debugger. ITIS O.Belluzzi Laboratorio di 1-13

2 AMBIENTE DI SVILUPPO RAD Un ambiente di sviluppo RAD (Rapid Application Development) è un ambiente IDE dotato di potenti automazioni che consentono una progettazione WYSIWYG dell interfaccia GUI di una applicazione. L utilizzo dell ambiente RAD è dunque confinato ad una particolare categoria di sviluppi:le applicazioni GUI. Si deve notare che non sono gli unici programmi che uno sviluppatore deve saper fare perché esistono anche le applicazioni a linea di comando, le librerie, i programmi server ecc. ecc. che non hanno interfaccia GUI e quindi in questo caso le risorse RAD non servono. Nella progettazione di una applicazione con una interfaccia GUI si può partire per lo sviluppo da una maschera (un mock-up) che descrive graficamente la struttura visuale della finestra. La programmazione RAD si basa su due principi che vanno ben compresi per muoversi efficacemente in un ambiente RAD: Programmazione orientata agli oggetti Programmazione basata sugli eventi PROGRAMMAZIONE ORIENTATA AGLI OGGETTI Le risorse grafiche che vengono utilizzate in un programma GUI sono in realtà funzioni gestite dal sistema operativo (API = Application Program Interface). Questo vuole dire che un programma applicativo non ha il compito di disegnare materialmente sulla scheda grafica l aspetto (rendering) degli elementi grafici che usa ma che deve invece chiamare delle funzioni parametriche di sistema operativo che si occupano di questo compito accedendo al dispositivo grafico. Questa unicità di azione spiega perché l aspetto dei componenti GUI è indipendente dalle applicazioni che li presentano. CLASSI DI COMPONENTI GRAFICI Spesso gli ambienti di sviluppo mascherano la chiamata a queste funzioni dello strato API del sistema operativo attraverso la disponibilità di classi da cui si possono ricavare oggetti che hanno un livello di astrazione superiore rispetto alle API. Ad esempio l ambiente JDK rende disponibili le librerie Swing mentre nell ambiente Builder sono disponibili le librerie VCL. Ogni libreria mette a disposizione una vasta gamma di classi che consentono di realizzare oggetti specializzati a partire dalla finestra per arrivare ai vari componenti utili nella composizione di una interfaccia GUI come caselle di testo, bottoni menu e così via. COMPONENTI WINDOWED Nonostante l apparente differenza tra gli oggetti sopra citati va tenuto presente che in realtà dal punto di vista del sistema operativo esiste un unico componente di tipo finestra e che tutti i componenti citati sono in realtà ottenuti per ereditarietà da una classe base che implementa una finestra modificandone i parametri di visualizzazione per ottenere l effetto richiesto. Quindi se è abbastanza intuitivo comprendere che una classe di tipo finestra di una libreria GUI corrisponde ad una API di sistema operativo che genera una finestra come la intendiamo normalmente in può sorprendere che una classe di tipo bottone corrisponde in realtà ancora una API di tipo finestra, specializzata in modo da avere l aspetto di un bottone. L oggetto di classe bottone viene aggregato come attributo all oggetto finestra dal punto di vista della programmazione OOP. Dal punto di vista della API di sistema operativo la finestra bottone diventa figlia della finestra vera. Componenti di questo tipo vengono detti windowed perché derivati da una finestra. ITIS O.Belluzzi Laboratorio di 2-13

3 COSTRUZIONE DI UNA INTERFACCIA GUI IN AMBIENTE IDE In un ambiente DE o IDE per realizzare una interfaccia GUI è quindi necessario che il programma principale dichiari degli oggetti di tipo grafico e poi che li istanzi inizializzandoli correttamente. Basandosi sui principi della ereditarietà e del polimorfismo quindi il punto di partenza è realizzare una nuova classe che erediti da una classe finestra e che aggreghi al suo interno come suoi attributi degli oggetti ottenuti dalle varie classi di componenti GUI ( caselle di testo, bottoni ) Questa nuova classe deve avere un costruttore che scavalca il costruttore di default della classe finestra perché al momento della costruzione deve instanziare ed inzializzare gli oggetti grafici che sono strati aggregati al suo interno. Il programma principale deve a sua volta instaziare un oggetto della classe finestra ; l esecuzione del costruttore, dopo avere inizializzato lo stato dell oggetto provvede all esecuzione dell API di sistema operativo che rende visibile la finestra sul monitor. FINESTRA COME RISORSA DI SISTEMA OPERATIVO C è da tenere presente che l API di sistema operativo non si limita a disegnare la finestra sul monitor ma genera anche una sua risorsa interna (un area di memoria contenente informazioni associate alla finestra e gestite direttamente dal sistema operativo). Queste risorsa, che esiste anche se la finestra diventa invisibile, la possiamo immaginare come una variabile di stato che rappresenta, istante per istante lo stato della finestra. La finestra è quindi posseduta dal sistema operativo e non dall applicazione che ne ha solo chiesto la creazione. E attraverso questa risorsa che avviene la comunicazione tra la finestra ( e i suoi componenti interni che non sono altro che sotto-finestre) e l applicazione. COSTRUZIONE DI UNA INTERFACCIA GUI IN AMBIENTE RAD Visto che lo scopo della progettazione della classe finestra, dei suoi componenti interni e della loro inizializzazione è di dare una presentazione grafica iniziale alla finestra in un ambiente RAD le operazioni sopra descritte invece che essere fatte scrivendo codice nei file sorgente vengono fatte con una tecnica WYSIWYG trascinando, posizionando e modificando i componenti nella finestra. Si deve notare che questa automazione va comunque a produrre codice nei file sorgenti esattamente nello stesso modo in cui verrebbe prodotto a mano in un ambiente solo IDE. E buona norma, in NetBeans è obbligatorio, non modificare a mano il codice generato automaticamente quindi alla fine nel codice sorgente ci troveremo parti di codice generate automaticamente mescolate a parti di codice generate da noi. Non sempre è possibile configurare i componenti usando una tecnica WISIWYG; ad esempio mentre è possibile cambiare la posizione di un bottone trascinandolo non è possibile cambiare il testo o il colore. Per questo motivo gli ambienti RAD dispongono di un pannello di servizio detto Object Inspector in Builder ( Properties in NetBeans) che mostra le proprietà dell oggetto selezionato e ne consente la modifica. A questo punto ci si aspetterebbe di trovare nel codice una miriade di inizializzazioni nel codice e invece non se ne trova traccia. Il motivo è che le caratteristiche degli oggetti inizializzati in modo RAD vengono raccolte in un file aggiuntivo di progetto (in genere in formato XML e con estensione.dfm in Builder e.frm in NetBeans). Questo file viene usato dal compilatore durante la generazione del codice (nativo o intermedio a seconda dei casi) facendo scomparire dal sorgente i dettagli dell inizializzazione. ITIS O.Belluzzi Laboratorio di 3-13

4 PROGRAMMAZIONE BASATA SUGLI EVENTI La progettazione GUI è sempre anche basata sugli eventi. Il motivo di questa architettura sta nell affermazione fatta precedentemente riguardo alle finestre: abbiamo visto che le finestre (principali o aggregate sotto forma di componenti) non sono possedute direttamente dall applicazione ma sono invece gestite dal sistema operativo. Immaginiamo che una applicazione utilizzi una finestra contenente un bottone e che al click del bottone debba fare una qualche azione, ad esempio scrivere un testo in una casella di testo. L evento di click sul bottone è responsabilità dell utente del programma e l utente può fare l evento quando vuole, o anche non farlo. In una prima visione superficiale quindi si potrebbe pensare che l applicazione che ha creato la finestra rimanga in esecuzione interrogando in continuazione lo stato del mouse per sapere se il bottone è stato clicckato. Se fosse veramente così l applicazione consumerebbe il 100% del tempo di CPU impedendo un corretto funzionamento del sistema. In realtà l applicazione invece non rimane in esecuzione in attesa dell arrivo del click ma viene posta in sospensione dallo schedulatore del sistema operativo lasciando la CPU libera per l esecuzione di altri processi. L evento di click non non può quindi essere ricevuto direttamente dall applicazione che è sospesa, ma dal sistema operativo che lo riceve attraverso un interrupt hardware. CODA DEI MESSAGGI Il sistema operativo associa ad ogni processo applicativo avviato una coda per la ricezione degli eventi che viene chiamata coda dei messaggi. Una coda è una struttura dati formata da più elementi dove gli elementi vengono sempre inseriti in fondo ed estratti dalla cima (disciplina FIFO=First In First Out). Quando si verifica un evento che deve essere comunicato ad una applicazione (ad esempio un click sull area di monitor occupata da una finestra in primo piano) il sistema operativo inserisce l informazione nella coda dell applicazione. Lo schedulatore, durante la sua attività di commutazione dei processi, analizza lo stato delle relative code e manda in esecuzione, uno alla volta solo i processi che hanno informazioni in coda in attesa di essere servite. In questo modo un processo con la coda vuota rimane in sospensione, mentre un processo con informazioni in coda entra prima o poi in esecuzione. LOOP DEI MESSAGGI La struttura del programma principale di una applicazione orientata agli eventi è a livello di pseudocodice la seguente: mentre (getmessage()) DispatchMessage() finementre La funzione getmessage() è una API di sistema operativo che estrae un dato dalla coda e che funziona nel seguente modo: Se c è un messaggio in coda lo estrae e restituisce true in modo da entrare nel loop ed eseguire la gestione finestra (DispatchMessage()) Se il messaggio è un QUIT (chiusura della finestra) restituisce un false provocando l uscita dal loop e quindi la terminazione del programma. Se la coda è vuota provoca la sospensione del programma che tornerà in esecuzione completando la getmessage() solo quando la coda non sarà più vuota. GESTIONE DEL MESSAGGIO Il messaggio ricevuto oltre ad identificare il motivo dell evento indica anche il destinatario che può essere la finestra principale o un qualsiasi componente contenuto nella finestra principale. Ad ogni componente è associato un oggetto nel programma; questo oggetto ha vari attributi che lo definiscono e tra questi ci sono alcuni attributi che vengono definiti proprietà-evento ; si tratta di informazione di tipo puntatore (o reference) perché l informazione contenuta nell attributo è l indirizzo di un metodo che svolge il compito associato all evento. ITIS O.Belluzzi Laboratorio di 4-13

5 Questi attributi esistono sempre per tutti i componenti ma per default contengono l informazione null quindi non viene eseguita alcuna operazione. Lo sviluppatore può realizzare un metodo che svolga il compito applicativo richiesto ed inserire il suo riferimento (materialmente il suo indirizzo) nella proprietà evento di un componente mediante l object inspector (properties in NetBeans). In questo modo quando il sistema operativo cattura un evento lo inserisce nella coda dell applicazione che lo deve ricevere che prima o poi verrà risvegliata dallo schedulatore; quando l applicazione estrae l informazione dalla coda e la smista al componente destinatario che esegue il metodo associato nella corrispondente proprietà-evento. I metodi evento (ev.proc) vengono definiti HANDLER (manipolatore) in ambiente Builder e LISTENER (ascoltatore) in ambiente NetBeans ma il significato è lo stesso. Si tratta di metodi della classe derivata dalla classe finestra che vengono definiti dallo sviluppatore. Questi metodi però non vengono chiamati da altri metodi del programma in modo sincrono. Il loro riferimento (o indirizzo della prima istruzione) viene inserito come valore di un attributo in un oggetto aggregato alla finestra; quando il sistema operativo riconosce il verificarsi di un evento. ITIS O.Belluzzi Laboratorio di 5-13

6 STRUTTURA DELL AMBIENTE BUILDER L ambiente Builder è costituito da una piccola finestra che contiene i menu, i bottoni di scelta rapida e le tavolozze dei componenti di libreria. Menu Bottoni di scelta rapida Tavolozze dei componenti Le varie attività di sviluppo svolte nell ambiente possono determinare l apertura di ulteriori finestre che sono indipendenti dalla finestra principale. Object Inspector Class Inspector Source Editor Watches WYSIWYG editor Le finestre di uso più comune sono: Object Inspector: consente di vedere e modificare i valori di inizializzazione degli attributi dell oggetto visuale selezionato ne WYSIWYG editor. I valori impostati in questo pannello vengono usati per la generazione del file XML di form (DFM o FRM) Class Inspector: consente di vedere la struttura delle classi che sono utilizzate nel progetto. Source Editor: è un editor di testo che consente di leggere, scrivere e modificare i files sorgente. E dotato del controllo di sintassi mediante i colori e dell aiuto contestuale. WYSIWYG editor: è un editor grafico che consente di costruire una maschera delle finestre GUI dell applicazione trascinando i componenti GUI dalla tavolozza nella finestra. L inserimento di un componente nella finestra determina la sua dichiarazione ed instanziazione nel codice sorgente e la sua definizione nel file XML di form. Watches: consente di esplorare il contenuto delle variabili durante di debug. ITIS O.Belluzzi Laboratorio di 6-13

7 COSTRUZIONE DI UNA APPLICAZIONE GUI Per costruire una nuova applicazione GUI in ambiente Builder si utilizza la voce di menu: File New Application Poiché una applicazione GUI deve avere almeno una finestra si aprono le finestre di Source Editor, Class Inspector e WYSIWYG editor contenenti rispettivamente il file sorgente della finestra principale, la struttura della classe finestra principale e la form della finestra principale che al default è identificata dall identificatore Form1. SALVATAGGIO DEI FILE DI PROGETTO E buona norma salvare sempre il progetto appena creato. Nei computer dei laboratori il salvataggio deve avvenire nel disco D: Il salvataggio del progetto si realizza con la voce di menu File Save Project As... Si apre una finestra di dialogo che consente di scegliere il percorso di salvataggio e realizza un salvataggio multiplo. Per ogni file salvato viene offerta la possibilità di cambiare il nome di default. Elenco dei files salvati: File sorgente della finestra principale (nome di default Unit1.cpp) File header della finestra principale (stesso nome del sorgente con estensione.h) File form della finestra principale (stesso nome del sorgente con estensione.dfm) File di progetto del programma (nome di default Project1.bpr ) File sorgente del programma principale (nome del progetto con estensione.cpp) File di risorse del progetto (stesso nome del progetto con estensione.res) Questi sono i files che si devono salvare per poter rigenerare o modificare il progetto. FILE SORGENTE DEL PROGRAMMA PRINCIPALE Mentre l ambiente Java è un OOP puro l ambiente C++ è un ambiente misto funzionale+oop. In ambiente Java il programma principale è rappresentato da una classe che contiene un metodo statico di nome main() che viene eseguito dalla macchina virtuale all avvio del programma. In ambiente C++ invece il programma principale è una funzione che viene chiamata dal sistema operativo all avvio del programma. Si accede al sorgente del programma principale mediante il menu: Project View Source E raro dover modificare il codice del programma principale ma è utile conoscere la struttura per comprendere meglio il funzionamento di una applicazione GUI. La struttura tipica di un programma principale, automaticamente generata dall ambiente RAD, è la seguente: WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int) { try { Application->Initialize(); Application->CreateForm( classid(tform1), &Form1); Application->Run(); } catch (Exception &exception) { Application->ShowException(&exception); } return 0; } L ambiente di run-time di Borland costruisce un oggetto Application di classe TApplication che rappresenta una istanza della applicazione in corso di esecuzione. Il metodo Initialize() provvede all inizializzazione dei componenti dell applicazione come ad esempio la coda dei messaggi per il collegamento con il sistema operativo. Il metodo CreateForm istanzia un oggetto derivato dal tipo finestra ottenendolo dalla classe TForm1 (è la classe definita nell header della finestra principale) e ne assegna il riferimento alla variabile Form1 ITIS O.Belluzzi Laboratorio di 7-13

8 Il metodo Run attiva l esecuzione del loop dei messaggi in modo che il processo si porti in sospensione quando la coda è vuota ed esegua i metodi agganciati alla finestra quando ci sono messaggi in coda per il processo. In pratica tutta l elaborazione del processo viene svolta all interno del metodo Run dal quale si esce solo chiudendo il programma. I più curiosi si possono accertare di questa situazione in debug mettendo un breakpoint in corrispondenza di questo metodo. Lanciando il programma si arriva immediatamente al breakpoint. Se a questo punto si esegue uno Step Over (F8) parte l esecuzione del programma e si arriva al breakpoint solo chiudendo l applicazione con la crocetta. Chi è ancora più curioso può, una volta arrivato al breakpoint aprire la finestra CPU e tracciare con un Trace Into (F7) in modo da entrare nel metodo Run; a questo punto procedendo con lo Step Over si individua dopo una complessa inizializzazione il loop dei messaggi. COSTRUZIONE DELLA FINESTRA PRINCIPALE Prima di analizzare il contenuto dei files relativi alla finestra principale conviene popolare la form mediante l editor WYSIWYG con alcuni componenti. Ad esempio si può selezionare dalla tavolozza dei componenti la casella di testo (Edit) e fare click in una qualsiasi posizione sull area della finestra; si disegna una casella di testo sulla finestra; la casella può successivamente essere spostata e ridimensionata per trascinamento. Allo stesso modo si può inserire nella finestra un bottone (Button). FILE HEADER DELLA FINESTRA PRINCIPALE Il file header della finestra principale (al default Form1.h) contiene la definizione della classe della finestra principale ottenuta per ereditarietà da una classe della libreria VCL che si chiama TForm. Per aprire il file header si deve avere il file sorgente già aperto nel source editor; si fa click con il bottone destro sull area del source editor e si sceglie dal menu contestuale la voce Open Source/header file. Se il file sorgente è stato chiuso inavvertitamente si può riaprire dal menu View Units. Il file header contiene la definizione della classe formata dalla dichiarazione degli attributi e dai prototipi dei metodi ma non contiene il codice dei metodi che è nel file sorgente. Da questo punto di vista il C++ si differenzia dal Java che invece nella definizione della classe non inserisce solo le firme dei metodi ma l intero codice. #include <Classes.hpp> #include <Controls.hpp> #include <StdCtrls.hpp> #include <Forms.hpp> class TForm1 : public TForm { published: // IDE-managed Components TEdit *Edit1; TButton *Button1; private: // User declarations public: // User declarations fastcall TForm1(TComponent* Owner); }; Le direttive di inclusione consentono a questo header di utilizzare le definizioni contenute in ulteriori header consentendo quindi l utilizzo di classi di libreria. ITIS O.Belluzzi Laboratorio di 8-13

9 La classe che viene definita si chiama TForm1 ed eredita (parola chiave public che corrisponde al Java extends) dalla classe TForm che descrive nella libreria VCL una finestra vuota. La struttura della classe è divisa in tre sezioni: published: attributi e metodi generati automaticamente dall ambiente RAD; gli attributi che si trovano in questa sezione visualizzati nella finestra dell editor WYSIWYG e vengono gestiti dall object inspector consentendo una configurazione visuale. E raccomandabile non modificare questa parte private: attributi e metodi privati della classe; possono essere generati dallo sviluppatore e sono accessibili solo dall interno della classe public: attributi e metodi pubblici della classe; possono essere generati dallo sviluppatore e sono accessibili dall esterno della classe. Avendo già trascinato i due componenti nella finestra nella sezione published sono presenti due attributi che rappresentano i riferimenti ai due componenti. In ambiente C++, diversamente dall ambiente Java, i puntatori sono gestiti esplicitamente quindi una variabile di tipo riferimento va dichiarata in modo diverso da una variabile che non sia un riferimento. Per questo motivo la variabile che si riferisce alla casella di testo è realizzata da: TEdit *Edit1; Si tratta di una dichiarazione con l usuale struttura <tipo> <identificatore> dove il <tipo> indica una classe della libreria VCL che si chiama TEdit che realizza una finestra sotto forma di casella di testo; l identificatore è Edit1 ma Edit1 non rappresenta l area di memoria che contiene l oggetto ma invece l area di memoria che contiene il riferimento (puntatore) all oggetto; questa situazione in C++ deve essere messa in evidenza con l operatore asterisco (*) che trasforma la dichiarazione in questo modo: Edit1 è una variabile che contiene il puntatore ad un oggetto di tipo TEdit La reference a questi due oggetti dovrebbe essere generata, come in Java, con un operatore new di cui non si trova traccia nel sorgente. Il motivo è che questa istanziazione è nascosta dentro al metodo CreateForm del programma principale. L ultima riga della classe è il prototipo del costruttore; il codice del costrutte si trova nel file sorgente. FILE SORGENTE DELLA FINESTRA PRINCIPALE Il file sorgente della finestra principale (al default Form1.cpp) la dichiarazione dell oggetto finestra ed il codice dei metodi della classe. E questo il file dove opera normalmente lo sviluppatore creando nuovi metodi con tecniche manuali o automatiche ed inserendo codice nei metodi. Dopo la popolazione della finestra il codice del file sorgente si presenta così: #include <vcl.h> #include "Unit1.h" TForm1 *Form1; fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { } L inclusione dell header di sistema vcl.h consente di utilizzare le classi di libreria VCL. L inclusione dell header applicativo Unit1.h consente di utilizzare la classe TForm1. La dichiarazione definisce la variabile puntatore all oggetto Form1 che viene istanziato all interno del metodo CreateForm() del programma principale. Seguono i metodi della classe; al momento esiste il solo metodo costruttore TForm1: la parola chiave fastcall indica al compilatore che deve usare una tecnica di ottimizzazione del codice macchina; si tratta di cose che ovviamente non possono esistere in Java che non ha accesso alla macchina fisica. L operatore :: individua l appartenenza di un metodo ad una classe con la sintassi <classe>::<metodo>. Questa tecnica si rende necessaria perché in C++ all interno della definizione di classe si trovano solo i prototipi dei metodi e non l intero codice che si trova in un altro file. Ogni volta che si scrive un metodo è quindi necessario ITIS O.Belluzzi Laboratorio di 9-13

10 specificare a quale classe appartiene. In questo caso quindi TForm1::TForm1( ) vuole dire metodo TForm1 (cioè il costruttore) della classe TForm1. L argomento di ingresso del costruttore è il riferimento al oggetto che è proprietario della finestra (TComponent* Owner) e i questo caso è l oggetto Application cje viene passato al momento della istanziazione nel metodo CreateForm. La classe TForm1 eredita dalla classe TForm quindi in costruttore deve a sua volta invocare il costruttore della classe superiore. Questa operazione è fatta dall operatore duepunti che precede il costruttore di TForm; quindi :TForm(Owner) in sostanza corrisponde al costruttore super() di Java. Al momento il costruttore è vuoto e quindi non aggiunge nulla alla costruzione di default. FILE FORM DELLA FINESTRA PRINCIPALE Il file form della finestra principale (.DFM) contiene le informazioni sulla finestra generate dall editor WYSIWYG e dall object inspector. Si tratta di un file di testo che contiene in forma strutturata le definizioni dell aspetto grafico. E possibile vedere la struttura testuale di questo file facendo click con il bottone destro sulla finestra e selezionando dal menu contestuale la voce View as text. Nel caso in esempio si ottiene un testo di questo tipo: object Form1: TForm1 Left = 456 Top = 191 Width = 289 Height = 102 Caption = 'Form1' Color = clbtnface Font.Charset = DEFAULT_CHARSET Font.Color = clwindowtext Font.Height = -11 Font.Name = 'MS Sans Serif' Font.Style = [] OldCreateOrder = False PixelsPerInch = 96 TextHeight = 13 object Edit1: TEdit Left = 16 Top = 16 Width = 121 Height = 21 TabOrder = 0 Text = 'Edit1' end object Button1: TButton Left = 152 Top = 16 Width = 75 Height = 25 Caption = 'Button1' TabOrder = 1 OnClick = Button1Click end end Per tornare al modo visuale selezionare dal menu contestuale la voce view as Form. ITIS O.Belluzzi Laboratorio di 10-13

11 USO DELL OBJECT INSPECTOR L object inspector consente la modifica degli attribute degli oggetti published cioè degli oggetti che sono stati inseriti in modo RAD. Si tratta di una finestra sensibile al contesto che modifica il suo contenuto in base all oggetto selezionato nella finestra visuale. Facendo click su un componente della finestra visuale questo componente viene selezionato; ai suoi margini compaiono dei quadratini neri che rappresentano le maniglie di ancoraggio per il ridimensionamento, è possibile trascinarlo e le sue proprietà compaiono nella finestra dell object inspector. PROPRIETA SELEZIONATO E quindi possibile cambiare ad esempio l altezza del bottone sia trascinando una maniglia di ancoraggio (in questo caso si vedra anche cambiare la proprietà Height dell object inspector) oppure si può cambiare il valore di Height nella casella dell object inspector (in questo caso si vedra cambiare l altezza del bottone nella finestra. Si può anche cambiare l altezza del bottone proceduralmente nel costruttore della finestra assegnando un valore alla proprietà Height ma in questo caso l effetto si vede solo al momento dell esecuzione: fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { Button1->Height=50; } Vale la pena di notare alcune differenze rispetto a Java: Poiché C++ distingue le variabili accedute direttamente da quelle accedute per riferimento anche l operatore di accesso a proprietà e metodi è differenziato ed è l operatore punto (.) per le variabili ad accesso diretto e l operatore freccia (->) per le varibili accedute tramite un puntatore. Mentre in Java le proprietà sono in genere private e l accesso è possibile sono con metodi lettori (getter) o scrittori (setter) in C++ le proprietà sono in genere pubbliche e possono essere lette e scritte direttamente. Alcune proprietà possono essere modificate solo attraverso l object inspector come ad esempio è il caso della Caption del bottone. Gli oggetti non published non sono accessibili dall object inspector anche se sono componenti visuali e quindi possono essere inizializzati o modificati solo proceduralmente. ITIS O.Belluzzi Laboratorio di 11-13

12 PROPRIETÀ-EVENTO Le proprietà-evento sono attributi predefiniti dei componenti visuali che possono essere configurate dallo sviluppatore in modo che facciano riferimento a metodi progettati dallo sviluppatore. Esiste una proprietà-evento per ogni possibile evento che un componente può ricevere dal sistema operativo. Questi metodi vengono eseguiti in modo asincrono; cioè non sono chiamati dal programma stesso ma dal sistema operativo. Il caso più semplice è sicuramente il click su un bottone. Quando un bottone è visualizzato sullo schermo in primo piano il click del mouse sull area del bottone produce un interrupt hardware che viene intercettato dal sistema operativo. Il sistema operativo ottiene anche le coordinate del click ed in base ad esse individua quale finestra principale è interessata al click e di conseguenza anche quale processo applicativo in esecuzione. Il sistema operativo accoda nella coda dei messaggi l informazione sul click individuando anche quale eventuale sotto-finestra (il bottone) deve riceve l evento. Quando nell ambito della schedulazione il processo interessato ritorna in esecuzione spilla il messaggio della coda e lo inoltra al componente destinatario. Il componente destinatario esegue il metodo il cui riferimento è contenuto nella proprietàevento corrispondente all evento. Se non è stata configurato alcun metodo il componente non fa nulla. Esiste un ampio elenco di proprietà-evento configurabili. Per configurare una proprietà evento si passa sul pannello events dell object inspector e si fa doppio click sull area bianca dell evento che si vuole configurare. Nel file sorgente della finestra che contiene il bottone si crea un metodo vuoto che viene eseguito quando il bottone riceve l evento click. Nel file header, all interno della classe TForm1, nella sezione published viene aggiunto il prototipo del nuovo metodo. Lo sviluppatore può inserire codice nel metodo in modo da legare queste azioni al evento configurato. Ad esempio in questo esercizio si potrebbe inserire l istruzione: Edit1->Text= hai fatto click ; In modo da fare comparire questo messaggio nella casella di testo quando si fa click sul bottone. ITIS O.Belluzzi Laboratorio di 12-13

13 DISTRIBUZIONE DELLE APPLICAZIONI I collaudi si fanno nell ambiente di debug dell IDE ma al termine dello sviluppo è necessario distribuire l applicazione. La distribuzione delle applicazioni è un problema molto complesso che va al di là di questo studio e che riprenderemo in un secondo tempo. Per il momento verifichiamo la possibilità di rendere distribuibili solo le semplici applicazioni di base. Le applicazioni prodotte in ambiente Builder non sono indipendenti dalla piattaforma come quelle Java e quindi deve in primo luogo essere ben chiaro su che piattaforma possono essere eseguite. Si tratta di applicazioni grafiche per la piattaforma Windows 32 bit. L esecuzione del menu Project Build porta alla creazione del file Project1.exe che può essere eseguito direttamente dall interfaccia GUI del sistema operativo. In realtà questo eseguibile fa affidamento per funzionare su un certo numero di librerie dinamiche di runtime che sono sicuramente presenti nel computer destinato allo sviluppo perché sono installate insieme all ambiente di sviluppo mentre potrebbero non essere presenti nel computer di destinazione. Si può dedurre l esigenza di componenti di supporto dalle piccole dimensioni dell eseguibile (dell ordine di 20KB nell esempio) In questa versione di distribuzione senza entrare nel merito di una vera e propria procedura di installazione che distribuisca ed installi anche i componenti di supporto creiamo una distribuzione che incorpora nell eseguibile tutti i componenti di supporto necessari. Questa operazione non è sempre possibile ma ha successo in alcuni semplici casi. Si modificano le seguenti configurazioni: Project Options Packages Build with runtime packages: togliere la spunta Project Options Linker Linking Use RTL Library : togliere la spunta Per ottenere il nuovo eseguibile si deve rieseguire un Project Build A questo punto l eseguibile dovrebbe avere raggiunto dimensioni ragguardevoli (dell ordine di 300KB nell esempio) segnalando il fatto che i componenti di supporto sono stati inclusi nell eseguibile. Il test finale consiste nel copiare l eseguibile su un computer Windows 32 bit sicuramente privo dell ambiente di sviluppo Borland e controllare che l esecuzione avvenga senza errori. ITIS O.Belluzzi Laboratorio di 13-13