Newsgroup: it.comp.lang.c++
Titolo: Cambiare font in una finestra di dialogo

Qualcuno sa dirmi come posso cambiare i font delle label (Static Text) in
una finestra di Dialogo?

una finestra di Dialogo?
Come qualsiasi altra finestra, cosi` anche uno static control
con uno stile di tipo testuale dovrebbe rispondere al messaggio
WM_SETFONT cambiando il proprio font (al font la cui handle
viene passata in wParam) e ridisegnandosi se richiesto dal
valore di lParam (0=non ridisegnare, 1=ridisegnare).
La HFONT, che ti serve per mandare un messaggio WM_SETFONT,
naturalmente, puoi ottenerla con CreateFont, ecc ecc; o, magari,
farlo scegliere dall'utente con ChooseFont, che ti aggiorna un
LOGFONT sulla cui base puoi fare un CreateFontIndirect; ecc.
Ecco un piccolo esempio -- una funzione che, per esempio,
puo` essere chiamata da una dialog procedure, quando l'utente
clicca uno di due bottoni per scegliere l'uno o l'altro font per
una data scritta (uno static control di id IDC_SCRITTA).  Facci
sapere (qui, please, non nella mia mailbox) se questo codice
ti e` utile, e/o se hai bisogno di vedere anche il resto del minuscolo
programmino d'esempio che usa questa funzione, ecc.
HFONT fnt[2];
BOOL doFont(HWND hDlg, int fid)
{
 if(!fnt[fid]) {
  LOGFONT lf;
  ZeroMemory(&lf, sizeof(lf));
  CHOOSEFONT cf;
  ZeroMemory(&cf, sizeof(cf));
  cf.lStructSize=sizeof(cf);
  cf.hwndOwner=hDlg;
  cf.lpLogFont=&lf;
  cf.Flags=CF_FORCEFONTEXIST|
   CF_SCREENFONTS;
  if(!ChooseFont(&cf))
   return FALSE;
  fnt[fid] = CreateFontIndirect(&lf);
  if(!fnt[fid])
   return FALSE;
 }
 HWND hStat = GetDlgItem(hDlg, IDC_SCRITTA);
 if(!hStat) return FALSE;
 SendMessage(hStat, WM_SETFONT, (WPARAM)fnt[fid], 1);
 return TRUE;
}
Alex


Per default i control di un Dialog usano la stessa font del Dialog stesso.
Se vuoi cambiare il font di un control (Static o anche altro), manda un
messaggio WM_SETFONT al control in questione per esempio quando
processi OnInitDialog.
Vedi Help-in-line per i dettagli sui parametri.

Sě, mi č stato utile, non perchč lo abbia utilizzato direttamente (a me
serviva solo cambiare il font di alcune scritte nella InitDialog), ma perchč
da esso ho preso spunto per risolvere il mio problema. Da qualche altra
parte, mi era stato suggerito di creare il font con CreateFontIndirect e
assegnarlo con SetFont. Io ho provato, ma non funzionava. Ecco il codice.
LOGFONT lpFont;
CFont fOutputFont;
(GetDlgItem(IDS_INPS1_1)->GetFont())->GetLogFont(&lpFont);
lpFont.lfHeight = - 13;
fOutputFont.CreateFontIndirect(&lpFont);
for (i = 0; i < NUM_DEST1; i++)
{
      ........
     GetDlgItem(IDS_INPS1_1 + i)->SetFont(&fOutputFont)
}
Dove sbaglio? Per ora, prendendo spunto dal tuo esempio, ho fatto cosě
LOGFONT lpFont;
HFONT fOutputFont;
ZeroMemory(&lpFont, sizeof(lpFont));
(GetDlgItem(IDS_INPS1_1)->GetFont())->GetLogFont(&lpFont);
lpFont.lfHeight = - 13;
fOutputFont = ::CreateFontIndirect(&lpFont);
for (i = 0; i < NUM_DEST1; i++)
{
  ........
      GetDlgItem(IDS_INPS1_1 + i)->SendMessage(WM_SETFONT, (WPARAM)
fOutputFont, 1);
}
e funziona. Mi piacerebbe comunque sapere dove sbagliavo prima.
P.S. Ho una certa preferenza a utilizzare le MFC piuttosto che le chiamate
dirette alle API (giusto come terminologia?), anche se so bene che la
corrispondente MFC spesso non fa altro che chiamare la corrispondente API.
Per me, risulta piů leggibile il codice scritto utilizzando MFC
(probabilmente perchč in Windows ho iniziato direttamente con MFC).

(probabilmente perchè in Windows ho iniziato direttamente con MFC).
Io ho iniziato con le API nude, tanti anni fa, ma trovo comunque piu` comodo
qualsiasi "vestito" (MFC sono un po' troppo ingrassate per i miei gusti, anche
se, ovviamente, le uso quando mi serve, ma il "leggerissimo vestito" posto ad
esempio dal framework ATL, classe CWindow e parenti, mi piace da matti!).
Una serie di funzioni PippoX(HPIPPO p), PippoY(HPIPPO p, int i), ecc ecc, GRIDA
per essere "tradotta" in p->X(), p->Y(i), eccetera...:-).
Pero`, se uno fa una domanda e non si capisce in quale framework (if any)
stia lavorando (sarebbe meglio specificarlo...!), per default penso che si
debba rispondere basandosi sulle API, piuttosto che su MFC, ATL, OWL,
VCL, o mille altri, no...?
Alex

VCL, o mille altri, no...?
Concordo pienamente.
Volevo comunque dirti che avevo provato a mettere la ZeroMemory anche
nell'altro caso, e continuava a non funzionare. Poi lo tolsi visto che non
era quello il problema.

> 
http://www.geocities.com/sunsetstrip/stage/7787
 <<
<<<<<<<<<<<< 
DucaCr...@iol.it
 >>>>>>>>>>>>>>

MFC con qualche funzione in meno oppure č diverso?
Decisamente diverso!  Mentre MFC, anzitutto per ragioni storiche
connesse alla sua data di nascita, evita assolutamente l'eredita`
multipla, e si affaccia timidamente al mondo dei template appena
appena, ATL e` tutta basata su template ed eredita` multipla.  Un
tempo (versione 1.0) MFC voleva essere un "leggero strato di
rivestimento" sopra le API Windows, ma presto questa iniziale
filosofia di architettura fu mischiata con esigenze, del tutto diverse,
di "ricchezza funzionale"; ATL e` "filosoficamente" molto simile al
concetto originale di MFC ("leggero strato di rivestimento"), e gli
strumenti del C++ moderno gli permettono di implementare questa
filosofia con estrema coerenza.  MFC ti offre tonnellate di funzioni
pre-cotte, purche` tu "pieghi" l'intera logica del tuo programma alla
sua struttura document/view; ATL ha MOLTO meno funzionalita`
"general purpose" (basta pensare a print e print preview...!), offre
invece un supporto splendido al COM (varie tacche sopra quello,
secondo me abbastanza goffo, e limitato al "dispatch", di MFC).
Se devo mettere insieme un'applicazione con print, print preview,
eccetera, MFC mi permette di farlo molto piu` in fretta; per quegli
usi "leggeri", in cui verrebbe piu` spontaneo usare le nude API di
Windows, trovo invece preferibile ATL.  Se il COM e` in gioco (e,
al giorno d'oggi, in qualsiasi applicazione Windows, e` probabile
che lo sia -- se non altro, ad esempio, per il requisito ormai quasi
indispensabile che ogni applicazione sia server di Automation!),
preferisco di gran lunga farlo con ATL.  ATL e MFC possono
benissimo convivere -- i Wizard di VC++6.0 "lo sanno", e non
danno troppi problemi a realizzarlo; con VC++5.0, occorreva
un "retro-fit" manuale dell'ATL sull'EXE MFC fatta dal Wizard,
ma, una volta vista la tecnica, non e` poi un grosso problema
(una _scocciatura_, questo si`:-).
Ci sono vari altri "framework leggeri" che rivestono le API di
Windows con uno strato minimale, sostanzialmente di routing
di messaggi/comandi/notifiche -- un vecchio testo molto bello,
"Unsupported Windows" di Schulmann, ne introduce ad esempio
uno molto funzionale, per Win16, basato tutto sul C; VxWin,
un framework avanzato gratuitamente disponibile in rete, e`
un esempio di come si puo` impostarlo in C++, come pure, a
livello piu` introduttivo, lo e` il tutorial online della Relisoft.
ATL, da questo punto di vista, offre uno di questi "framework
leggeri", praticamente "senza costo" (in termini di dimensione
e velocita` del codice) -- piu`, naturalmente, la roba di COM.
In pratica, per usare un framework leggero, bisogna conoscere
bene le API di Windows, visto che esso, per definizione, le
"ricopre appena appena".
Sulla mailing list GIDA (Gruppo Italiano Diffusione API) stiamo
sviluppando un tutorial sulle API, attualmente in corso di
primissima stesura "draft", che un giorno potra`, penso,
tornare comodo a chi voglia affrontare questi argomenti.
Alex

solo controlli ActiveX, ma "server COM" di tutti i gusti e sapori), ...
[snip]
....
grazie per la esauriente e chiara spiegazione!!
mi piacerebbe saperne qualche cosa di piů sul COM... ho provato mesi fa con
qualche tutorial e articolo dalla rete, ma non mi ha chiarito tanto le idee
a livello pratico.... mi consigli un buon libro per cominciare, magari
orientato allo sviluppo in C++?
Tieni conto che le MFC le conosco abbastanza da riuscirmi ad orientare bene
nello sviluppo di un programma per win... conosco abbastanza anche le API
nude e crude....
Quello che mi serve č un libro che spieghi i concetti ma soprattutto come
implementare degli oggetti COM usando il VC++


 orientato allo sviluppo in C++?
Alex mi perdonera' se gli rubo la risposta, ma non posso trattenermi dal 
raccomandare "Essential COM" di Don Box (Addison Wesley). E' "il" libro 
da leggere se si vuole capire veramente come funziona COM e perche'.
Come libro aggiuntivo, per quanto riguarda ATL, e' uscito da pochissimo 
"Professional ATL COM Programming" di Grimes (Wrox ed.). L'ho appena 
iniziato a leggere ma da una rapida sfogliata sembra piuttosto 
esauriente, e soprattutto e' per ora l'unico libro in giro aggiornato ad 
ATL 3.0. Come alternativa puoi vedere se e' finalmente uscito "Inside 
ATL" dall'oracolo ufficiale (alias Microsoft Press). Lo davano in uscita 
alla fine di ottobre.
Altri libri: "Beginning ATL COM Programming" di Grimes (leggermente piu' 
a livello introduttivo del professional, e aggiornato ad ATL 2.1) e 
"Active Template Library - A Developer's Guide" di Armstrong (IDG Books 
credo). Anche quest'ultimo riguarda ATL 2.1, ma contiene un'ottima 
introduzione all'architettura della libreria.
Ciao,
Antonello

implementare degli oggetti COM usando il VC++
"Beginning ATL COM Programming", Grimes et al, WROX Press.
Alex

introduzione all'architettura della libreria.
Tutto giusto (eccetto che "Beginning" e` di Grimes *et al* -- non e`
solo Grimes l'autore).  Dei due, il testo Wrox e` piu` pragmatico,
quello IDG da` in effetti piu` informazioni "architetturali".
Incidentalmente, tutti questi testi esistono solo in inglese.  In
italiano, c'e` l'introduttivo "Inside COM" (non male) e
l'intermedio "Inside Distributed COM" (non e` granche`, a
meno che a uno non interessino culturalmente dettagli sui
protocolli di rete usati, ecc), entrambi Mondadori Informatica
(Microsoft Press nell'originale); e, tanto per completare il
quadro, il testo che io penso andrebbe letto PRIMA, per dare
un inquadramento della problematica (non insegna a scrivere
programmi, ma chiarisce il rapporto fra COM, ActiveX, OLE,
ecc!), il Chappell, sempre Mondadori Informatica (allo SMAU
lo vendevano col 50% di sconto, forse perche` "datato", ma
per quello che copre e` e resta valido), ottimo veramente.
Comunque, tutti questi testi tradotti in italiano c'entrano
col COM, ma non con ATL...
Alex

 
Beh non e' certo un libro banale o superficiale, e ammetto che non e' 
stata la mia prima lettura sull'argomento COM, pero' mi e' piaciuto molto 
lo stile dell'autore e il modo/ritmo con cui elargisce informazioni 
(soprattutto la gradualita'/naturalezza con cui passa dal C++ a COM).
Se si puo' definire "avvincente" un libro di informatica, credo che 
"Essential COM" meriti l'aggettivo. 
Concordo pienamente nel giudizio sul Chappell, ottimo per farsi un'idea 
su "che diavolo e' 'sto COM" ma chiaramente (e dichiaratamente) 
insufficiente per iniziare a programmarci su. 
Purtroppo per chi paga i libri con la propria carta di credito, temo che 
per quanto riguarda COM non la si possa sfangare con un testo solo -- 
sigh :(
Ciao,
Antonello 
-- 
// ---------------------------------------------------
// Antonello Salvatucci
// Software Engineer, LEGO Media International
// Kloevermarken 120, Billund 7190 DENMARK
//
// antonello at digi. lego. com    
http://www.lego.com