Documentazione per il corso:

“Sviluppo Applicazioni in ambiente Windows con

Microsoft Visual C++ 6.0”
Autore: David Bandinelli

Revisione: 1.1 (23/10/2002)

Bibliografia:
“Programming Windows with MFC” di J. Prosise
“Programming Windows” di C. Petzold
Microsoft MSDN Library

Parte 1 : Dall’SDK ad MFC

Introduzione alla programmazione in ambiente Windows

Fino a pochi anni fa l’unica possibilita’ per sviluppare applicazioni in ambiente Windows
di una certa complessita’, era quella di utilizzare il linguaggio C e l’SDK (Software
Development Kit).
In pratica l’SDK di Windows era formato da una immensa collezione di API (Application
Program Interface) che potevano essere richiamate all’interno di un programma C e che
permettevano di realizzare applicazioni grafiche a prezzo pero’ di una notevole
complessita’ e di una vasta gamma di conoscenze necessarie al programmatore per
scrivere anche il piu’ banale programma.
Successivamente, l’avvento del Visual Basic ha permesso a tutti di poter sviluppare
applicazioni Windows in maniera sicuramente piu’ veloce e piu’ facile, senza la
necessita’ di dover acquisire l’enorme bagaglio di conoscenze necessario per
programmare con l’SDK.
Fino alla versione 6.0 comunque il Visual Basic e’ rimasto un linguaggio semi-
interpretato e quindi per applicazioni di una certa importanza, dove le prestazioni sono un
fattore critico, non rappresentava certo la scelta ideale.
Per rispondere a questa esigenza di uno strumento piu’ performante e piu’ sicuro del
Visual Basic ma che fosse piu’ semplice da utilizzare dell’SDK e soprattutto fosse in
linea con i moderni concetti della programmazione Object Oriented, lo sviluppo in
ambiente Windows si e’ orientato verso il linguaggio C++ utilizzato congiuntamente alla
libreria di classi MFC.
Resta il fatto che la programmazione in ambiente Windows e’ notevolmente piu’
complessa di quella tradizionale, soprattutto a causa della complessa interfaccia utente, e
quindi richiede un approccio sostanzialmente diverso da parte del programmatore.

1
In generale i normali programmi per ambienti tradizionali utilizzano una logica
procedurale, ovvero l’esecuzione del programma parte da un main e continua a seconda
del flusso dell’applicazione (cicli, chiamate a funzione, istruzioni if-then-else ecc.).
Le applicazioni Windows operano in maniera diversa, ovvero utilizzano un modello di
programmazione chiamato “event driven”; che consiste nel gestire la reazione del
programma di fronte ad eventi (es. la pressione del pulsante del mouse o la chiusura di
una finestra) che vengono segnalati all’applicazione tramite messaggi inviati dal sistema
operativo.
In sostanza un’applicazione Windows non ha un vero e proprio main, ma si limita ad
aprire una o piu’ finestre e a posizionarsi in un ciclo di attesa (loop dei messaggi),
aspettando che il sistema operativo invii messaggi all’applicazione in risposta ai vari
eventi che si possono verificare durante l’esecuzione del programma.
I messaggi in arrivo diretti ad una applicazione vengono accodati in attesa
dell’elaborazione e solitamente si continua l’esecuzione in questo modo fino all’arrivo di
un messaggio di richiesta di terminazione del programma (WM_QUIT), che solitamente
viene inviato quando l’utente preme il tasto ‘x’ su di una finestra, oppure seleziona la
voce ‘Esci’ dalla barra dei menu.
La complessita’ di sviluppo delle applicazioni Windows deriva pertanto dalla necessita’
di prevedere in fase di progetto tutti i possibili messaggi che dovranno essere gestiti e che
quindi richiederanno la scrittura di una routine di gestione apposita.
La libreria MFC semplifica questo processo prendendosi carico di gestire al suo interno
gran parte dei messaggi che l’applicazione riceve e lasciando quindi al programmatore
solo la scrittura della logica del programma.

Programmare con l’SDK

Prima di arrivare a trattare le classi MFC e quindi la programmazione Windows in
linguaggio C++ e’ istruttivo esaminare un semplice programma scritto in C tramite
l’SDK per capire meglio la struttura ed il funzionamento delle applicazioni in ambiente
Windows e la notevole differenza dalle applicazioni tradizionali.

Il seguente listato puo’ essere generato dallo Wizard di Visual Studio 6.0 selezionando
File->New e scegliendo un nuovo progetto di tipo Win32Application.
Nella finestra del wizard selezionare “Hello World Application” per generare
automaticamente il codice di una semplice applicazione Windows-SDK che stampa un
messaggio a video ed e’ dotata di un piccolo menu e di una finestra di informazioni.

2
(listato 2_1_1)
#include "stdafx.h"
#include "resource.h"

#define MAX_LOADSTRING 100

// Variabili globali: istanza, titolo della finestra

// principale e nome dell’applicazione
HINSTANCE hInst;
TCHAR szTitle[MAX_LOADSTRING];
TCHAR szWindowClass[MAX_LOADSTRING];

// Prototipo delle funzioni utilizzate

ATOM MyRegisterClass(HINSTANCE hInstance);
BOOL InitInstance(HINSTANCE, int);
LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);
LRESULT CALLBACK About(HWND, UINT, WPARAM, LPARAM);

// Questa e’ la funzione main delle applicazioni Windows

int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
// variabile di tipo messaggio
MSG msg;

// Inizializzazione stringhe globali

LoadString(hInstance, IDS_APP_TITLE, szTitle,
MAX_LOADSTRING);
LoadString(hInstance, IDC_TESTSDK, szWindowClass,
MAX_LOADSTRING);

// Si registrano le caratteristiche principali

// dell’applicazione
MyRegisterClass(hInstance);

// Inizializzazione dell’applicazione
if (!InitInstance (hInstance, nCmdShow))
{
return FALSE;
}

3
 // LOOP dei messaggi
while (GetMessage(&msg, NULL, 0, 0))
{
// I messaggi vengono estratti dalla coda
// e passati alla funzione di callback
TranslateMessage(&msg);
DispatchMessage(&msg);
}

return msg.wParam;
}

ATOM MyRegisterClass(HINSTANCE hInstance)

{
WNDCLASSEX wcex;

// si definiscono le caratteristiche dell’applicazione

// come icone, stile della finestra principale, colori
// font, menu ecc.
wcex.cbSize = sizeof(WNDCLASSEX);
wcex.style = CS_HREDRAW | CS_VREDRAW;
wcex.lpfnWndProc = (WNDPROC)WndProc;
wcex.cbClsExtra = 0;
wcex.cbWndExtra = 0;
wcex.hInstance = hInstance;
wcex.hIcon = LoadIcon(hInstance,
(LPCTSTR)IDI_TESTSDK);
wcex.hCursor = LoadCursor(NULL, IDC_ARROW);
wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
wcex.lpszMenuName = (LPCSTR)IDC_TESTSDK;
wcex.lpszClassName = szWindowClass;
wcex.hIconSm = LoadIcon(wcex.hInstance,
(LPCTSTR)IDI_SMALL);

return RegisterClassEx(&wcex);
}

// La finestra principale dell’applicazione viene

// visualizzata
BOOL InitInstance(HINSTANCE hInstance, int nCmdShow)
{
HWND hWnd;

hInst = hInstance;

// Questa funzione crea la finestra principale

4
 // dell’applicazione
hWnd = CreateWindow(szWindowClass, szTitle,
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL,
hInstance, NULL);

if (!hWnd)
{
return FALSE;
}

// La finestra viene finalmente visualizzata

ShowWindow(hWnd, nCmdShow);
UpdateWindow(hWnd);

return TRUE;
}

// Questa e’ la funzione detta di callback che gestisce I

// messaggi ricevuti dall’applicazione
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM
wParam, LPARAM lParam)
{
int wmId, wmEvent;
PAINTSTRUCT ps;
HDC hdc;
TCHAR szHello[MAX_LOADSTRING];
LoadString(hInst, IDS_DAVID, szHello, MAX_LOADSTRING);

switch (message)
{
case WM_COMMAND:
wmId = LOWORD(wParam);
wmEvent = HIWORD(wParam);
// Gestisce la selezione di una voce dal
// menu:
switch (wmId)
{
case IDM_ABOUT:
DialogBox(hInst,
(LPCTSTR)IDD_ABOUTBOX, hWnd,
(DLGPROC)About);
break;
case IDM_EXIT:
DestroyWindow(hWnd);
break;
default:

5
 return DefWindowProc(hWnd, message,
wParam, lParam);
}
break;
case WM_PAINT:
hdc = BeginPaint(hWnd, &ps);
RECT rt;
GetClientRect(hWnd, &rt);
// Visualizza il messaggio nella finestra
DrawText(hdc, szHello, strlen(szHello), &rt,
DT_CENTER);
EndPaint(hWnd, &ps);
break;
case WM_DESTROY:
// si e’ ricevuto il messaggio di uscita
PostQuitMessage(0);
break;
default:
// I messaggi non gestiti vengono passati
// alla funzione di default
return DefWindowProc(hWnd, message, wParam,
lParam);
}
return 0;
}

// La dialog box di informazioni ha il suo gestore di

// messaggi
LRESULT CALLBACK About(HWND hDlg, UINT message, WPARAM
wParam, LPARAM lParam)
{
switch (message)
{
case WM_INITDIALOG:
return TRUE;

case WM_COMMAND:
if (LOWORD(wParam) == IDOK || LOWORD(wParam)
== IDCANCEL)
{
EndDialog(hDlg, LOWORD(wParam));
return TRUE;
}
break;
}
return FALSE;
}

6
Il cuore di una applicazione Windows SDK e’ la funzione WinMain; al suo interno viene
richiamata RegisterClass per registrare la finestra principale dell’applicazione (la
registrazione consiste nel definire alcune importanti caratteristiche di una finestra come
l’indirizzo della routine di gestione dei messaggi, la presenza di icone e menu, i colori di
sfondo ecc.).
Una volta registrata la finestra dell’applicazione e’ possibile creare fisicamente la finestra
tramite la funzione CreateWindow che permette anche di definirne lo stile (posizione,
dimensione, presenza di scrollbar laterali e/o orizzontali ecc.).
La finestra, una volta creata, non e’ visibile fino a che non vengono chiamate le funzioni
ShowWindow e UpdateWindow.
Successivamente l’applicazione inizia il cosiddetto loop dei messaggi, ovvero si effettua
un ciclo while che chiama le funzioni GetMessage, TranslateMessage e
DispatchMessage le quali rispettivamente esaminano la coda dei messaggi e, se un
nuovo messaggio e’ presente, lo interpretano e lo inviano alla corrispondente funzione di
gestione (message handler).
Nel nostro esempio la funzione di gestione dei messaggi e’ la CALLBACK WndProc
che si occupa di implementare la reazione dell’applicazione ad ognuno dei messaggi
riconosciuti.
Ad esempio, in risposta al messaggio WM_PAINT (che viene inviato tutte le volte che
e’ necessario ridisegnare la finestra), la funzione WndProc provvede a visualizzare il
messaggio a video.
La funzione WndProc viene definita funzione di callback perche’ non viene chiamata
esplicitamente dal programma ma e’ chiamata direttamente dal loop dei messaggi ogni
volta che se ne presenti la necessita’ (ovvero e’ arrivato un nuovo messaggio).
I messaggi non gestiti direttamente dall’applicazione vengono passati alla funzione
DefWindowProc per segnalare al sistema operativo che il messaggio non viene gestito e
che quindi e’ sufficiente un trattamento di default da parte di Windows.
Il gestore del messaggio WM_DESTROY richiama la funzione PostQuitMessage per
inviare un messaggio WM_QUIT alla coda dei messaggi e causare in questo modo la
corretta terminazione dell’applicazione.
Il messaggio WM_DESTROY viene inviato ad una applicazione immediatamente prima
della chiusura della finestra principale ed e’ a cura del programmatore inviare il
messaggio WM_QUIT altrimenti l’applicazione non potrebbe terminare correttamente.

7
Introduzione a MFC
Lo scopo primario di MFC (Microsoft Foundation Classes) e’ quello di incapsulare
all’interno di classi (piu’ di 200 nella versione 6.0) le API di Windows e di fornire inoltre
un ambiente di programmazione Windows ad oggetti che aiuti il programmatore nel
complesso meccanismo di sviluppo delle applicazioni dotate di interfaccia grafica.
Le classi MFC forniscono un architettura di sviluppo che semplifica la gestione dei
compiti piu’ ripetitivi di ogni applicazione Windows come la gestione dei messaggi, ed
offre inoltre alcuni potenti strumenti per separare l’implementazione dei dati di un
programma dalla sua rappresentazione grafica raggiungendo un livello di astrazione
sensibilmente maggiore rispetto all’SDK (Architettura Document/View).
E’ da considerare inoltre che l’utilizzo di MFC e del linguaggio C++ aggiunge alle
applicazioni Windows tutti i benefici derivanti dalle tecniche OO come l’incapsulamento,
l’ereditarieta’ e le funzioni virtuali.
E’ possibile infatti ereditare da una qualsiasi classe MFC e creare in poco tempo potenti
elementi di interfaccia personalizzati ed avvalersi inoltre della libreria di template e
container messi a disposizione del programmatore da STL.

La prima applicazione MFC in dettaglio

Analizziamo adesso in dettaglio la struttura di una applicazione MFC tramite l’analisi di
un semplice esempio che stampa al centro di una finestra il messaggio “Hello World!”.
Sebbene sia possibile utilizzare il wizard di Visual Studio per generare interamente lo
scheletro di una applicazione MFC e’ utile scrivere tale programma senza l’ausilio
dell’ambiente di sviluppo per prendere familiarita’ con l’architettura.
Per creare un nuovo progetto MFC senza utilizzare il Wizard e’ necessario:

- Selezionare File -> New e scegliere un nuovo progetto di tipo “Win32

Application”
- Indicare che si vuole creare un progetto vuoto scegliendo “Empty Project”
- Selezionare Project -> Settings ed indicare l’opzione “Use MFC in a shared
DLL” per comunicare al compilatore che si vuole linkare dinamicamente la
libreria MFC all’eseguibile

A questo punto e’ possibile aggiungere un nuovo file .CPP o .H (in alternativa .HPP) ed
iniziare a scrivere il codice.

8
(listato 2_1_2)
(Hello.h)
// classe principale applicazione MFC
class CMyApp : public CWinApp
{
public:
// il metodo InitInstance deve essere
// implementato in CMyApp
virtual BOOL InitInstance ();
};

// classe per la finestra dell’applicazione

class CMainWindow : public CFrameWnd
{
public:
// metodo per la creazione della finestra
// principale (e’ anche il costruttore!)
CMainWindow ();

protected:
// dichiarazione della mappa dei messaggi
// e delle funzioni di gestione dei msg
afx_msg void OnPaint ();
DECLARE_MESSAGE_MAP ()
};

(Hello.cpp)
// MFC richiede l’include di afxwin.h
#include <afxwin.h>
#include "Hello.h"

// Istanziamo un oggetto di tipo applicazione MFC

CMyApp myApp;

// Override del metodo InitInstance

BOOL CMyApp::InitInstance ()
{
m_pMainWnd = new CMainWindow;
m_pMainWnd->ShowWindow (m_nCmdShow);
m_pMainWnd->UpdateWindow ();
return TRUE;
}

9
// mappa dei messaggi gestiti dall’applicazione
BEGIN_MESSAGE_MAP (CMainWindow, CFrameWnd)
ON_WM_PAINT ()
END_MESSAGE_MAP ()

// override della funzione di creazione della

// finestra principale necessaria per modificare
// il titolo (il costruttore della classe CmainWindow
// provvede a creare la finestra)
CMainWindow::CMainWindow ()
{
Create (NULL, "La mia prima applicazione MFC");
}

// gestione dell’evento (messaggio) WM_PAINT

void CMainWindow::OnPaint ()
{
// istanziamo un “device context”
CPaintDC dc (this);

// istanziamo una client area

CRect rect;
GetClientRect (&rect);

// adesso possiamo scrivere nella finestra

dc.DrawText ("Hello, World!", -1, &rect,
DT_SINGLELINE | DT_CENTER | DT_VCENTER);
}

Come si puo’ notare dal listato, una applicazione MFC non ha una funzione WinMain
come l’esempio del capitolo precedente realizzato mediante l’SDK.
Le funzionalita’ del WinMain sono svolte da un oggetto di tipo applicazione che deve
essere istanziato in maniera globale derivandolo dalla classe base CWinApp.
In ogni programma MFC deve esistere un solo oggetto di tipo applicazione e se si vuole
che l’applicazione abbia una finestra e’ necessario effettuare l’implementazione del
metodo InitInstance nella classe derivata (in questo caso CMyApp) per crearne una e poi
visualizzarla tramite i metodi ShowWindow e UpdateWindow.
La funzione virtuale InitInstance e’ utilizzata per effettuare qualsiasi operazione di
inizializzazione sia necessaria al momento della partenza dell’applicazione; la funzione
InitInstance deve sempre terminare con il return TRUE.
Da notare che la finestra dell’applicazione viene creata dinamicamente all’interno di
InitInstance tramite l’istruzione m_pMainWnd = new CMainWindow.
In questo modo viene creata una nuova istanza di un oggetto appartenente alla classe
CMainWindow che avevamo derivato (nel .h) dalla classe base CFrameWnd e ne
avevamo implementato il costruttore (l’istruzione Create).

10
La classe base CFrameWnd e’ una delle classi MFC che fornisce l’implementazione di
una generica finestra che puo’ essere contenitore per altre finestre o controlli, oppure
essere utilizzata come nell’esempio per potervi accedere direttamente.
Il metodo Create della classe CFrameWnd puo’ essere scritto in modo da modificare
l’apparenza della finestra dell’applicazione; ad esempio per dotare la window di una
scrollbar verticale e’ necessario specificare:

Create (NULL, "MFC", WS_OVERLAPPEDWINDOW | WS_VSCROLL);

L’applicazione di esempio deve gestire il refresh del messaggio “Hello World!”

all’interno della propria finestra in risposta al messaggio WM_PAINT che gli viene
inviato dal sistema operativo.
La gestione del messaggio WM_PAINT avviene all’interno del metodo OnPaint( ) della
classe CMainWindow.
Per poter disegnare (o scrivere del testo come nell’esempio) all’interno di una finestra e’
necessario disporre di un oggetto denominato “Device Context” che serve ad astrarre
cio’ che si vuole disegnare dal destinatario fisico del disegno (schermo o stampante
indipendentemente dalla risoluzione, numero dei colori, modello della scheda video ecc.).
Non e’ possibile effettuare alcun tipo di output diretto su di una finestra senza l’utilizzo
di un Device Context.
Una volta istanziato l’oggetto di tipo Device context e’ possibile richiamarne il metodo
DrawText per inviare del testo ad un area rettangolare all’interno della finestra definita
istanziando un oggetto di classe CRect.
Il metodo GetClientRect restituisce un riferimento ad un oggetto di tipo CRect che
rappresenta la parte di una finestra su cui e’ possibile effettuare un output (e’ necessario
questo passaggio intermedio dato che l’area di una finestra varia sempre a causa del
ridimensionamento effettuato dall’utente e quindi non e’ possibile stabilire in maniera
assoluta le coordinate e l’ampiezza dell’area utilizzabile).

La “Mappa dei Messaggi”

Il loop dei messaggi e le funzioni di callback che venivano utilizzate con l’SDK sono
state incapsulate all’interno di MFC e quindi il programmatore deve solo utilizzare le
macro BEGIN_MESSAGE_MAP e END_MESSAGE_MAP per specificare quali
saranno i messaggi gestiti dalla sua applicazione.

BEGIN_MESSAGE_MAP (CMainWindow, CFrameWnd)

ON_WM_PAINT ()
END_MESSAGE_MAP ()

Quando si dichiara la mappa dei messaggi e’ necessario indicare sia la classe base che la
classe derivata di cui si dovranno gestire i messaggi ed inoltre e’ necessario che la classe
derivata contenga una funzione membro per ogni messaggio gestito (la CMainWindow
risponde all’evento ON_WM_PAINT dichiarato all’interno della mappa dei messaggi,
tramite la funzione OnPaint).
E’ necessario consultare la documentazione dell’MFC per il prototipo preciso della
funzione membro che deve rispondere ad un determinato messaggio dato che alcune
richiedono parametri in input come ad esempio:

11
WM_LBUTTONDOWN (Pulsante destro del mouse premuto)

che viene gestita da:

Afx_msg void OnLButtonDown (UINT nFlags, Cpoint point)

Parte 2 : Le classi MFC e l’interfaccia di Windows

Gli elementi base di MFC: Disegnare tramite un “Device Context”,

gestione di mouse e tastiera, gestione dei menu.

Per illustrare gli argomenti di questo capitolo verra’ utilizzato come esempio il listato
2_2_1, nel quale si trova l’implementazione di una semplice versione del gioco del tris.
Oltre ad essere un poco piu’ complessa dell’esempio “Hello World” questa applicazione
ci permette di introdurre alcuni argomenti fondamentali come l’intercettazione del mouse
e l’aggiunta e la gestione dei menu.
Data la lunghezza del listato ne riporteremo solo alcuni brani commentati ed invitiamo gli
studenti ad esaminarlo con la massima attenzione autonomamente.

Il “Device Context”
Come abbiamo gia’ visto nel capitolo precedente per poter disegnare su di una finestra e’
necessario disporre di un dispositivo astratto chiamato “Device Context”; per modificare
le caratteristiche di cio’ che si disegna come ad esempio il colore o lo spessore del tratto,
e’ necessario avvalersi di alcune classi MFC come CPen e CBrush che devono essere
associate al device context corrente in questo modo:

Void CMainWindow::OnPaint()
{
// crea il device context
CPaintDC dc(this);

// Crea un nuovo oggetto di tipo CPen (un tratto

// solido completamente nero largo 16 pixel
CPen pen(PS_SOLID, 16, RGB(0, 0, 0));
// si salva la penna corrente associata al
// device context (e’ una buona norma)
CPen *pOldPen = dc.SelectObject(&pen);
// disegna una ellisse (utilizzando la nuova penna)
dc.Ellipse(0, 0, 200, 100);
// riassocia la penna salvata al device context
dc.SelectObject(pOldPen);
}

12
Dal questo brano di codice si comprende che la sequenza di passi per disegnare su di una
window e’ sempre composta da:

- Creazione di un oggetto device context

- Creazione di eventuali oggetti che modificano le caratteristiche del disegno (come
CPen e CBrush)
- Salvataggio del vecchio oggetto associato al device context
- Utilizzo delle funzioni di disegno con le nuove caratteristiche tramite il device
context
- Ripristino delle condizioni iniziali del device context
- Rilascio del device context (distruzione); implicita quando la funzione OnPaint
esce di visibilita’.

Le “Message Box”
Spesso e’ necessario comunicare all’utente di una applicazione tramite piccole finestre di
avvertenza o di segnalazione dette “message box”.
Una message box puo’ essere indipendente dalla finestra in cui si trova e solitamente
serve per comunicare errori, warning o informazioni all’utente (come ad esempio che la
partita di tris e’ terminata nel listato di esempio).

La message box si definisce “finestra modale” ovvero rimane a video sopra le altre
finestre fino a che l’utente non preme il pulsante (solitamente di OK) per confermare la
lettura del messaggio.

MessageBox ("Pareggio!","Game Over",MB_ICONEXCLAMATION |

MB_OK);

Il primo parametro della funzione MessageBox e’ il messaggio stesso, il secondo e’ il

titolo della finestra ed il terzo e’ una combinazione di parametri che specificano il tipo di
MessageBox (informativa, di errore o di avvertenza) ed la combinazione di bottoni
presenti (in questo caso il solo bottone OK).

Il metodo PostNCDestroy
Nell’applicazione di esempio possiamo vedere che la classe che gestisce la finestra
principale dell’applicazione (CMainWindow) richiede l’implementazione della funzione
virtuale PostNCDestroy per distruggere esplicitamente l’oggetto di tipo finestra.
Questo avviene perche’ la classe CMainWindow non era stata derivata da CFrameWnd
come nell’esempio precedente, ma dalla classe base CWnd che ha caratteristiche diverse
e non effettua automaticamente il rilascio delle risorse allocate.

13
Virtual void PostNCDestroy
…
void CMainWindow::PostNcDestroy ()
{
delete this;
}

L’intercettazione di mouse e tastiera

Come si puo’ gia’ intuire da quanto detto fino ad ora riguardo alla programmazione
Windows, l’intercettazione dell’input proveniente dal mouse e dalla tastiera avviene
tramite la gestione di appositi messaggi da parte dell’applicazione.
Ad esempio la pressione dei tasti del mouse ed il suo movimento sono comunicati dal
sistema operativo alle applicazioni tramite una serie di messaggi come ad esempio
WM_LBUTTONDOWN, che indica che il pulsante sinistro del mouse e’ stato premuto,
oppure WM_MOUSEMOVE che indica che il mouse e’ stato mosso al di sopra della
finestra dell’applicazione.
Il programma che vuole gestire questi eventi deve aggiungere alla mappa dei messaggi
l’indicazione dei messaggi a cui e’ interessata e deve fornire le corrispondenti routine di
gestione per gli eventi ricevuti.
Venendo alla nostra applicazione di esempio:

Nel .h ho abbiamo i seguenti prototipi:

// l’applicazione gestisce la pressione del tasto destro

// e sinistro del mouse e il doppio click del tasto
// sinistro
afx_msg void OnLButtonDown (UINT nFlags, CPoint point);
afx_msg void OnLButtonDblClk (UINT nFlags, CPoint point);
afx_msg void OnRButtonDown (UINT nFlags, CPoint point);

Nella mappa dei messaggi ho l’associazione tra eventi e corrispondenti routine di

gestione:

BEGIN_MESSAGE_MAP (CMainWindow, CWnd)

…
ON_WM_LBUTTONDOWN ()
ON_WM_LBUTTONDBLCLK ()
ON_WM_RBUTTONDOWN ()
…
END_MESSAGE_MAP ()

e nel .cpp avro’ l’implementazione delle varie routine di gestione degli eventi legati al
mouse:

14
// in questo caso l’implementazione della routine di
// gestione per l’evento double click del pulsante sinistro
void CMainWindow::OnLButtonDblClk (UINT nFlags, CPoint
point)
{
…
CClientDC dc (this);
if (dc.GetPixel (point) == RGB (0, 0, 0))
ResetGame ();
…
}

Ogni messaggio derivante da una operazione di input da parte dell’utente su mouse e

tastiera avra’ argomenti di input diversi che poi andranno utilizzati nell’implementazione
della funzione di gestione; ad esempio il messaggio LBUTTONDBLCLK invia alla
funzione di gestione un oggetto di tipo CPoint contenente le coordinate del punto in cui
e’ stato effettuato il doppio click del mouse ed un intero contenente un flag che specifica
informazioni addizionali come lo stato dell’altro pulsante oppure se alcuni tasti speciali
della tastiera come CONTROL e SHIFT risultavano premuti al momento del doppio
click.
Le coordinate vengono gia’ passate dal sistema operativo in maniera relativa rispetto alla
finestra dell’applicazione e quindi possono essere facilmente utilizzate dal
programmatore.

La gestione dei menu di un’applicazione MFC

I menu sono una parte fondamentale di ogni applicazione Windows e spesso
rappresentano un elemento irrinunciabile per ogni applicazione dotata di interfaccia
grafica.
Ci sono vari modi per aggiungere un menu ad una applicazione MFC, ma in sostanza la
differenza principale e’ tra memorizzare i menu in un file di risorse esterno oppure crearli
a runtime all’interno del codice che inizializza l’applicazione.
Solitamente si tende a mantenere i menu all’interno del file di risorse che viene poi
compilato separatamente dall’applicazione tramite il “Resource Compiler” per avere
una maggiore facilita’ in caso di modifica successiva delle voci che compongono il menu.
Infatti nel caso in cui si utilizzi il file di risorse si puo’ intervenire con un normale editor
di testo e cambiare le voci di menu senza andare a cercarle all’interno del sorgente
dell’applicazione.
Inoltre l’ambiente di sviluppo Visual Studio mette a disposizione un tool chiamato
“resource editor” che permette di intervenire facilmente sulla struttura dei menu di
un’applicazione e di ricompilare il file di risorse senza conoscerne la struttura interna; il
file di risorse puo’ ospitare al suo interno non solo menu, ma anche messaggi di testo,
icone, bitmap e cursori utilizzati dall’applicazione Windows.
Per aggiungere un menu all’applicazione di esempio utilizzando il file di risorse e’
necessario effettuare i seguenti passi:

15
Selezionare dal menu Insert -> Resource e scegliere Menu premendo il tasto New.

A questo punto e’ possibile editare la struttura dei menu graficamente facendo doppio
click sulla casella vuota per inserire un nuovo elemento in un menu esistente oppure
crearne uno nuovo.

Una volta creata la struttura dei menu e’ necessario salvare il file di risorse (avra’
estensione .rc) e spostarlo tra i sorgenti del progetto per fare in modo che venga
ricompilato quando si effettua il Build dell’eseguibile.

Per indicare nel sorgente che si utilizza un file di risorse esterno e’ necessario includere
nel .h lo header file resource.h

#include <resource.h>

a questo punto dobbiamo, sempre nel .h, dichiarare il prototipo della funzione che verra’
richiamata per ogni voce di menu selezionata; ad esempio se abbiamo una voce ‘Exit’
all’interno del menu ‘File’ che e’ stata chiamata all’interno dell’editor di menu
ID_EXIT, e’ necessario aggiungere il prototipo della seguente funzione di gestione:

afx_msg void OnExit();

nel .cpp e’ necessario aggiungere alla mappa dei messaggi il collegamento alla funzione
OnExit( ) nel momento in cui viene ricevuto il messaggio che segnala che l’utente ha
selezionato la voce ‘Exit’ dalla barra dei menu:

BEGIN_MESSAGE_MAP (CMainWindow, CWnd)

…
ON_COMMAND(ID_EXIT, OnExit)
…
END_MESSAGE_MAP ()

La funzione di gestione OnExit deve essere implementata all’interno della classe

CMainWindow:

void CMainWindow::OnExit()
{
// si fa semplicemente terminare l’applicazione
PostMessage(WM_CLOSE, 0, 0);
}

A questo punto rimane da collegare il menu che abbiamo creato alla finestra
dell’applicazione e per fare questo abbiamo varie alternative; una di queste consiste
nell’aggiungere le seguenti righe di codice all’interno del costruttore della classe
CMainWindow:

16
// Crea un nuovo oggetto di tipo menu
CMenu menu;
// il menu creato nel resource file viene associato
// all’oggetto menu creato
menu.LoadMenu(MAKEINTRESOURCE(IDR_MENU1));
SetMenu(&menu);
// si distacca il menu creato dall’oggetto menu in modo che
// non venga distrutto quando l’oggetto menu andra’ al di
// fuori dello spazio di visibilita’
menu.Detach();

Un metodo alternativo per collegare un menu ad una finestra consiste nel modificare
l’istruzione Create della finestra passandogli l’identificativo del menu:

CreateEx (0, strWndClass, "Tris",

WS_OVERLAPPED | WS_SYSMENU | WS_CAPTION |
WS_MINIMIZEBOX,rectDefault,
MAKEINTRESOURCE(IDR_MENU1), NULL );

Altrimenti e’ possibile effettuare la creazione e/o la modifica di un menu completamente

all’interno di un programma senza utilizzare il file di risorse; questa possibilita’ puo’
essere utilizzata ad esempi nel caso in cui si abbia una applicazione che ha due tipi di
menu che possono essere scambiati a richiesta (ad esempio menu “abbreviati” per gli
utenti principianti e menu “completi” per quelli avanzati).

Esempio:
// crea il menu di primo livello (es. File)
CMenu menuMain;
MenuMain.CreateMenu();

// crea le voci all’interno del menu (es. Exit)

Cmenu menuPopup;
MenuPopup.CreatePopupMenu();
// crea la voce ‘Exit’
MenuPopup.AppendMenu(MF_STRING, ID_EXIT, “Exit”);
// aggancia il sottomenu al menu principale ‘File’
Menumain.AppendMenu(MF_POPUP, (UINT) menuPopup.Detach(),
“File”);
// visualizza il menu completo
SetMenu(&menuMain);
MenuMain.Detach();

17
I controlli di base e le “dialog box”
I “controlli” possono essere considerati come i “mattoni” che servono a costruire
l’interfaccia di qualsiasi applicazione Windows.
In generale un controllo e’ uno speciale tipo di finestra che permette di interagire con
l’utente finale, sia in termini di input che di output; i piu’ comuni controlli utilizzati in
pressoche’ tutte le applicazioni Windows sono bottoni, label, textbox, listbox, combo
box e check box.
Naturalmente esistono molti altri controlli, ed altri se ne aggiungono via via che
l’interfaccia delle varie versioni di Windows viene migliorata ed evoluta; il
programmatore li puo’ utilizzare come oggetti preconfezionati (classi in MFC) tramite la
loro interfaccia senza preoccuparsi di come siano stati implementati.

Per utilizzare i controlli di Windows all’interno delle applicazioni MFC in genere si

procede in questo modo:

- Nel .h della classe che implementa la finestra si aggiungono gli oggetti che si
vorranno visualizzare nella finestra sotto forma di oggetti membro di tipo
variabile a seconda della classe di oggetto (es. CButton m_myButton, CListbox
m_myListBox ecc.)
- Al momento della creazione della una finestra si creano anche i controlli che sono
contenuti nella finestra (chiamando i metodi create delle varie classi MFC che
implementano i controlli come CButton, CListbox ecc.).
- Nella mappa dei messaggi vanno aggiunti gli eventi generati dai controlli
utilizzati; ad esempio il controllo bottone genera un evento ON_BN_CLICKED
che viene generato al momento della pressione.
- Gli eventi dei controlli che si desidera gestire vanno associati alle corrispondenti
routine di gestione (es. OnButtonClicked).
- Le routine di gestione vanno implementate all’interno dell’applicazione.

Ogni controllo ha le sue caratteristiche, attributi ed eventi che puo’ generare con relativi
differenti prototipi delle routine di gestione; e’ chiaro quindi che e’ necessario leggere la
documentazione di ogni tipo di controllo per poterlo utilizzare correttamente all’interno
delle proprie applicazioni.

Nel listato 2_2_2 si trova un esempio di utilizzo di alcuni dei controlli principali (un
bottone, una listbox, una label ecc.) che vongono impiegati in una semplice applicazione
che visualizza in una listbox tutte le font di caratteri installate nel sistema.

Nel file .h vengono aggiunti come membri della classe finestra dell’applicazione i
controlli che si utilizzeranno in questo modo:

CStatic m_wndLBTitle;
CListBox m_wndListBox;
CButton m_wndCheckBox;

18
CButton m_wndGroupBox;
CStatic m_wndSampleText;
CButton m_wndPushButton;

Nella mappa dei messaggi della nostra applicazione d’esempio vediamo quali siano gli
eventi gestiti per ognuno dei controlli presenti nella finestra principale; per il bottone
gestiamo l’evento OnPushButtonClicked, per la checkbox gestiamo
OnCheckBoxClicked e per la listbox OnSelChange che viene attivato quando la
selezione di uno degli elementi della listbox cambia.
Naturalmente possono esserci dei controlli nella finestra dell’applicazione per cui non
gestiamo eventi; ad esempio il controllo label e’ utilizzato per visualizzare solo del testo
statico e quindi non abbiamo la necessita’ di gestirne alcun evento.

BEGIN_MESSAGE_MAP (CMainWindow, CWnd)

// evento bottone 'Stampa' premuto
ON_BN_CLICKED (IDC_PRINT, OnPushButtonClicked)
// evento click sulla checkbox
ON_BN_CLICKED (IDC_CHECKBOX, OnCheckBoxClicked)
// evento cambio di elemento all'interno della listbox
ON_LBN_SELCHANGE (IDC_LISTBOX, OnSelChange)
END_MESSAGE_MAP ()

Nella routine di gestione dell’evento OnCreate della finestra dell’applicazione si chiama

il metodo Create per ognuno degli oggetti di tipo controllo; in questo modo i controlli
verranno finalmente visualizzati nella finestra e se ne potra’ anche definire le
caratteristiche tramite gli argomenti passati al metodo Create (es. la caption per un
bottone o una label).

// creazione del controllo label

m_wndLBTitle.Create ("Font", WS_CHILD | WS_VISIBLE |
SS_LEFT, rect, this);

// creazione della listbox

m_wndListBox.CreateEx (WS_EX_CLIENTEDGE, "listbox", NULL,
WS_CHILD | WS_VISIBLE | LBS_STANDARD, rect, this,
IDC_LISTBOX);

// creazione della checkbox

m_wndCheckBox.Create ("Mostra solo le font TrueType",
WS_CHILD | WS_VISIBLE | BS_AUTOCHECKBOX, rect, this,
IDC_CHECKBOX);

// creazione del frame di visualizzazione della font

m_wndGroupBox.Create ("Esempio", WS_CHILD | WS_VISIBLE |
BS_GROUPBOX, rect, this, (UINT) -1);

// creazione del testo font selezionata

19
m_wndSampleText.Create ("", WS_CHILD | WS_VISIBLE |
SS_CENTER, rect, this, IDC_SAMPLE);

// creazione del bottone 'Stampa'

m_wndPushButton.Create ("Stampa", WS_CHILD | WS_VISIBLE |
WS_DISABLED | BS_PUSHBUTTON, rect, this, IDC_PRINT);

Da notare che il metodo Create e’ diverso per ogni controllo a seconda degli argomenti
necessari e che ognuno ha bisogna di una struttura di tipo CRect per definirne posizione
e dimensione all’interno della finestra.

A questo punto vanno implementate le routine di gestione specificate all’interno della

mappa dei messaggi:

void CMainWindow::OnPushButtonClicked ()
{
MessageBox ("Aspetto di essere implementata",
"Error", MB_ICONINFORMATION | MB_OK);
}

Questa e’ l’implementazione della routine di risposta all’evento click del bottone di

‘Stampa’; chiaramente in questo caso il programma non fa niente se non visualizzare un
messaggio ma l’importante e’ vedere come e’ strutturata la routine di gestione.

// evento cambiamento di font selezionata nella listbox

void CMainWindow::OnSelChange ()
{
int nIndex = m_wndListBox.GetCurSel ();
…
CString strFaceName;
m_wndListBox.GetText (nIndex, strFaceName);
…
}

Piu’ interessante appare l’implementazione della routine di risposta all’evento

OnSelChange della listbox di cui e’ stato riportato solo una porzione.
Il metodo GetCurSel restituisce l’indice dell’elemento correntemente selezionato
all’interno della listbox e tale indice viene utilizzato congiuntamente al metodo GetText
per recuperare il testo dell’elemento selezionato ed appoggiarlo in una variabile di tipo
CString.

Una delle potenzialita’ piu’ interessanti di MFC e’ rappresentata dal fatto che e’ possibile
creare controlli “customizzati” ereditando dalle classi base dei controlli predefiniti in
modo da arricchirne le funzionalita’.
L’architettura MFC rende questa operazione sufficientemente semplice in quanto
permette di specificare un meccanismo di “reindirizzamento” dei messaggi dalla classe
base a quella derivata; ad esempio se ho derivato un controllo listbox proprietario in cui

20
voglio gestire il double click in maniera diversa da quella della listbox tradizionale e’
sufficientemente ereditare una nuova classe CMyListbox da CListBox e specificare
nella mappa dei messaggi che l’evento double click avra’ un trattamento speciale (che
naturalmente dovra essere implementato) rispetto al controllo base.

L’esempio 2_2_3 serve ad esemplificare questa tecnica, implementando un controllo

label a cui e’ possibile cambiare il colore del testo; stranamente nel controllo base non e’
possibile infatti intervenire direttamente sul colore.

class CColorStatic : public CStatic

{
protected:
COLORREF m_clrText;
COLORREF m_clrBack;
CBrush m_brBkgnd;

public:
CColorStatic ();
void SetTextColor (COLORREF clrText);
void SetBkColor (COLORREF clrBack);

protected:
afx_msg HBRUSH CtlColor (CDC* pDC, UINT nCtlColor);
DECLARE_MESSAGE_MAP ()
};

Dalla definizione della classe del nostro controllo custom si puo’ notare che abbiamo
aggiunto due nuovi metodi SetTextColor e SetBkColor; nella mappa dei messaggi del
nuovo controllo dovremo specificare solo quali sono gli eventi che vogliamo gestire in
maniera differente dal controllo base:

BEGIN_MESSAGE_MAP (CColorStatic, CStatic)

// rispetto al controllo base il controllo derivato
// gestisce autonomamente il messaggio CtlColor
ON_WM_CTLCOLOR_REFLECT ()
END_MESSAGE_MAP ()

Il messaggio speciale ON_WM_CTLCOLOR_REFLECT, serve a segnalare ad MFC

che il nostro controllo derivato avra’ una sua routine di gestione di questo evento e che
non vogliamo il trattamento di default riservato alla classe base.

(common controls)

Le “Dialog Box”
Nelle applicazioni Windows di solito i controlli non vengono posizionati nella finestra
principale dell’applicazione, ma in speciali finestre progettate per la raccolta dell’input da
parte dell’utente dette “dialog box”.

21
Un esempio puo’ essere la finestra di salvataggio dei file che troviamo in tutte le
applicazioni Windows oppure la finestra in cui si definiscono le opzioni di stampa.
Per inserire una dialog box in una applicazione MFC e’ necessario ereditare una propria
classe dalla classe base CDialog, inserire i controlli all’interno della dialog, ed
eventualmente implementare alcune funzioni virtuali che gestiscono il comportamento
della dialog.
In sintesi i passi da seguire per aggiungere ad una applicazione una semplice dialog box
che richiede l’input di un campo test e di uno numerico (listato 2_2_4), sono questi:

- Sebbene sia possibile fare tutto manualmente e’ bene in questo caso avvalersi
dell’aiuto dell’ambiente di sviluppo per la creazione della struttura base della
dialog e quindi dal menu Insert selezionare New Form, scegliere come classe
base CDialog e specificare il nome; il Visual Studio provvedera’ a creare il file di
risorse, ed i file .cpp e .h per la nostra nuova dialog.
- A questo punto possiamo aprire il resource editor e modificare l’aspetto della
nostra dialog box aggiungendo i controlli di input necessari (da notare che i
bottoni OK e CANCEL con la relativa gestione base sono gia’ stati implementati
dallo Wizard.
- Una volta aggiunti i controlli di input graficamente e assegnato loro un nome (es.
IDC_EDITNAME) e’ necessario aggiungere nel .h tante variabili membro della
classe CMyDialog quanti sono i campi associati ai controlli di input.
- E’ necessario poi effettuare l’associazione tra le variabili membro ed i controlli di
input e definire se devono essere effettuati controlli di validazione sull’input
inserito; i due metodi possibili per queste operazioni sono illustrati
successivamente da alcuni brani di codice tratti dall’esempio 2_2_4.
- Una volta preparata la dialog box e’ possibile richiamarla dall’applicazione
istanziando un oggetto di tipo CMyDialog in maniera “modale” (la dialog non si
chiude fino a che non si preme Ok o Cancel e non si puo’ passare ad altre finestre)
oppure “non modale” la dialog puo’ esssere chiusa e trattata come le finestre
tradizionali.

Vediamo la definizione della classe CMyDialog tratta dal listato 2_2_4 con la
dichiarazione delle variabili membro che dovranno ospitare il risultato dell’input sui
controllli della dialog:

class CMyDialog : public CDialog

{
public:
// costruttore standard
CMyDialog(CWnd* pParent = NULL);

// variabili membro associate ai controlli di

// input
CString m_strNome;
int m_intNumero;
…
}

22
Per poter associare i controlli alle variabili membro appena dichiarate essitono due
metodi; il primo consiste nell’effettuare l’override delle funzioni virtuali OnInitDialog e
OnOk per associare direttamente al controllo (in questo caso IDC_EDITNOME) la
variabile membro (m_strNome) sia quando la dialog viene inizializzata, sia quando il
pulsante Ok viene premuto e quindi la dialog verra’ chiusa.

// nel .h (CMyDialog.h)
virtual BOOL OnInitDialog ();
virtual void OnOK();

// nel .cpp (CMyDialog.cpp)

BOOL CMyDialog::OnInitDialog()
{
CDialog::OnInitDialog();
SetDlgItemText(IDC_EDITNOME, m_strNome);
return TRUE;
}

void CMyDialog::OnOK()
{
GetDlgItemText(IDC_EDITNOME, m_strNome);
CDialog::OnOK();
}

Altrimenti e’ possibile lasciare il lavoro di associazione / validazione dell’input

direttamente ad MFC utilizzando il metodo DoDataExchange della classe CDialog; la
funzione DDX_Text associa una variabile membro ad un controllo e la funzione
DDV_MinMaxInt controlla che il valore inserito nel controllo di input sia all’interno di
un range specificato.

void CMyDialog::DoDataExchange(CDataExchange* pDX)

{
CDialog::DoDataExchange(pDX);

DDX_Text(pDX, IDC_EDITNUMERO, m_intNumero);

DDV_MinMaxInt(pDX, m_intNumero, 0, 10);
}

Nell’applicazione principale la dialog viene richiamata in maniera “modale” e si puo’

testare il valore di ritorno per determinare se l’utente ha premuto il pulsante Ok o Cancel;
una volta usciti dalla dialog e’ possibile recuperare il contenuto delle variabili membro ed
utilizzare il risultato dell’input effettuato all’interno della dialog.

23
CMyDialog dlg;
if (dlg.DoModal() == IDOK)
{
// l'utente ha premuto il pulsante OK nella dialog
// visualizziamo il risultato dell'input nella dialog
CString nome;
nome = dlg.m_strNome;
MessageBox(NULL,nome,"Messaggio",MB_OK);
}

Nonostante l’associazione tra controlli e variabili membro all’interno di una dialog box
possa essere lasciata ad MFC, e’ possibile comunque manipolare direttamente i controlli
presenti all’interno di una dialog ottenendone un puntatore e chiamandone i metodi
tramite questo puntatore:

// ottiene un puntatore al controllo Edit

CWnd* pWnd = GetDlgItem(IDC_EDITNOME);
// accede al controllo Edit tramite il puntatore e lo rende
// inattivo
pWnd->EnableWindow(FALSE);

// ottiene un puntatore ad una ListBox

CListBox *pListBox = (CListbox *) GetDlgItem(IDC_LIST);
PListBox->AddString(“TEST”);

si puo’ interagire con un controllo all’interno della dialog anche in altri modi, ad esempio
tramite il metodo DDX_Control della dialog che effettua il collegamento tra una
variabile di tipo CListBox ed un controllo ListBox all’interno della dialog:

DDX_Control (pDX, IDC_LIST, m_ListBox);

m_listBox.AddString(“TEST”);

Fogli di proprieta’ (“Property Sheets”)

I fogli di proprieta’ sono particolari tipologie di dialog box in cui le pagine di controlli
sono suddivise in piu’ sezioni dette “tabs”.

Le “Common Dialogs”
Le “common dialogs” sono finestre di tipo dialog box che vengono usate praticamente in
ogni applicazione Windows (come la finestra “Save as …”) e che quindi sono state
“pacchettizzate” in un un unico controllo che al suo interno incorpora tutti gli altri
controlli costituenti e nasconde all’utilizzatore la complessita’ della loro
implementazione.
In sostanza e’ possibile, utilizzando le common dialogs, incorporare nelle proprie
applicazioni finestre complete di gestione di particolari tipi di input standard (salvataggio
dei file, settaggio della stampante, selezione di un colore ecc.) scrivendo pochissime
righe di codice che servono solo a personalizzare minimamente il contenuto di questi utili
oggetti preconfezionati.

24
Le classi di utilita’ MFC e la “serializzazione”
Un alternativa all’utilizzo della libreria STL (Standard Template Library) e’ quella di
utilizzare le collezioni di classi “container” e di utilita’ fornite da MFC; infatti all’interno
di MFC si trovano una serie di classi che mette a disposizione container, strutture dati ed
ua classe stringa (CString).
Dato che le funzionalita’ di queste classi rappresentano, sotto molti aspetti, un
sottoinsieme di quello che viene fornito da STL si consiglia per quanto possibile, di
utilizzare STL all’interno delle proprie applicazioni MFC (anche per non dover imparare
ad utilizzare tutta una nuova libreria di classi per fare piu’ o meno le stesse cose).

La “serializzazione”
Uno dei concetti piu’ importanti contenuti all’interno delle classi di utilita’ MFC e’
quello della serializzazione; questo procedimento consiste nel poter salvare e leggere da
disco i dati persistenti di una applicazione MFC in maniera semplice ed indipendente da
come i dati sono organizzati.
Il cuore del concetto di serializzazione consiste nella possibilita’ di rendere
“serializzabile” una classe, ovvero di poter avere a disposizione una serie di meccanismi
che permettono di memorizzare e rileggere da supporto magnetico i dati contenuti
all’interno di una classe semplicemente utilizzando gli operatori << e >> tramite
l’utilizzo di un oggetto appartenente alla classe CArchive.

Vediamo qualche esempio tratto dal listato 2_2_5:

Per rendere una classe “serializzabile” come prima cosa e’ necessario derivarla dalla
classe base CObject ed inserire all’interno della definizione della classe la macro
DECLARE_SERIAL; la classe serializzabile deve inoltre avere un metodo Serialize che
riceve in input un reference ad un oggetto di tipo CArchive che sara’ il vero e proprio
file su cui andremo a salvare il contenuto della classe Ctest:

class CTest : public CObject

{
DECLARE_SERIAL (CTest)

protected:
CString m_strMsg;
public:
CTest() { }
void set_msg(CString s) { m_strMsg = s; }
CString get_msg() { return m_strMsg; }
void Serialize (CArchive& ar);
};

25
Nel .cpp in cui andremo ad implementare i metodi della nostra classe serializzabile e’
necessario specificare la macro IMPLEMENT_SERIAL e scrivere il metodo Serialize
in cui andremo a scrivere e leggere all’interno dell’oggetto CArchive i membri della
classe che vogliamo rendere persistenti:

IMPLEMENT_SERIAL(CTest, CObject, 1)

void CTest::Serialize(CArchive &ar)

{
CObject::Serialize(ar);
if (ar.IsStoring())
// SAVE
ar << m_strMsg;
else
// LOAD
ar >> m_strMsg;
}

All’interno dell’applicazione principale utilizziamo la nostra classe serializzabile

all’interno di due comandi di menu Load e Save; nel metodo Save viene creato il file su
cui salvare il contenuto della classe e viene chiamato il metodo Serialize che provvede a
scrivere sul file.
Nel metodo Load il file viene aperto in lettura e di nuovo viene invocato il metodo
Serialize per recuperare il contenuto dei membri persistenti della classe dal supporto
magnetico:

void CMy2_2_5App::OnSave()
{
CTest ct;
ct.set_msg("pino");

CFile file("CTest.txt", CFile::modeWrite |

CFile::modeCreate);
CArchive ar (&file, CArchive::store);
ct.Serialize(ar);

26
void CMy2_2_5App::OnLoad()
{
CTest ct;

CFile file("CTest.txt", CFile::modeRead);

CArchive ar (&file, CArchive::load);
ct.Serialize(ar);

MessageBox(NULL,ct.get_msg(),"Msg",MB_OK);
}

Introduzione all’architettura “Document View”

Come gia’ detto nei primi capitoli, MFC non e’ solo un’interfaccia Object Oriented verso
le API di Windows, ma e’ anche tutta una serie di meccanismi applicativi e di tecniche di
sviluppo (il cosiddetto “framework”), di cui l’architettura Document/View
(Documento/Vista) costituisce una parte fondamentale.

L’architettura applicativa Document/View si puo’ definire come un insieme di classi e di

tecniche di programmazione che permette di astrarre la rappresentazione dei dati di una
applicazione (Document) dalla sua visualizzazione grafica all’interno di una finestra
(View).

Il vantaggio di questo tipo di architettura, oltre a quello intrinseco di separare i dati

dall’interfaccia grafica, e’ rappresentato dal fatto che il framework MFC praticamente si
occupa di gestire molti aspetti dell’applicazione (soprattutto in termini di interfaccia
grafica) lasciando quindi al programmatore il compito di scrivere il codice
concentrandosi sulle classi che gli servono per risolvere il problema specifico.

Per fare un esempio, l’architettura Document/View permette di gestire il salvataggio e la

lettura dei dati di un’applicazione senza praticamente dover scrivere codice, e gestisce
inoltre in maniera trasparente altre situazioni come la richiesta di salvare prima di uscire
se un documento e’ stato modificato ecc.

Un altro vantaggio nell’utilizzo di applicazioni MFC Document/View consiste

nell’elevato grado di astrazione della vista rispetto al dispositivo fisico di output; infatti
effettuare operazioni di output su di una vista permette di raggiungere l’indipendenza
rispetto al fatto che poi la vista sia mappata fisicamente sullo schermo oppure sulla
stampante, rendendo l’implementazione di routine di stampa un compito ben piu’
semplice che in passato.

Una applicazione Document/View MFC puo’ inoltre aggiornare il registro, specificando

la propria estensione dei file in modo che sia sufficiente fare doppio click su di un file

27
salvato dall’applicazione per poterlo caricare ed eseguire allo stesso tempo l’applicazione
(come succede quando si fa doppio click su di un file .doc di Word); e’ inoltre possibile
aprire direttamente un nuovo file semplicemente trascinandolo all’interno della finestra
dell’applicazione (drag & drop open).

La struttura base dell’architettura di un’applicazione Document/View e’ formata da una

“finestra container” o “frame window” (CFrameWnd) che rappresenta la finestra
principale dell’applicazione, la quale agisce da contenitore per una o piu’ “viste”
(CView) che non sono altro che rappresentazioni dei dati del programma memorizzati
all’interno di un oggetto appartenente alla classe “documento” (CDocument).

Le applicazioni Document/View possono essere di tipo SDI (Single Document

Interface), ovvero che possono gestire una singola vista per volta di un oggetto
documento all’interno della finestra contenitore, e MDI (Multiple Document Interface)
ovvero dotate di viste multiple su oggetti documento multipli.
E’ chiaro che l’implementazione e la gestione di un’applicazione MDI e’ ben piu’
complessa di una SDI e probabilmente anche piu’ difficile da comprendere per
l’utilizzatore finale; percio’ all’interno di questi capitoli dedicati all’architettura
Document/View ci concentreremo maggiormente sulle applicazioni SDI.

Il framework MFC permette inoltre di creare a runtime documenti, viste e finestre

container tramite il processo chiamato “Dynamic Object Creation”

Grazie alla possibilita’ di instradamento dei messaggi effettuata da MFC le varie

componenti di una applicazione Document/View possono processare i messaggi ricevuti
indipendentemente; ogni messaggio in arrivo verra’ prima inviato alla vista, se questa
non ha una routine di gestione andra’ all’oggetto Document e successivamente alla
finestra container CFramewnd e su fino all’oggetto globale Application (Ad esempio e’
l’oggetto applicazione, che solitamente gestisce gli eventi OnFileNew e OnFileSave per
una applicazione Document/View).

Le applicazioni SDI (Single Document Interface)

Per chiarire il funzionamento dell’architettura Document/View andremo ad analizzare
un’applicazione di esempio (listato 2_2_6), che e’ molto semplice ma contiene al suo
interno tutti i concetti fondamentali.
Grazie al framework MFC e’ possibile generare un’applicazione di questo tipo limitando
al minimo la quantita’ di codice scritto manualmente utilizzando il Wizard dell’ambiente
di sviluppo.
Avvalendosi del wizard e’ possibile delegare al Visual Studio la generazione di tutto lo
scheletro di una applicazione SDI base gia’ fornita di tutti le funzionalita’ base descritte
nel capitolo precedente, come salvataggio/caricamento dei documenti, menu dei comandi
pregenerato con relativa mappa dei messaggi, predisposizione per le funzioni di stampa
ecc.

28
Per creare lo scheletro di una applicazione SDI utilizzando il code wizard e’ necessario
seguire questi passi:

- Selezionare File -> New per creare un nuovo progetto e scegliere “MFC App
Wizard” come tipo di applicazione.
- A questo punto si apriranno alcune finestre in cui e’ possibile specificare che tipo
di scheletro vogliamo generare; nel nostro caso selezionare “Single Document” e
lasciare attivata la checkbox “Document/View Support”.
- Nella seconda finestra del wizard non selezionare alcun supporto per database.
- Nella terza finestra lasciare attivata la voce “None” e deselezionare anche la voce
“ActiveX Controls”.
- Nella quarta finestra selezionare le feature che si desidera includere
automaticamente nell’applicazione; per mantenere semplice il codice se non si
hanno esigenze particolari di stampa o di interfaccia deselezionare tutte le
opzioni.
- Nella quinta e ultima finestra del wizard lasciare tutte le opzioni di default.
- Nella sesta e ultima finestra e’ presente un riepilogo dei file .cpp e .h che verranno
generati automaticamente dal Visual Studio ed e’ possibile eventualmente
cambiare i nomi proposti per classi e sorgenti.
- Finalmente lo scheletro dell’applicazione viene generato, ed e’ ora possibile
intervenire nel codice prodotto per personalizzare il comportamento
dell’applicazione; da notare che viene generato anche il file di risorse (.rc) che
contiene tutti i menu, i messaggi a video, le icone e le dialog box
dell’applicazione.

Se proviamo ad eseguire lo scheletro dell’applicazione generato dal Visual Studio

possiamo vedere quanta parte di lavoro sia gia’ stata svolta dall’ambiente di sviluppo in
termini di interfaccia e funzioni comuni.

Utilizzando come modello l’applicazione di esempio andiamo ad esaminare quali sono le

classi utilizzate da una tipica applicazione SDI:

La prima classe che troviamo e’ quella utilizzata per istanziare l’applicazione stessa;
l’oggetto applicazione viene creato in maniera globale nello stesso modo che avevamo
visto negli esempi precedenti (ad esempio CSquaresApp MyApp), ma troviamo una
differenza nell’implementazione del metodo InitInstance dell’oggetto CSquaresApp
dato che l’inizializzazione dell’architettura Document/View richiede una serie di
operazioni aggiuntive:

29
// anche CSquaresAPP e’ derivata da CWinApp
class CSquaresApp : public CWinApp

BOOL CSquaresApp::InitInstance()
{
// crea la chiave nel registro se non esistente
// e carica le impostazioni di default (gestito
// da MFC)
SetRegistryKey("SDISquares");
LoadStdProfileSettings();

// inizializza l’applicazione di tipo

// Document/View SDI creando un nuovo template e
// specificando l’id del file di risorse, il nome
// della classe Document, il nome della classe della
// finestra container ed il nome della classe vista
CSingleDocTemplate* pDocTemplate;
pDocTemplate = new CSingleDocTemplate(
IDR_MAINFRAME,
RUNTIME_CLASS(CSquaresDoc),
RUNTIME_CLASS(CMainFrame),
RUNTIME_CLASS(CSquaresView));
AddDocTemplate(pDocTemplate);

// abilita l’apertura dell’applicazione in seguito

// al doppio click su di un file salvato
EnableShellOpen();
RegisterShellFileTypes(TRUE);

// riceve eventuali parametri da linea di comando

CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo);

// processa i parametri ricevuti da linea di comando

if (!ProcessShellCommand(cmdInfo))
return FALSE;

// visualizza la finestra e container

m_pMainWnd->ShowWindow(SW_SHOW);
m_pMainWnd->UpdateWindow();

// abilita l’apertura di nuovi documenti semplicemente

// facendo drag e drop all’interno della finestra
// dell’applicazione
m_pMainWnd->DragAcceptFiles();
return TRUE;
}

30
La differenza piu’ importante sta nella creazione del template di tipo
CSingleDocTemplate, che in pratica comunica al compilatore che stiamo creando una
nuova applicazione di tipo Document/View e che quindi vogliamo utilizzare la struttura
finestra container / vista / documento.

La finestra principale dell’applicazione che agisce da container per la vista e’ derivata

dalla classe base CFrameWnd; la classe CFrameWnd e’ diversa da CWnd che avevamo
utilizzato negli esempi precedenti in quanto la classe CWnd e’ semplicemente un oggetto
di tipo finestra Windows senza particolari caratteristiche mentre la classe CFrameWnd
rappresenta un tipo particolare di finestra gia’ progettato per agire da container per altre
finestre e dotato di tutta una serie di funzionalita’ orientate verso l’architettura
Document/View.
Si tratta in sostanza di una finestra “intelligente” che provvede al suo interno a gestire
molti dei compiti richiesti dall’architettura Document/View (ad esempio quando viene
ridimensionata la finestra container automaticamente viene ridimensionata anche la vista
ecc.).
Se osserviamo l’implementazione della classe CMainFrame, vediamo che oltre al codice
generato automaticamente dal wizard non e’ stato necessario scrivere una sola riga di
codice per personalizzare il comportamento della finestra container che va gia’ benissimo
cosi’ per la nostra semplice applicazione.

class CMainFrame : public CFrameWnd

La classe CSquaresDoc derivata da CDocument rappresenta la struttura dati di una

applicazione Document/View ed include le “operazioni” che e’ possibile effettuare sui
dati; e’ da notare che non e’ presente nessuna informazione riguardo a come questi dati
verranno poi visualizzati nella finestra dato che questo compito e’ demandato interamente
all’oggetto vista.

class CSquaresDoc : public Cdocument

{
…
public:
void SetSquare (int i, int j, COLORREF color);
COLORREF GetSquare (int i, int j);
COLORREF GetCurrentColor();
virtual ~CSquaresDoc();

protected:
COLORREF m_clrCurrentColor;
COLORREF m_clrGrid[4][4];

afx_msg void OnColorRed();

afx_msg void OnColorYellow();
afx_msg void OnColorGreen();

31
 afx_msg void OnColorCyan();
afx_msg void OnColorBlue();
afx_msg void OnColorWhite();
afx_msg void OnUpdateColorRed(CCmdUI* pCmdUI);
afx_msg void OnUpdateColorYellow(CCmdUI* pCmdUI);
afx_msg void OnUpdateColorGreen(CCmdUI* pCmdUI);
afx_msg void OnUpdateColorCyan(CCmdUI* pCmdUI);
afx_msg void OnUpdateColorBlue(CCmdUI* pCmdUI);
afx_msg void OnUpdateColorWhite(CCmdUI* pCmdUI);
DECLARE_MESSAGE_MAP()
}

Generalmente nell’implementazione della classe derivata dalla CDocument e’ necessario

effettuare l’override del metodo OnNewDocument per effettuare le necessarie
operazioni di inizializzazione nel momento in cui un nuovo documento viene creato (il
metodo OnNewDocument viene chiamato automaticamente dal framework MFC nel
momento in cui si selezione la voce ‘New’ dal menu ‘File’);e’ inoltre necessario
implementare anche il metodo Serialize per fare in modo che la nostra classe derivata da
CDocument sia “serializzabile” (vedi capitolo 2.3).

BOOL CSquaresDoc::OnNewDocument()
void CSquaresDoc::Serialize(CArchive& ar)

La classe CSquaresView e’ derivata dalla classe base CView ed e’ quello che si

definisce la “vista” della nostra applicazione; come gia’ accennato lo scopo della vista e’
quello di fornire una rappresentazione dei dati contenuti nella classe documento e di
interagire con l’utente dell’applicazione (ovvero intercettare l’input da mouse e/o
tastiera).
Si possono associare piu’ viste ad uno stesso oggetto documento (dato che possono
esistere diversi modi di rappresentare graficamente gli stessi dati), ma una vista
appartiene sempre ad un solo documento.
Questo legame e’ mantenuto dal framework MFC ed il programmatore puo’ accedere per
puntatore all’oggetto documento collegato ad una vista tramite il metodo GetDocument.

class CSquaresView : public CView

{
…
public:
CSquaresDoc* GetDocument();
…
inline CSquaresDoc* CSquaresView::GetDocument()
{ return (CSquaresDoc*)m_pDocument; }
}

32
In genere, dato che la vista si occupa di dare una rappresentazione grafica ad un
documento, il metodo piu’ importante dell’oggetto CView e’ quello che risponde
all’evento OnDraw, ovvero alla richiesta di disegnare il contenuto della vista.
Questo metodo, fornito come implementazione della funzione virtuale OnDraw, e’
chiamato direttamente dal framework MFC tutte le volte che sia necessario ridisegnare il
contenuto della vista :

void CSquaresView::OnDraw(CDC* pDC)

{
CSquaresDoc* pDoc = GetDocument();
…
COLORREF color = pDoc->GetSquare (i, j);
…
pDC->FillRect (rect, &brush);
…
}

E’ da notare due cose nell’implementazione del metodo OnDraw; la prima e’ il modo in

cui la vista ottiene accesso al documento utilizzando un puntatore di tipo CSquaresDoc
restituito dal metodo GetDocument, e la seconda e’ il fatto che le funzioni di disegno
(come FillRect) lavorino su di un device context generico che viene passato alla funzione
di disegno della vista dal framework MFC (questo ci suggerisce che se il device context
fosse associato ad un oggetto fisico di tipo “stampante” non ci sarebbe da modificare
niente all’interno del metodo OnDraw per poter ottenere una stampa cartacea).

La classe CSquaresView, come gia’ detto, si deve occupare anche della gestione
dell’input (in questo caso della pressione del tasto sinistro del mouse che comporta la
colorazione di uno dei quadrati); e’ da notare che questo evento e’ gestito normalmente
tramite la mappa dei messaggi come avevami visto negli esempi dei capitoli precedenti.
L’unica particolarita’ consiste nel fatto che, come prima cosa, viene richiamato il metodo
OnLButtonDown della classe base CView (dato che anche la classe base deve essere
notificata dell’evento):

void CSquaresView::OnLButtonDown(UINT nFlags, CPoint point)

{
CView::OnLButtonDown(nFlags, point);
…
}

33
Le viste “scrollabili” ed altri tipi di viste
La vista che abbiamo utilizzato nel programma di esempio (derivata da CView) non
dispone di funzionalita’ di scroll del contenuto della finestra; se avessimo voluto disporre
di tale funzionalita’ avremmo dovuto derivare la nostra classe vista da un’altra classe
denominata CScrollView; la classe CscrollView si occupa di gestire la maggior parte
delle operazioni necessarie per gestire lo scorrimento del contenuto della vista tanto da
poter utilizzare una generica funzione OnDraw sia su di una vista scrollabile, sia su di
una vista fissa.
Esistono inoltre altri tipi di viste che e’ possibile utilizzare all’interno dell’architettura
Document/View, le piu’ importanti sono:

CHtmlView utilizzata per visualizzare documenti HTML all’interno della vista

CTreeView utilizzata per visualizzare documenti in maniera gerarchica

E’ possibile inoltre crearsi tipi personalizzati di viste per particolari esegenze applicative
semplicemente derivando una propria classe vista dalla classe base CCtrlView.

Le applicazioni MDI (Multiple Document Interface)

In questo capitolo evidenzieremo solo le caratteristiche principali delle applicazioni MDI
ma non ci addentreremo nei dettagli relativi allo sviluppo data la complessita’ di questo
tipo di applicazioni (anche se in fondo la maggior parte delle applicazioni Windows che
vengono realizzate sono proprio di questo tipo: vedi i pacchetti che compongono
Microsoft Office e molte altri software commerciali).
Una applicazione MDI puo’ supportare viste multiple sullo stesso documento, piu’
documenti dello stesso tipo attivi allo stesso tempo e perfino tipi multipli di documento
visualizzati tramite viste differenti.

Queste sono le caratteristiche principali di una applicazione MDI:

- si possono avere piu’ documenti aperti in editing allo stesso tempo mentre le
applicazioni SDI richiedono che il documento corrente venga chiuso prima di
poterne aprire un altro.
- Talvolta si possono avere applicazioni MDI che supportano diversi tipi di
documento contemporaneamente (ad esempio un gestionale integrato che
permette di lavorare allo stesso tempo su di un testo, un foglio di calcolo, un
archivio, un grafico).
- Le applicazioni MDI dispongono di un menu’ Windows che offre dei comandi per
selezionare la vista attiva e disporre le varie finestre contenenti le varie viste.
- Le applicazioni MDI che supportano diversi tipi di documento
contemporaneamente devono gestire diversi tipi di menu (uno per ogni tipologia
di documento).
- Le applicazioni SDI sono dotate di una sola finestra contenitore e della vista,
mentre le applicazioni MDI hanno all’interno della finestra contenitore altre

34
 finestre che contengono le diverse viste e che possono essere ognuna
ridimensionata, dockata, minimizzata, chiusa ecc.

Fortunatamente il framework MFC offre un notevole supporto al programmatore nella

realizzazione di applicazioni MDI, mantendo oltretutto le stesse modalita’ impiegate per
lo sviluppi di applicazioni SDI, con alcune differenze:

- Le applicazioni MDI derivano la finestra principale (quella che fa da container a

tutte le altre) da CMDIFrameWnd invece che da CFrameWnd
- Le finestre multiple che contengono le varie viste vengono derivate da
CMDIChildWindow
- Il template da cui vengono create le applicazioni MDI e’ denominato
CMultiDocTemplate invece di CSingleDocTemplate
- Le applicazioni MDI hanno in genere piu’ di un menu nel file di risorse, e
solitamente gestiscono menu diversi per quando nessun documento e’ aperto e
quando e’ aperto almeno un documento

Le funzionalita’ di stampa
Implementare funzionalita’ di stampa in applicazioni Windows tradizionali (SDK) e’
sempre stato un compito di una certa difficolta’, che rendeva la progettazione dei report e
delle stampe una attivita’ piuttosto onerosa per il programmatore.
Tutto questo per i molti fattori che entrano in gioco quando si tratta di stampare in un
ambiente Windows, come la paginazione, il fatto di poter essere in grado di annullare una
stampa in corso ed anche perche’ spesso si tratta di stampare output grafico e non solo
testo.
Inoltre altro codice andava scritto se si voleva dotare le applicazioni anche della
funzionalita’di “Preview di stampa”.
L’architettura MFC attenua moltissimo la difficolta’ di implementazione di procedure di
stampa nelle applicazioni Windows, in particolare se utilizzano l’architettura
Document/View.
Infatti MFC mette a disposizione del programmatore un device context generico che puo’
essere rediretto facilmento su stampante, si prende cura della possibile interruzione della
stampa in corso e gestisce perfino in maniera molto semplice la funzionalita’ di preview.

Sebbene il metodo OnDraw visto nel capitolo 2.5 permetta di inviare l’output sia a video
che su stampante e’ spesso necessario utilizzare l’altro metodo chiamato OnPrint in
quanto comunque quando si stampa si devono gestire informazioni aggiuntive come
magari il numero di pagina o una intestazione.

I passi necessari per effettuare la stampa da una applicazione MFC document/view sono I
seguenti:

Effettuare l’override della funzione virtuale OnPreparePrinting della classe CView.

35
BOOL CMyView::OnPreparePrinting(CPrintInfo* pInfo)
{
pInfo->SetMaxPage(10);
return DoPreparePrinting(pInfo);
}

In questa forma minima la funzione OnPreparePrinting non fa altro che aprire la dialog
box relativa alle impostazioni di stampa e ritornare un puntatore ad un device context di
tipo stampante; e’ consigliato inoltre chiamare la funzione SetMaxPage per comunicare
al sottosistema di stampa il numero massimo di pagine.

Dato che il numero di pagine puo’ non essere noto a priori e spesso dipende dalla
dimensione del documento si puo’ omettere tale parametro nella OnPreparePrinting e
sfruttare l’evento successivo OnBeginPrinting per calcolare il numero effettivo di
pagine:

void CMyView::OnBeginPrinting(CDC *pDC, CprintInfo *pInfo)

{
int nPageHeight = pDC->GetDeviceCaps(VERTRES);
int nDocLength = GetDocument()->GetDocLength();
int nMaxPage = max (1, (nDocLength + (NpageHeight –1))
/ nPageHeight);
pInfo->SetMaxPage(nMaxPage);
}

L’evento OnBeginPrinting viene attivato subito prima di iniziare la stampa, quindi il

sistema ha gia’ allocato le risorse necessarie ed e’ quindi possibile calcolare con esattezza
il numero delle pagine da stampare.

Una volta chiamate queste due funzioni di preparazione della stampa, per ogni pagina,
vengono chiamati i metodi:

void CMyView::OnPrepareDC(CDC *pDC, CprintInfo *pInfo)

{
}

void CMyView::OnPrint(CDC *pDC, CprintInfo *pInfo)

{
// ad esempio
PrintHeader(pDC);
PrintPageNumber(pDC, pInfo->m_nCurPage);
OnDraw(pDC);
}

36
l’override di queste due funzioni virtuali e’ necessario solamente nel caso in cui si voglia
stampare qualcosa oltre il contenuto di default (cio’ che viene stampato nel metodo
OnDraw), come ad esempio il numero di pagina oppure un’intestazione.

Alla fine del processo di stampa viene chiamato il metodo:

void CMyView::OnEndPrint(CDC *pDC, CprintInfo *pInfo)

{
}

Se deve essere effettuata qualche operazione al termine della stampa puo’ essere utile
effettuare l’override del metodo OnEndPrint.

Se ad un’applicazione MFC document/view e’ stata aggiunt la funzionalita’ di stampa, la

fpossibilita’ di effettare anche il preview e’ implementabile in maniera veramente
semplice collegando la voce di menu “Print Preview” al metodo
CView::OnFilePrintPreview.

Questa e’ la mappa dei messaggi tratta dall’applicazione di esempio 2_2_7 che mostra
quanto poco codice sia necessario aggiungere per implementare la funzionalita’ di
preview di stampa:

ON_COMMAND(ID_FILE_PRINT_PREVIEW,CView::OnFilePrintPreview)

Parte 3 : Oltre l’interfaccia

La gestione dei timer e del ciclo “Idle”

I Timer
Spesso capita di dover sviluppare applicazioni che devono eseguire operazioni non in
risposta a determinati input da parte dell’utente, ma ad intervalli regolari; un esempio
puo’ essere un’applicazione che effettua il monitoraggio delle risorse di un server ogni 5
minuti, oppure un programma che effettua la pulizia di alcuni file temporanei ogni n
secondi ecc.
In questi casi e’ necessario avere a disposizione un oggetto chiamato “timer” la cui
funzione e’ quella di “svegliare” un’applicazione una volta trascorso un certo intervallo
di tempo (solitamente espresso in millisecondi).
Per gestire i timer con MFC e’ necessario utilizzare due funzioni CWnd::SetTimer e
CWnd::KillTimer il cui significato e’ abbastanza ovvio.
Ogni volta che l’intervallo fissato e’ trascorso il timer deve comunicarlo all’applicazione
e per fare questo possono essere utilizzati due metodi:

37
 - inviando ad una finestra specificata il messaggio WM_TIMER
- chiamando una funzione definita all’interno dell’applicazione detta “funzione di
callback”
Gestire il messaggio WM_TIMER probabilmente e’ il metodo piu’ semplice, ma se si
hanno timer multipli in un’applicazione e’ preferibile utilizzare il metodo della funzione
di callback.

NOTA BENE: Windows non e’ un sistema operativo “real time” quindi un timer
settato ad un intervallo di 500 millisecondi non mi da nessuna garanzia che scattera’
con la massima precisione ogni 500 millisecondi; diciamo piuttosto che la media,
dopo un centinaio di attivazioni, convergera’ verso tale valore.

Per creare un timer si utilizza la funzione SetTimer passandogli un numero identificativo

del timer, l’intervallo in millisecondi ed il metodo di gestione (NULL come ultimo
parametro indica l’utilizzo del messaggio WM_TIMER altrimenti e’ necessario passare il
nome della funzione di callback):

// in genere il timer viene creato al momento

// della creazione della finestra principale
Int CMainWindow::OnCreate (LPCREATESTRUCT lpcs)
{
…
// creiamo il timer 1 con intervallo 1 secondo
if (!SetTimer (1, 1000, NULL))
{
MessageBox(“Errore nella SetTimer”);
Return –1;
}
return 0;
}

// dichiariamo nella message map il messaggio del timer

BEGIN_MESSAGE_MAP(CMainWindow, CFrameWnd)
…
ON_WM_TIMER()
ON_WM_CLOSE()
…
END_MESSAGE_MAP()

38
// funzione che risponde al messaggio WM_TIMER
// da notare che input riceve l’identificativo del timer
Void CMainWindow::OnTimer(UINT nTimerId)
{
// operazioni da svolgere ogni secondo
}

// il timer viene distrutto prima della chiusura

// della finestra dell’applicazione
Void CMainWindow::OnClose()
{
KillTimer(1);
}

Per settare un timer in modo da utilizzare la funzione di callback:

SetTimer (1, 1000, TimerProc);

Void CALLBACK TimerProc (HWND hWnd, UINT nMsg,

UINT nTimerId, DWORD dwTime)
{
// il parametro hWnd contiene l’handle della
// finestra in cui era stato definito il timer
// nMsg contiene l’id di messaggio WM_TIMER
// nTimerId contiene l’identificativo del timer
// dwTime contiene il numero di millisecondi
// passati dal momento dell’avvio di Windows (!)
}

Le elaborazioni durante il ciclo di “Idle”

Una applicazione Windows generica trascorre la maggior parte del suo tempo ad
elaborare i vari messaggi in arrivo dal sistema operativo in risposta ad operazioni di input
da parte dell’utente finale.
Quando nella coda non sono disponibili messaggi una applicazione si mantiene in uno
stato detto di “idle” (inattivita’); per ottimizzare l’efficienza di una applicazione si puo’
pensare di utilizzare questo momento di inattivita’ per portare avanti delle elaborazioni in
background che non hanno bisogno di interagire con l’utente (ad esempio la pulizia di file
temporanei o la scrittura di informazioni non critiche in un file di log ecc.).
La classe applicazione MFC CWinApp mette a disposizione per questo tipo di
elaborazioni una routine di gestione chiamata OnIdle in cui si puo’ posizionare del
codice da eseguire durante il ciclo di “idle”.

39
// chiamata automaticamente durante il ciclo di idle
// lCount indica il numero di volte che la funzione
// di idle e’ stata chiamata dall’ultimo messaggio
// processato dall’applicazione
BOOL CMyApp::OnIdle (LONG lCount)
{
// ATTENZIONE se si omette la chiamata al metodo
// OnIdle di CWinApp si compromette il funzionamento
// di tutta l’applicazione
CWinApp::OnIdle(lCount)
// adesso possiamo eseguire le nostre operazioni in
// background
DoIdleProcessing();
Return TRUE;
}

Sebbene la tecnica dell’utilizzo del ciclo di idle possa apparire interessante e conveniente
nelle applicazioni moderne in genere si tende ad utilizzare la tecnica del “multithreading”
che vedremo nel prossimo capitolo; puo’ capitare comunque di utilizzare questa tecnica
se le operazioni da compiere in background sono semplici e non si vuole utilizzare risorse
inutilmente per creare un nuovo thread, oppure se la nostra applicazione deve girare
ancora in ambiente 16 bit (Windows 3.11 e precedenti) dove non esiste supporto per il
multithreading.

(WriteProfileString / GetProfileString)
(Ctime / Ctime::GetCurrentTime)

Gestione dei “Thread”

Nell’ambiente Windows a 32 bit un’applicazione in esecuzione viene definita
“processo”, ed ogni processo contiene uno o piu’ “thread” in esecuzione; un thread puo’
essere definito come un percorso di elaborazione all’interno del codice di un programma
che si porta dietro i suoi dati e le sue risorse (stack, registri, heap e cosi’ via).
Solitamente nelle applicazioni tradizionali si ha un solo thread che tende quindi ad
identificarsi completamente con il processo; un sistema operativo si definisce
“multitasking” se e’ in grado di eseguire piu’ processi contemporaneamente mentre
un’applicazione si definisce “multithread” se e’ formata da piu’ thread in esecuzione
contemporanea (parallela).
Nonostante gli evedenti benefici di questo tipo di applicazioni (un thread puo’ occuparsi
di interagire con l’utente mentre un altro effettua le necessarie elaborazioni e calcoli
dando la possibilita’ al programma di rimanere sempre pronto a rispondere alle richieste
di input dell’utente e non bloccandosi durante le elaborazioni), i programmi
“multithread” sono molto difficili da scrivere rispetto ai programmi tradizionali ed e’
necessario che il programmatore inizi a ragionare in maniera “parallela”.
Il problema risiede nel fatto che si e’ portati a ragionare come programmatori in maniera
“sincrona”, mentre per definizione i programmi multithread sono “asincroni” e quindi e’

40
necessario gestire la sincronizzazione fra il task principale dell’applicazione ed i vari
sottothread per evitare tutta una serie di errori che possono scaturire dal parallelismo (ad
esempio il programma principale tenta di accedere ai risultati di una elaborazione quando
il thread che elabora non e’ ancora terminato, oppure le risorse necessarie ad un thread
per un’elaborazione sono “bloccate” da un altro ecc.).

La programmazione multithread si porta dietro inoltre tutta una serie di concetti e

considerazioni che non possono essere ignorate qualora si decida di utilizzare questa
tecnica:

Priorita’
Ad un thread puo’ essere utile assegnare una priorita’ maggiore rispetto ad un altro
perche’ l’elaborazione che sta svolgendo e’ di importanza critica per l’applicazione.

Sincronizzazione tra thread e tra thread e applicazione principale

L’applicazione principale deve avere a disposizione meccanismi per gestire la
sincronizzazione dei vari thread ed inoltre devono essere usati strumenti per
regolamentare l’accesso alle risorse tra i vari thread in esecuzione; Windows supporta i
seguenti meccanismi di sincronizzazione:

- Sezioni critiche (l’accesso ad alcune risorse come variabili o strutture dati

condivise tra piu’ thread vengono serializzate, ovvero un solo thread alla volta
puo’ accedervi)
- Mutex (contrazione di “mutuamente esclusivo”; aree di memoria condivise tra
piu’ thread anche di processi differenti sono accessibili in maniera esclusiva da un
solo thread per volta)
- Eventi (possono essere definiti come comandi che vengono inviati ai thread per
bloccarne o riprenderne l’esecuzione)
- Semafori (i semafori sono utlizzati per regolamentare l’accesso a risorse a
disponibilita’ limitata, ovvero risorse a cui non possano accedere piu’ di n thread;
il semaforo si occupa di tenere il conteggio e quando il numero di accessi
consentiti e’ finito impedisce ogni accesso alla risorsa fino a che un thread non
segnala al semaforo che ha intenzione di rilasciarla)

L’esempio 2_3_1 dimostra un possibile utilizzo per un’applicazione multithread; in

questo esempio un thread si occupa di effettuare un complesso calcolo matematico
mentre il thread principale si occupa di gestire l’interfaccia utente.
Se proviamo infatti a far calcolare al programma il numero di primi da 2 a
100.000.000 il thread che effettua il calcolo impieghera’ un certo tempo ma possiamo
notare che, grazie all’architettura multithread, l’interfaccia utente non e’ bloccata fino
alla fine del calcolo ma rimane utilizzabile (ovvero risponde agli input dell’utente).

41
// alla pressione del comando start viene avviato il nuovo
// thread
void CSieveDlg::OnStart()
{
…
// al thread di calcolo viene passata una struttura
// contenente i parametri necessari per il calcolo
THREADPARMS* ptp = new THREADPARMS;
ptp->nMax = nMax;
ptp->hWnd = m_hWnd;
// oltre ai parametri viene passato il nome della
// funzione che implementa il thread vero e proprio
AfxBeginThread (ThreadFunc, ptp);
}

// mappa dei messaggi dell’applicazione principale

BEGIN_MESSAGE_MAP(CSieveDlg, CDialog)
…
ON_MESSAGE (WM_USER_THREAD_FINISHED, OnThreadFinished)
END_MESSAGE_MAP()

// l’evento OnThreadFinished viene attivato al termine

// dell’elaborazione del thread grazie al messaggio
// definito nella message map (WM_USER_THREAD_FINISHED)
// il messaggio viene inviato dal thread stesso una volta
// terminata l’elaborazione per fare in modo che
// l’applicazione principale possa visualizzare il
// risultato
LONG CSieveDlg::OnThreadFinished (WPARAM wParam, LPARAM
lParam)
{
// una volta finito il thread di calcolo visualizziamo
// il risultato
SetDlgItemInt (IDC_RESULT, (int) wParam);
GetDlgItem (IDC_START)->EnableWindow (TRUE);
return 0;
}

42
// il vero e proprio thread di calcolo
UINT ThreadFunc (LPVOID pParam)
{
// lettura dei parametri ricevuti
THREADPARMS* ptp = (THREADPARMS*) pParam;
int nMax = ptp->nMax;
HWND hWnd = ptp->hWnd;
delete ptp;

// si effettua il calcolo
int nCount = Sieve (nMax);

// si segnala all’applicazione principale che

// l’elaborazione e’ terminata
::PostMessage (hWnd, WM_USER_THREAD_FINISHED, (WPARAM)
nCount, 0);
return 0;
}

Introduzione alle tecniche di accesso ai dati

L’architettura corrente per l’accesso ai dati messa a disposizione da Microsoft per i vari
ambienti Windows e’ definita MDAC (Microsoft Data Access Components), ed e’
attualmente distribuita in un pacchetto arrivato alla versione 2.7
I componenti di accesso ai dati includono ActiveX Data Objects (ADO) che verra’
trattato in dettaglio nel capitolo 3.4, OLE DB e Open Data Base Connectivity (ODBC).
Applicazioni scritte utilizzando i vari linguaggi Microsoft (Visual C++, Visual Basic,
ASP ecc.) possono utilizzare questi componenti per accedere ad una vasta gamma di
fonti dati, sia relazionali che non relazionali, attraverso reti locali (LAN) oppure
attraverso Internet.

ActiveX Data Objects (ADO)

ADO fornisce una libreria di accesso ai dati ad alte prestazioni e dalle basse richieste in
termini di risorse come memoria e disco.
Fornisce inoltre un’interfaccia di facile utilizzo verso OLE DB, il quale si occupa dello
strato sottostante e del vero e proprio accesso ai dati; ADO e’ realizzato tramite la
tecnologia COM per poter essere impiegato alll’interno di qualsiasi applicazione
indipendentemente dal linguaggio con cui e’ scritta.

43
OLE DB
OLE DB e’ un set di interfacce che espongono dati da una varieta’ di fonti relazionali e
non relazionali, attraverso l’utilizzo della tecnologia COM.
Fornisce inoltre un’interfaccia verso i driver ODBC per garantire uniformita’ di supporto
e di accesso verso una vasta gamma di DBMS relazionali.

Open Database Connectivity (ODBC)

L’interfaccia ODBC di Microsoft permette alle applicazioni di poter accedere ai piu’
popolari database relazionali tramite un metodo di uniforme ed indipendente dal vero e
proprio DBMS che contiene i dati.
Tramite la tecnologia ODBC e’ possibile creare applicazioni che utilizzano statement
SQL che non devono essere modificate nel momento in cui viene cambiato il DBMS
sottostante.

ADO e gli OLE DB Provider

Tra le varie tecnologie di accesso ai database elaborate da Microsoft nel corso delle varie
versioni Windows e’ interessante soffermarsi su quella chiamata OLE DB.
OLE DB definisce un insieme di interfacce COM che forniscono alle applicazioni un
metodo uniforme di accesso ai dati memorizzati nelle piu’ diverse forme.
L’architettura OLE DB rende trasparente alle applicazioni che accedono alla fonte dati
tramite ADO, gli ulteriori strati intermedi necessari per arrivare dallo statement SQL
all’interno del programma all’effettivo interfacciamento con il DBMS ed al recupero dei
dati attraverso una rete locale o perfino attraverso Internet.
Un driver OLE DB che permette ad ADO di interagire direttamente con una fonte dati e’
definito “OLE DB Provider”.
Consideriamo ad esempio i seguenti scenari che possono verificarsi nel momento in cui si
voglia effettuare una query:

- I dati risiedono in un database relazionale per cui esiste un driver ODBC ma per
cui non e’ disponibile un provider OLE DB nativo; l’applicazione utilizza ADO
per parlare con l’OLE DB provider per ODBC il quale poi pensa ad utilizzare il
driver ODBC appropriato; il driver passa lo statement SQL al database il quale
restituisce i dati richiesti.
- I dati risiedono in in database Microsoft SQL Server per cui e’ disponibile un
provider OLE DB nativo; l’applicazione utilizza ADO per parlare direttamente
con l’OLE DB provider per SQL Server e nessun altro strato intermedio e’
necessario
- I dati risiedono in Microsoft Exchange, il quale ha un OLE DB provider ma che,
non essendo un DBMS relazionale, non ha un motore in grado di comprendere
statement SQL; l’applicazione utilizza ADO per parlare con l’OLE DB Provider
per Echange il quale si occupa di tradurre gli statement SQL in query che possano
essere comprese da Exchange
- I dati risiedono nel file system di Windows 2000 (NTFS) sotto forma di
documento; l’accesso avviene tramite un provider OLE DB nativo che si

44
 appoggia al servizio di Microsoft Indexing Service il quale estre i dati richiesti dal
proprio repository.

Come si puo’ vedere da questi esempi, un’applicazione che utilizza ADO puo’ effettuare
interrogazioni su una vasta gamma di fonti dati (non necessariamente database
relazionali) senza effettuare cambiamenti di rilievo alla struttura dell’applicazione ed al
modo di utilizzare gli oggetti ADO; tutto questo e’ possibile grazie all’architettura OLE
DB.

Accesso ai database tramite ADO

ADO (ActiveX Data Object) e’ una libreria basata su tecnologia COM che fornisce agli
sviluppatori un potente modello di programmazione per accedere ad una grande varieta’
di fonti dati attraverso interfacce di sistema OLE DB.
L’utilizzo piu’ comune di ADO e’ per effettuare query e aggiornamenti sulle tabelle dei
piu’ diffusi database relazionali (Oracle, SQL Server, DB2, Informix ecc.) tramite il
linguaggio SQL.
ADO e’ formato da una serie di nove oggetti e di quattro “collections” attraverso i quali
e’ possibile utilizzarne le funzionalita’:

Oggetto o Collezione Descrizione

Connection object Rappresenta la connessione tra un applicazione
client ed una generica fonte dati
Command object Usato per definire comandi SQL che poi vengono
applicati ad una fonte dati
Recordset object Rappresenta l’insieme dei record risultato di uno
statement SQL oppure l’intero contenuto di una
tabella di un database; ogni recordset e’ formato da
righe e da colonne (campi della tabella)
Record object Rappresenta una singola riga all’interno di un
recordset
Stream object Rappresenta un flusso generico di dati binari o di
tipo testo
Parameter object Contiene i parametri da associare ad una query o
stored procedure che richiede argomenti dinamici
Field object Rappresenta una colonna (campo) all’interno di un
oggetto Recordset
Property object Rappresenta un container di proprieta’ di ADO
definite dinamicamente a seconda delle
caratteristiche del provider con cui si accede alla
fonte dati
Error object Contiene i dettagli relativi agli errori di accesso ai
dati
Fields collection Contiene tutti gli oggetti Field di un Recordset o di
un Record
Properties collection Contiene tutti gli oggetti Property di una particolare
istanza di un oggetto
Parameters collection Contiene tiutti gli oggetti Parameter di un oggetto
Command
Errors collection Contiene tutti gli oggetti Error avvenuti durante una
operazione sulla fonte dati

45
Il seguente diagramma mostra graficamente la gerarchia degli oggetti che compongono
ADO:

L’esempio 2_3_4 provvede ad illustrare le caratteristiche fondamentali di ADO

illustrando come avviene la connessione ad un DB Access, l’apertura di un recordset su
di una tabella del db e lo scorrimento di tutti i record della tabella che vengono utilizzati
per riempire una listbox.

Per poter utilizzare ADO all’interno di una applicazione C++ e’ necessario importare la
libreria ADO (msado15.dll) tramite l’utilizzo della nuova direttiva di preprocessore
import; inoltre per evitare collisioni tra ADO ed MFC e’ necessario specificare la
clausola no_namespace e rinominare la define EOF in EndOfFile.

#import
"c:\Program Files\CommonFiles\System\ADO\msado15.dll"
no_namespace rename("EOF", "EndOfFile")

Il primo passo per poter accedere ad un data base tramite ADO e’ quello di dichiarare ed
istanziare una variabile di tipo puntatore a Connection:

// dichiariamo un puntatore ad un oggetto ADO Connection

// e ad un oggetto ADO RecordSet
_ConnectionPtr pConn("ADODB.Connection");
_RecordsetPtr pRst("ADODB.Recordset");

46
// stringa di connessione ad Access
// apriamo la connessione tramite l’utilizzo del metodo
// Open dell’oggetto Connection
pConn->Open("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=d:\\test.mdb;", "", "", adConnectUnspecified);

Dato che ADO puo’ connettersi a qualsiasi fonte dati e’ necessario specificare all’interno
del metodo Open dell’oggetto Connection a quale database ci vogliamo connettere
(OLEDB Provider) e quale e’ il nome della fonte dati che identifica il vero e proprio db.
Nel caso di Microsoft Access come identificativo della fonte dati possiamo utilizzare
direttamente il nome del file mdb che contiene il database, ma se ad esempio volessimo
utilizzare ADO per accedere a SQL Server avremmo dovuto fornire dei parametri di
connessione diversi:

// stringa di connessione per una fonte dati SQL Server

Provider=sqloledb;Data Source='MySqlServer'
Initial Catalog='pubs';Integrated Security='SSPI'

Una volta inizializzato l’oggetto ADO Connection e’ possibile inizializzare un oggetto

ADO RecordSet utilizzando il puntatore alla connessione:

// apre il recordset
pRst->Open(
"countries", // nome tabella db
_variant_t((IDispatch *) pConn, true),
adOpenStatic, // recordset statico
adLockReadOnly, // la tabella e’ lockata
adCmdTable); // stiamo leggendo una tabella

se si vuole aprire un recordset che contiene il risultato di una SELECT SQL e’

necessario modificare gli argomenti del metodo Open in questo modo:

pRst->Open(
"SELECT * FROM countries ", // SQL
_variant_t((IDispatch *) pConn, true),
adOpenStatic,
adLockReadOnly,
1); // stiamo passando un’istruzione SQL

una volta che il recordset e’ aperto abbiamo a disposizione tutto l’insieme dei record della
tabella (o dello stament SQL) e possiamo quindi scorrere e posizionarci all’interno del
RecordSet:

47
// si posiziona sul primo elemento del recordset
pRst->MoveFirst();

while (!pRst->EndOfFile)
{
// Legge il campo ‘Country’ dal recordset
vtCountry =
pRst->GetFields()->GetItem("country")->GetValue();

pRst->MoveNext();
}
e’ necessario sempre ricordarsi di chiudere sia l’oggetto recordset che la connessione una
volta terminate le operazioni sul database:

pRst->Close();

pConn->Close();

Per poter eseguire uno statement SQL che effettui una modifica al database
(INSERT,UPDATE o DELETE) e’ necessario utilizzare l’oggetto ADO Command:

// inizializza lo statement SQL di aggiornamento

bstr_t strSQLChange("UPDATE Titles SET Type = "
"'self_help' WHERE Type =
'psychology'");

_ConnectionPtr pConnection("ADODB.Connection");
_CommandPtr pCmdChange("ADODB.Command");
_RecordsetPtr pRstTitles("ADODB.RecordSet");

// apertura connessione
…
// apertura del recordset
pRstTitles->Open ("Titles",
_variant_t((IDispatch *) pConnection,true), adOpenStatic,
adLockOptimistic, adCmdTable);

// Inizializza l’oggetto Command con lo statement SQL

pCmdChange->ActiveConnection = pConnection;
pCmdChange->CommandText = strSQLChange;

// esegue l’oggetto Command sul recordset pRstTitles

ExecuteCommand(pCmdChange, pRstTitles);

48
In alternativa il metodo execute puo’ essere applicato direttamente all’oggetto
Connection passandogli una stringa contenente lo statement SQL da eseguire:

pConnection->Execute(strSQLRestore, NULL,
adExecuteNoRecords);

// Dopo l’esecuzione di uno statement SQL che modifica un

// recordset e’ possibile rigenerare il recordset chiamando
// il metodo Requery
pRstTitles->Requery(adCmdUnknown);

Gli oggetti COM

L’acronimo COM (Component Object Model) identifica una serie di tecnologie elaborate
da Microsoft che permetteno di costruire “oggetti” indipendenti da qualsiasi linguaggio di
programmazione.
Il linguaggio C++ e’ fortemente orientato al concetto di “riuso” di codice sia in forma
sorgente che sotto forma di librerie di classi gia’ precompilate; l’unico svantaggio e’
rappresentato dal fatto che tali classi siano utilizzabili solo all’interno di programmi C++
e quindi di conseguenza da programmatori C++.
La tecnologia COM spinge all’estremo il concetto di “riuso di moduli eseguibili”,
permettendo di costruire “oggetti COM”, scritti con un qualsiasi linguaggio di
programmazione, che una volta eseguiti potranno offrire funzionalita’ ad un altro
programma scritto in un qualsiasi linguaggio di programmazione.
Questo significa che un programma C++ potra’ ususfruire dei servizi messi a
disposizione da un oggetto COM scritto in Visual Basic e viceversa.
Le funzioni “messe a disposizione” da un oggetto COM vengono chiamate “metodi”;
piu’ metodi vengono raggruppati in “interfacce” che possono essere accedute tramite
“puntatori ad interfacce”.
I metodi di un oggetto COM vengono raggruppati in interfacce diverse a seconda della
funzione svolta dai vari metodi (ad esempio un’interfaccia IMath puo’ contenere i metodi
Add e Subtract), quindi un oggetto COM puo’ avere piu’ di un’interfaccia.
Ogni oggetto COM deve comunque implementare una particolare interfaccia denominata
“IUnknown” che deve contenere sempre i metodi QueryInterface, AddRef e Release;
questi metodi servono rispettivamente per:

QueryInterface Ritorna un puntatore ad un altra interfaccia dell’oggetto

AddRef Serve per segnalare che un client sta utilizzando l’oggetto
Release Serve per segnalare che un client sta rilasciando l’oggetto

Gli oggetti COM sono identificati univocamente tramite valori a 128 bit; il Class Id
identifica l’oggetto COM e deve essere utilizzato per crearne un’istanza, e l’Interface Id
identifica una delle interfacce all’interno di un oggetto COM.

Esempio:

49
// dichiariamo un puntatore all’interfaccia
IMath *pMath;

// creiamo un’istanza dell’oggetto COM tramite

// Class ID e Interface ID e assegniamo l’indirizzo
// dell’interfaccia IMath al puntatore pMath
CoCreateInstance(CLSID_Object, NULL, CLSCTX_SERVER,
IID_IMath, (void **) &pMath);

// a questo punto possiamo utilizzare l’oggetto COM

// tramite l’interfaccia pMath
Int sum;

PMath->Add (2, 2, &sum);

// rilasciamo l’interfaccia
PMath->Release();

COM Servers
Un programma eseguibile che implementa al suo interno un oggetto COM e’ chiamato
“COM Server”; per poter utilizzare un oggetto implementato all’interno di un COM
Server e’ necessario che tale oggetto sia “registrato” (ovvero esista all’interno del registro
di sistema un’associazione tra il CLASS ID ed il nome dell’eseguibile al cui interno e’
implementato l’oggetto COM).
In una prima release della tecnologia COM era possibile, da un client, istanziare solo
oggetti COM che erano registrati sulla stessa macchina, ma successivamente fu introdotta
un’evoluzione (chiamata DCOM, Distributed COM) che permetteva ad un oggetto di
girare su di un qualsiasi COM server all’interno di una rete.
Tramite un meccanismo chiamato “marshaling” la locazione dell’oggetto DCOM e’
completamente trasparente al programma che lo utilizza, nel senso che e’ la tecnologia
COM che risolve la chiamata al metodo remoto sia che l’ogggetto si trovi sullo stesso
computer, all’interno di una LAN oppure su di un server remoto a cui si accede tramite
Internet.

Object Linking and Embedding (OLE)

E’ importante sottolineare che la tecnologia COM deriva dal meccanismo chiamato OLE
(Object Linking and Embedding); questa tecnologia che nacque insieme alla prime
versioni di Windows permetteva di includere oggetti creati da un’applicazione all’interno
di un’altra che agiva da contenitore (un caso classico consisteva nell’includere un foglio
Excel all’interno di un documento Microsoft Word, e secondo la terminologia OLE si
definiva Excel un “OLE Server” e Word un “OLE Container”).
La tecnologia OLE, prima di essere inclusa all’interno del mondo COM, si e’ evoluta in
quelli che venivano definiti “Active Documents” ovvero una tecnica che permetteva ad
applicazioni di tipo “Active Document Containers” (come Microsoft Internet Explorer) di

50
incorporare al suo interno documenti creati da “Active Document Serves” come Word ed
Excel.

ActiveX
Un’altra delle tecnologie COM-based di Microsoft che vale la pena di menzionare e’
denominata “ActiveX”; questo tipo di tecnologia e’ nota soprattutto perche’ permette di
realizzare controlli particolari (denominati controlli ActiveX) i quali sono oggetti COM a
tutti gli effetti che hanno la particolarita’ di poter essere utilizzati indifferentemente
all’interno di un’applicazione VC++ o Visual Basic e allo stesso tempo all’interno di una
pagina Internet (e possono essere manipolati tramite linguaggi di scripting come
VBScript).

COM e MFC
Il ruolo di MFC all’interno della tecnologia COM, e’ quello di fornire al programmatore
VC++ un’infrastruttura applicativa che semplifichi il piu’ possibile la realizzazione di
oggetti COM (che siano ActiveX o OLE Server o Active Documents).
Senza il supporto di MFC la realizzazione di un oggetto COM si rivelerebbe un compito
di estrema difficolta’ dato che lo standard COM prevede che l’oggetto implementi tutta
una serie di interfacce (e di metodi) predefinite che regolamentano il protocollo di
chiamata e di accesso all’oggetto.

Tecniche di “Automazione”
Con “automazione” si definisce una tecnologia “COM based” che permette ad
un’applicazione Windows di esporre le proprie feature ad un’applicazione client scritta in
Visual Basic, VBA oppure VBScript; indirettamente e’ possibile utilizzare l’automazione
anche tramite il linguaggio C++.
Esporre le proprie feature significa che il comportamento e le funzionalita’ di un
applicazione possono essere “programmati” da un’applicazione esterna tramite l’utilizzo
di un linguaggio di scripting.
Le applicazioni che offrono questa possibilita’ sono definite “automation servers”,
mentre quelle che ne fanno uso vengono denominate “automation clients”.
In genere l’automazione viene usata per permettere ad una applicazione di interagire con
uno dei pacchetti di Office; ad esempio per esportare i dati in un foglio Excel oppure in
un documento Word, oppure per realizzare un grafico appoggiandosi alla potente
capacita’ di Excel di produrre grafici.

Solitamente un oggetto COM espone interfacce e metodi, mentre un “automation

server” espone metodi e proprieta’ (attributi).

La scrittura di client di automazione e’ veramente semplice se si utilizzano linguaggi che

supportano direttamente al loro interno tale tecnologia (nascondendo all’utente tutta la
complessita’ COM che sta sotto) come il Visual Basic e il VB Script:

51
(esempio Visual Basic)
Dim math as Object
Set math = CreateObject(“Math.Object”)
// impostiamo una proprieta’ dell’oggetto
Math.base = 10
// accediamo al metodo add dell’oggetto
Sum = math.add(2,2)
Set math = nothing

Questo esempio scritto in Visual Basic mostra l’estrema semplicita’ con cui si puo’
accedere ad un automation server chiamato Math.Object.
Il linguaggio Visual C++ non dispone di tutti i meccanismi del Visual Basic che
facilitano la scrittura di automation client, rendendo quindi la scrittura di tali applicazioni
un compito molto piu’ complesso (e spesso anche inutile dato che si puo’ scrivere tali
client con linguaggi piu’ adatti e gia’ orientati allo “scripting”).

Dove l’accoppiata MFC / Visual C++ si rivela vincente e’ nella scrittura di server di
automazione, la quale diventa un’operazione alquanto semplice in VC++ grazie
soprattutto allo Wizard che si occupa di generare gran parte del codice necessario a
costruire l’infrastruttura di automazione.

In effetti la creazione di un semplicissimo server di automazione come quello utilizzato

dall’esempio scritto in Visual Basic e’ molto semplice se ci si avvale del potente supporto
offerto da MFC e dallo Wizard; i passi da seguire per la sua creazione sono:

- Utilizzare MFC App Wizard per creare un nuovo progetto chiamato AutoMath;
scegliere Single Document Interface (SDI) e cliccare sul supporto per
l’automazione (selezionando Automation e scegliendo Full Server).
- Nello step successivo (4) premere il bottone “advanced” ed indicare
“AutoMath.Object” nel campo “File Type ID”.
- Negli step successivi eliminare tutto quello che non serve (funzioni di stampa,
toolbar ecc.)
- Una volta generato lo scheletro dell’applicazione lanciare il Class Wizard da
View -> Class Wizard e spostarsi nella pagina Automation; selezionare la classe
CAutoMathDoc e cliccare su ‘Add Method’; denominare il metodo ‘Add’,
premere OK e poi su ‘Edit Code’ per aggiungere l’implementazione del metodo

Long CautoMath::Add(long a, long b)

{
return a + b;
}

- Se si desidera si possono aggiungere altri metodi analoghi con le stesse modalita’

(es. Subtract, Multiply ecc)
- Sempre all’interno della pagina Automation del Class Wizard cliccare su ‘Add
Property’ e selezionare get/set per creare una nuova proprieta’ denominata pi

52
 Double CautoMathDoc::GetPi()
{
return 3.1415926;
}

void CautoMathDoc::SetPi(double newValue)

{
SetNotSupported();
}

- Una volta definiti i metodi e le proprieta’ e’ sufficiente compilare l’automation

server ed eseguirlo almeno una volta per fare in modo che venga registrato.
- A questo punto e’ possibile da un linguaggio di scripting come Visual Basic o
Windows Scripting Host testare il server di automazione creato; per effettuare il
test con il VBScript creare un nuovo file di testo con estensione .vbs e scrivere del
codice di questo tipo:

Set mathObj = CreateObject(“Automath.Object”)

Sum = mathObj.add(2,2)
Msgbox (sum)
Msgbox (“pi = “ + cstr(mathObj.pi))

Per eseguire il codice VBS e’ sufficiente eseguire un doppio click sul file sorgente, dato
che il motore di scripting e’ integrato nei sistemi operativi Windows 2000 e Windows
XP.

Per un esempio piu’ complesso (e significativo) di automazione si prega di esaminare

l’esempio 2_3_3 che si compone di due applicazioni; un automation server che disegna
un grafico a torta ed un semplice automation client da cui e’ possibile variare i valori del
grafico disegnato dal server direttamente durante l’esecuzione.

53
Introduzione ad ATL
La Active Template Library (ATL) e’ una collezione di template che fa parte di
Microsoft Visual C++ e che serve per facilitare il compito di creare oggetti COM.
Sebbene sia possibile creare oggetti COM (come abbiamo visto nei capitoli precedenti)
tramite la scrittura manuale di codice C++ oppure tramite l’utilizzo di MFC e’ consigliato
l’utilizzo di ATL per applicazioni professionali dato che il codice generato da ATL e’
particolarmente performante ed efficiente.
Inoltre, lo wizard contenuto nel VC++ permette di creare oggetti COM utilizzando ATL
in un tempo brevissimo rispetto ad altre metodologie di sviluppo, dato che si occupa di
generare tutto il codice di base e le interfacce richieste dallo standard COM.
Le interfacce personalizzate dall’utente possono essere facilmente realizzate con ATL,
tramite l’utilizzo di un linguaggio di definizione delle interfacce denominate IDL
(Interface Definition Language).

Per realizzare un semplice oggetto COM utilizzando ATL e’ possibile utilizzare

l’application Wizard di Visual C++, il quale si occupa della creazione di tutta
l’infrastruttura ATL e di tutte le interfacce richieste dallo standard COM.
Nell’esempio 2_3_5 e’ riportato il COM server che offre solamente un metodo per
adddizionare due numeri e che e’ stato realizzato con i seguenti passi:

- Creare un nuovo progetto VC++ e selezionare “ATL COM App Wizard”; dare un
nome al progetto come “Simple_ATL”.
- Nella dialog successiva specificare che si vuole creare un oggetto COM di tipo
“Server DLL” e lasciare invariate tutte le altre opzioni.
- Una volta che il wizard ha creato i file di base per il nostro progetto selezionare
Insert->New ATL Object dal menu; tra i vari oggetti proposti scegliere “Simple
Object” e cliccare sul pulsante “Next”
- Nella dialog successiva indicare come short name “First_ATL” e poi cliccare sul
tab “Attributes”; impostare Interface->Custom e Aggregation->No e premere
OK per fare in modo che il wizard crei il nostro oggetto ATL.
- Se osserviamo il “Class View” per il nostro progetto possiamo vedere
un’interfaccia denominata “IFirst_ATL”; fare click del pulsante destro su questa
interfaccia e selezionare “Add Method”
- Il nome del metodo sara’ AddNumber e come parametri possiamo specificare:

[in] long Num1, [in] long Num2, [out] long *ReturnVal

- Una volta specificata l’interfaccia IDL per il nostro metodo e’ necessario fornirne
l’implementazione; per fare questo dal Class View espandere (+) l’albero
dell’interfaccia e fare doppio click su “AddNumbers”; il codice del metodo verra’
generato, e sara’ possibile quindi aggiungere l’istruzione di somma:

54
STDMETHODIMP CFirst_ATL::AddNumbers(long Num1, long Num2,
long *ReturnVal)
{
// TODO: Add your implementation code here
*ReturnVal = Num1 + Num2;

return S_OK;
}

- a questo punto il nostro oggetto COM minimale realizzato tramite ATL e’ pronto
per essere compilato (Build); una volta generata la DLL il VC++ provvedera’ a
registrare l’oggetto COM in modo da poterlo utilizzare da altre applicazioni.
- Per testare l’oggetto COM dal Visual Basic, aprire un nuovo progetto VB e dal
menu Project->References selezionare la libreria “Simple ATL 1.0 Type
Library” per aggiungere un riferimento all’oggetto COM all’interno del progetto
Visual Basic.
- Adesso e’ possibile scrivere ed eseguire il seguente codice Visual Basic che
utilizza il metodo AddNumbers del nostro oggetto COM:

Private Sub Command1_Click()

Dim objTestATL As SIMPLE_ATLLib.First_ATL
Set objTestATL = New First_ATL

Dim lngReturnValue As Long

objTestATL.AddNumbers 5, 7, lngReturnValue

MsgBox "La somma di 5 + 7 vale: " & lngReturnValue

End Sub

55
Parte 4 : Appendice

Indice dei listati a corredo del testo

2_1_1 “Hello World” versione SDK

2_1_2 “Hello World” versione MFC
2_2_1 Menu e “device context”
2_2_2 I controlli di base
2_2_3 “Customizzare” un controllo
2_2_4 Controlli e Dialog box
2_2_5 La serializzazione
2_2_6 Applicazioni SDI
2_2_7 Stampa e preview di stampa con MFC
2_3_1 Programmazione multithread
2_3_2 Automation server
2_3_3 Automation server + client
2_3_4 Accesso al DB tramite ADO
2_3_5 COM Server con ATL

Glossario

ADO ActiveX Data Object

API Application Program Interface
ASP Active Server Pages
ATL Active Template Library
COM Component Object Model
DBMS Data Base Management System
IDL Interface Definition Language
LAN Local Area Network
MDAC Microsoft Data Access Components
MDI Multiple Document Interface
MFC Microsoft Foundation Classes
ODBC Open Data Base Connectivity
OLE Object Linking and Embedding
OO Object Oriented
OOP Object Oriented Programming
SDI Single Document Interface
SDK Software Development Kit
STL Standard Template Library
VBA Visual Basic for Application
WSH Windows Scripting Host

56
Documentazione per il corso:.....................................................................................................1
“Sviluppo Applicazioni in ambiente Windows con Microsoft Visual C++ 6.0”..............................1
Parte 1 : Dall’SDK ad MFC.......................................................................................................1
Introduzione alla programmazione in ambiente Windows..................................................1
Programmare con l’SDK.....................................................................................................2
Introduzione a MFC............................................................................................................8
La prima applicazione MFC in dettaglio..............................................................................8
Parte 2 : Le classi MFC e l’interfaccia di Windows.................................................................12
Gli elementi base di MFC: Disegnare tramite un “Device Context”, gestione di mouse e
tastiera, gestione dei menu..............................................................................................12
I controlli di base e le “dialog box”..................................................................................18
Le classi di utilita’ MFC e la “serializzazione”...................................................................25
Introduzione all’architettura “Document View”................................................................27
Le applicazioni SDI (Single Document Interface).............................................................28
Le applicazioni MDI (Multiple Document Interface)..........................................................34
Le funzionalita’ di stampa ...............................................................................................35
Parte 3 : Oltre l’interfaccia...................................................................................................37
La gestione dei timer e del ciclo “Idle”.............................................................................37
Gestione dei “Thread”......................................................................................................40
Introduzione alle tecniche di accesso ai dati....................................................................43
Accesso ai database tramite ADO.....................................................................................45
Gli oggetti COM................................................................................................................49
Tecniche di “Automazione”..............................................................................................51
Introduzione ad ATL.........................................................................................................54
Parte 4 : Appendice.............................................................................................................56
Indice dei listati a corredo del testo.................................................................................56
Glossario..........................................................................................................................56

57