Il lettore che abbia seguito il nostro consiglio, provando a scrivere il codice del programmino esplorativo relativo agli stili degli edit box, sulla base di quanto sin qua abbiamo esposto, potrebbe avere prodotto qualcosa del genere (supponiamo, per comodità, in un singolo file sorgente, con le solite convenzioni, e usando, ad esempio, i cracker di WindowsX):
L'unica "finezza", se tale è, si accentra sulla
getStylebit
, che è architettata, oltre che per
decodificare lo stile dall'id del controllo sulla
base dell'eventuale bit 0x8000
, anche per dare
sempre 0 per eventuali non-bottoni; a questo
scopo, verifichiamo che la window procedure
del controllo in esame sia proprio quella dei
bottoni (che, per comodità, registriamo una
volta per tutte alla partenza come dato del
dialogo -- non ci sarebbe, ovviamente, nulla
di errato nel recuperarla invece ogni volta,
da una qualsiasi finestra che "sappiamo" essere
sicuramente null'altro che un bottone).
Eseguendo questo programma, osserviamo che
lo stile iniziale dell'edit è 0x50010000
(da un
esame di winuser.h, possiamo confermare che
questo corrisponde ai tre bit di stile:
Purtroppo, osserviamo anche che quasi tutti
questi cambiamenti di
bit di stile non hanno effetto alcuno...!
(Fra le poche eccezioni, ES_LOWERCASE
ed
ES_UPPERCASE
, che effettivamente agiscono
sul testo immesso mentre sono settati, benchè,
cosa tutto sommato ragionevole, non sul testo
preesistente).
Se il lettore che ha osservato questo effetto ha
anche provato, per rimediarlo,
a studiare la documentazione dell'SDK
di Windows, è anche possibile che abbia notato
una breve osservazione presente nella doc della
SetWindowLong:
"alcuni bit di stile sono in cache,
così che i cambiamenti fatti con SetWindowLong
non avranno effetto sinchè non si chiama la
funzione SetWindowPos
". Provando a seguire
questa indicazione, l'ipotetico, diligente lettore
può aver provato a rimediare al difetto con
l'aggiunta di una chiamata, appunto, a detta API:
setStyle
, subito dopo la chiamata a SetWindowLong
e subito prima della fine della setStyle
).
Questa è
una chiamata a SetWindowPos
che non fa nessun
cambiamento (grazie ai vari bit SWP_NOxxx
), ma
dice alla finestra che qualcosa è cambiato (grazie
all'apposito bit d'opzione SWP_FRAMECHANGED
).
Qualcosa, in effetti, migliora; ad esempio, i bit
di WS_HSCROLL
e WS_VSCROLL
adesso hanno
effetto, facendo apparire, se settati, le scroll
bar desiderate. Ma la maggior parte dei bit di
stato resta invece desolantemente priva di effetti,
per quanto noi possiamo settarli.
Purtroppo, la causa di questo "non-comportamento" è mal documentata ma sicuramente vera: non pochi dei bit di stile dei controlli di Windows sono, così ci dice l'osservazione, esaminati dal controllo soltanto in partenza; dopo che il controllo è stato creato, non tiene più conto di eventuali modifiche a questi bit. Ciò è sicuramente più efficiente, in quanto, in questo modo, la window procedure del controllo non ha bisogno di esaminare quei bit ad ogni messaggio che riceve, bensì solo alla creazione del controllo stesso... ma, come possiamo noi allora ottenere invece il "dinamismo" che ci serve per vedere in opera tutti i vari bit di stile al semplice clic su di una checkbox...?
Una soluzione c'è, benchè forse poco intuitiva; essa si basa, d'altronde, su di un'API che ancora non abbiamo visto, per quanto l'esistenza di qualcosa del genere debba poter essere considerata "implicita" in tutte le operazioni di Windows. Invitando il lettore a riflettere su quale possa essere l'API di cui stiamo parlando, promettiamo, ancora una volta, "il seguito alla prossima puntata"!
Capitolo 22: controlli: gli EDIT
Capitolo 24: creazione di finestre
Elenco dei capitoli