Newsgroup: it.comp.programmare.win32
Titolo: [VC5/MFC] Inserimento dati con CEdit in un CDialog

Ho dei controlli CEdit in un dialogo (classe creata con Class Wizard a
partire dal dialog editor) ma:
1. Se premo <ENTER>, anche se sono in edit, si chiude il dialogo
2. L'evento EV_CHANGE sul CEdit viene generato per ogni carattere
inserito mentre a me interessa sapere quando l'utente ha terminato
l'inserimento (sposta il focus su un altro controllo o preme <ENTER>
In pratica vorrei disabilitare la "chiusura automatica" del dialogo e
intercettare il tasto <ENTER> su un CEdit, possibilmente senza
subclassing.
Come faccio ?
Grazie, Alberto

 l'inserimento (sposta il focus su un altro controllo o preme <ENTER>
Se preme Enter non si verifica nessun "evento" particolare (se
il controllo ha want-return ed e` multiline) bensi` semplicemente
si inserisce un carattere di fine-riga (cioe` si va a capo).
Se non vuoi che <Enter> attivi il tuo attuale pushbutton di
default, rendi di-default un ALTRO pushbutton (magari non
visibile!) e nella funzione che gestisce i 'clic' su quest'altro
pushbutton farai tutte le verifiche che vuoi sul contenuto
dell'edit che ti interessa.
Quando, invece, l'edit perde il focus, ne avverte il genitore
(il tuo dialogo) con codice di notifica EN_KILLFOCUS.  Gestisci
dunque questo evento, sempre con tutte le verifiche del caso.
(Naturalmente, scriverai una subroutine comune da chiamarsi
in entrambi i casi in cui vuoi fare le stesse verifiche, *NON*
duplicherai codice).
Alex

(il tuo dialogo) con codice di notifica EN_KILLFOCUS.
...il "trucco" del bottone di default e' quello di cui avevo bisogno.
Su EN_CHANGE imposto un bool associato al controllo e su l'evento
CLICK del bottone di default e EN_KILLFOCUS (delcontrollo) verifico la
variabile di stato e agisto di conseguenza. Non mi resta che
trasformare il tutto in una classe in modo da gestire un set di
controlli di edit con validazione e dispatching automatico.
Non avevo indagato in questa direzione peche' davo per scontato che
esistesse un evento per gestire questo tipo di richieste e mi sembra
molto strano che manchi (dovrebbe essere una necessita' abbastanza
comune).
Grazie, Alberto.

 comune).
L'interfaccia-utente di Windows prevede che Enter attivi il bottone
di default.
E` tutt'altro che "abbastanza comune" che un'applicazione si arroghi
invece il diritto di stravolgere i normali standard di interfaccia utente
che gli utenti si aspettano.  O meglio, e` si` comune, perche` tutti i
programmatori nuovi della piattaforma vogliono fare le cose a modo
loro, ma le applicazioni che "maltrattano" gli utenti in questo modo
tendono a non sopravvivere a lungo.  Non sarebbe certo un buon
servizio da parte di un framework aiutare il programmatore a fare
un'applicazione che viola gli standard cui gli utenti sono abituati, e
che quindi gli utenti odieranno e faranno fallire sul mercato.
Le applicazioni migliori rispettano gli standard della piattaforma su
cui girano, permettendo cosi` agli utenti gia` abituati all'uso della
piattaforma stessa di usare le varie applicazioni con il minimo di
fatica per "spostarsi" dall'una all'altra.
I framework migliori rendono il piu` facile possibile seguire gli
standard in questione.
Per la validazione del contenuto al momento della perdita di focus,
invece, e` prevista appunto la notifica che ti dicevo, che e`
_appunto_ "un evento per questo tipo di richieste".
Alex

che gli utenti si aspettano. [...]
Non intendevo di certo questo (rispetto sempre gli standard di
interfaccia). Mi riferivo alla gestione dell'input da un controllo
CEdit. In generale, nelle applicazioni dialog based con dei CEdit,
basta premere <ENTER> per far processare il dato. E' naturale scrivere
e poi premere ENTER - di solito e' questo che l'utente si aspetta.
Mi sa che l'hai proprio voluta prendere dal lato sbagliato...

 Mi sa che l'hai proprio voluta prendere dal lato sbagliato...
Se qualcuno chiede "come si fa x" io tendo a spiegargli come
si fa, poi pero` aggiungo (se ho tempo) anche consigli del tipo
"ma non farlo, probabilmente non ti conviene, per questo e
quest'altro motivo".  Le persone che *merita* aiutare accettano
questo tipo di consigli motivati come non meno utili della mera
nozione tecnica di dettaglio.  Per le altre (quelle che ritengono
che offrire simili consigli sia "prenderla dal lato sbagliato") c'e`
poco da fare.  Ma un newsgroup ha molti piu` lettori, che non
gente che ci scrive su, quindi c'e` sempre la speranza ("spes
ultima dea") che non sia del tutto fiato sprecato.
Alex

 ma evedentemente ho interpretato male.
Mi dispiace se il mio tono ti ha indotto a questa interpretazione.  Non
pensavo che un utente Windows avesse aspettative diverse, per il
comportamento dell'Enter quando il focus e` su di un controllo Edit
mono-linea, da quello che fanno tutte le normali applicazioni Windows;
pensavo invece che tu volessi imporre un comportamento diverso (e
volessi altresi` che il framework te lo facilitasse) SAPENDO che la
normale GUI di Windows prevede un comportamento cosi` e cosa`.
A questo punto ti suggerisco di aprire MSDN, sotto "Books", e
studiare "The Windows Interface Guidelines for Software Design",
libro che e` interamente compreso nella MSDN stessa.  E` fatta
per essere studiata nel complesso, non usata come "quick
reference", pero` e` secondo me ben scritta.  Al Capitolo 8,
sotto "Characteristics of Secondary Windows", troverai la
pagina "Default Buttons" che illustra abbastanza bene gli
standard previsti (compreso il cambiamento di bottone di
default, con tanto di cambiamento delle indicazioni grafiche,
quando l'utente naviga con la tastiera fra diversi bottoni; il
ripristino del bottone di default quando il focus NON e` su
di un altro bottone; e i casi di altri controlli che "assorbono",
ovvero non assorbono, il tasto Enter).
Nella "Visual C++ Programmer's Guide" troverai una paginetta
riassuntiva che fa riferimento alle Guidelines (stranamente
senza un hyperlink -- pare sia stata scritta quando le guidelines
andavano acquistate come libro cartaceo, e non rivista per
riflettere il fatto che oggi sono anche incluse in MSDN!) e
a come il framework MFC e` progettato per supportarle (per
cui violarle e` tendenzialmente reso + arduo che rispettarle).
Quando vedi qualcosa in MFC che non va come ti aspetti,
dunque, controlla anche le tue aspettative... puo` darsi che
siano sbagliate loro, piuttosto che il framework (con cio` NON
voglio implicare che MFC sia perfetta, anzi -- ha alcuni difetti
"di fondo" di progettazione, vari difetti di dettaglio, e i bug di
implementazione o almeno le scelte discutibili anche da questo
lato non sono certo assenti -- pero` sull'aderenza alle guidelines
ci battono molto, e molto ci hanno investito).
Alex