Newsgroup: it.comp.lang.delphi
Titolo: TEdit

Come faccio a far accettare al mio TEdit soltanto Cifre e non lettere?
Thanks


Usa un TMaskEdit e usa una maschera di questo tipo!9999999999;1

Usa un TMaskEdit e usa una maschera di questo tipo!9999999999;1
oppure basta intercettare gli eventi OnKey...
--
Andrea Laforgia (
andrea_...@bigfoot.com
)
---------------------------------------------

Come faccio a far accettare al mio TEdit soltanto Cifre e non lettere?
utilizzando gli eventi  ( come ha detto Andrea Laforgia ) puoi filtrare
quello che vuoi.
La variabile "Key" ti restituisce il carattere digitato o il valore numerico
di quel carattere.
Ora ci sono degli eventi che si verificano prima o dopo aver premuto un
tasto.
Sta a te gestirli come meglio credi.
Oppure visto che il tuo campo deve accettare solamente cifre, puoi fare una
conversione e gestire l'eccezione.
Quando si verifica l' eccezione sai che si tratta di tutto ma non di un
numero.
Questo sistema non è che sia bello, ma voglio solo farti notare che puoi
gestire la situzione come vuoi, non è detto che devi usare per forza il
MaskEdit.
Molte volte conviene far da soli......non sempre ci sono i componenti pronti
per soddisfare le nostre
aspettative !! :-)))
Ok, ti saluto......buon lavoro !!
Ciaooooo !!!!
Antonio Tarolla
BSSoftware Tips Mailing - List Support

per soddisfare le nostre
...ma poi, aggiungo, volendo, si puo' costruire il proprio componente
TNumericEdit che accetta solo cifre in input. La costruzione dei
componenti e', a mio avviso, una valida palestra per imparare l'OOP in
modo corretto e dovrebbe essere piu' frequente tra i programmatori.


 sono, semplicemente cercando la proprieta' che serve.
Ciao Piero (era un po che non ti si vedeva sul Ng! ;-)
                  stai forse pensando ad un componente che si aggancia al
Tedit (o ad un altro componente in generale) controllando le modifiche fatte
su una proprietà?
Non so se è possibile ma credo che si potrebbe provare a sostituire le
procedure di Get e Set della proprietà mantenendo un riferimento alle
vecchie per poter fare una sorta di inheritance...
Ci si potrebbe fare un pensierino ;-)
Ciao :-)
--
(¯`·.¸¸.·´¯`·.¸¸.-> Andrea <-.¸¸.·´¯`·.¸¸.·´¯)
AntiSpam: rimuovere il trattino basso dall'indirizzo per rispondere
AntiSpam: remove the underscore from the e-mail address to reply

modo corretto e dovrebbe essere piu' frequente tra i programmatori.
Non cosi' pero'. Ti costringe a usare sempre e solo quel componente
anziche' altri che potrebbero essere + adatti al contesto.
Io preferirei dei componenti in grado di controllare quelli
preesistenti nel modo desiderato, addirittura senza sapere di che tipo
sono, semplicemente cercando la proprieta' che serve.
E' un'idea che mi frulla in testa da tempo. Pero' dovrei consolidare
le mie conoscenze.
Saluti
--
Piero Bonanno
bop...@libero.it
pie...@tiscalinet.it
bop...@tin.it
bpie...@hotmail.com
______________________________________________
"Madame, lei ha tra le gambe uno strumento
che puo' offrire piacere a migliaia di persone,
e tutto quello che sa fare e' grattarlo"
- Sir Thomas Beechan a una violoncellista

anziche' altri che potrebbero essere + adatti al contesto.
Si puo' gia' fare.
Esiste l' ereditarieta', il polimorfismo, l' ovverriding dei metodi.
Per controllare in modo diverso un componente esistente, ti basta
derivarne uno e aggiungere o modificare le proprieta'/metodi gia'
esistenti nel padre. Un buon testo sulla OOP ti potrebbe aiutare a
capire questi concetti.


 Un buon testo sulla OOP ti potrebbe aiutare a capire questi concetti.
Andrea, ti consiglio vivamente di non comportarti, qui su
it.comp.lang.delphi, come ti comporti su it.comp.lang.pascal e cioè (e sarò
molto chiaro) ti invito a non trattare gli altri frequentatori del Ng come
"inferiori".
Senza polemica.


"inferiori".
Mi accingo a rispondere con molta amarezza, ma bisogna chiarire le
cose una volta per tutte.
Non vedo che cosa ci sia di offensivo nella mia frase, dato che e' un
consiglio dato amichevolmente ! VEDIAMO DI SMETTERLA (saro' molto
chiaro anche io in proposito) di interpretare i messaggi di chi offre,
sottolineo *amichevolmente*, il suo aiuto come una dimostrazione di
snobbismo. Su it.comp.lang.pascal io ho aiutato e aiuto centinaia di
persone a risolvere i loro problemi (da molto prima che tu ci
entrassi, e non te lo dico per snobbismo, ma per ridimensionare un po'
le tue parole) e non lo dico per aspettarmi un ringraziamento, ma
perche' mi piace molto farlo (anche per e-mail).
Io non tratto nessuno come "inferiore" perche' mi sembra scorretto e
non ne ho affatto bisogno per sentirmi appagato, visto che faccio il
programmatore di mestiere e di soddisfazioni ne ho tante e di
tutt'altro genere, anzi considero **molto** (ma veramente tanto)
maleducato da parte tua e da parte di chi la pensa come te considerare
un atto di ostentata superiorita' l'atteggiamento di coloro che
impartiscono consigli in virtu' (forse) di una maggiore esperienza in
programmazione, anziche' farne tesoro (si chiama "ingratitudine", se
non lo sai). Quindi colui/coloro che deve/devono modificare il proprio
comportamento sei tu e quelli che la pensano come te, non io.
Veniamo alla questione tecnica : dice il saggio : prima di dire a
qualcuno "non hai capito", accertati d'aver capito tu per primo.
Quando io parlo della derivabilita' del componente, sto proponendo
l'esatta soluzione al problema.
Il mio interlocutore scrive :"Ti costringe a usare sempre e solo quel
componente anziche' altri che potrebbero essere + adatti al contesto.
Io preferirei dei componenti in grado di controllare quelli
preesistenti nel modo desiderato, addirittura senza sapere di che tipo
sono, semplicemente cercando la proprieta' che serve."
Adatti a questo scopo giungono incontro l'ereditarieta' e il
polimorfismo e qui ribadisco che, dato che questi argomenti non sono
esauribili nell'arco di un centinaio di righe di messaggio, la lettura
di un valido testo sulla OOP (come Thinking in C++ o Thinking in Java
per il C++ e Java rispettivamente) puo' offrire una buona inquadratura
di cio' di cui si sta parlando, senza per questo far sentire
"inferiore" nessuno. Se Paolo ha problemi nel capire come fare sono
disponibilissimo ad aiutarlo. Se dai un'occhiata alla gerarchia delle
classi VCL, inoltre, ti accorgi che esistono molte classi astratte di
tipo "custom".
"To custom" in inglese significa "personalizzare" e la loro
introduzione serve appunto a consentire di derivare sotto-classi che
conservino o meno caratteristiche della classe base (grazie alla
scopertura o meno delle proprieta'/metodi protetti) e/o modifichino il
suo comportamento, consentendo di "controllare i componenti
preesistenti nel modo desiderato". La classe TMemo, per esempio, cosi'
come TRichMemo sono entrambe sotto-classi del tipo TCustomMemo, ma
hanno proprieta'/metodi differenti.


capire questi concetti.
Beh...considera che sono tesista di Ingegneria del Software con una
tesi sull'OOD, qualcosina l'ho gia' letta :-)
Un'applicazione come dici tu va bene nella programmazione OOP "pura",
dove l'interfaccia la crei da codice. Ovviamente in quel caso derivare
e' una buona soluzione, di sicuro non l'unica e secondo me non sempre
migliore, perche' aumenta l'accoppiamento.
Nell'ambiente Delphi e' semplicemente scomoda: per esempio, considera
un edit box che accetta solo numeri (TNumericEdit) derivato da TEdit;
se trovi un componente edit che, per es., gestisce internamente il
tasto Invio e lo vuoi usare, come fai? Dovresti ri-derivare questo
nuovo componente per farne un TNumericEdit oppure riscrivere il tuo
componente per fargli gestire il tasto Invio. In entrambi i casi per
risolvere un problema, te ne sei creato uno + rognoso.
Senza considerare che ogni volta devi installare il nuovo componente
nell'ambiente, la palette aumenta a dismisura e cosi' via.
E cosi' ho maturato quell'idea che ho descritto nella risposta ad
Andrea...


Ci si potrebbe fare un pensierino ;-)
Questo potrebbe essere pane per i tuoi denti: hai idea di come
intercettare un certo evento solo per i componenti contenuti in una
lista? Si potrebbe dare vita ad una serie di TAMBPqualcosa :-)
Ciao


hanno proprieta'/metodi differenti.
Il fatto e' che la VCL e' pensata male dal punto di vista della
derivabilita'. Per esempio ci sono pochissimi metodi virtuali.
Derivare e' cmq possibile e semplice, ma non la trovo sempre la
soluzione migliore.
Nell'altra risposta al tuo msg mi spiego meglio.


riscrivere codice che gia' esiste ;)
Questo e' giusto e l'ho scritto proprio ieri in un altro msg :)


Notification del nostro oggetto)...
Credo di non aver capito.... 8-)
La lista a cui mi riferivo sarebbe quella mantenuta dal componente,
che contiene i controlli che si vogliono monitorare. Per es. ho un
TEdit e 2 TDBEdit di cui voglio controllare il codice fiscale. Pero'
voglio che questi controlli non siano minimamente influenzati (quindi
niente agganci agli eventi di modifica dei controlli).
Li introduco in una lista del nostro componente, il quale, ad ogni
evento di modifica dei controlli in lista, verifica se contengono un
CF giusto e ne da' riscontro in qualche modo.
Spero di essere stato abbastanza chiaro...


Ragazzi... una diatriba cosě lunga non l'avevo mai vista !!!!  :D
Davide DG

Ragazzi... una diatriba cosě lunga non l'avevo mai vista !!!!  :D
Con solo 20 msg?? :)


un esempio, che incontro spesso.
Capisco.
Be', controllare questo singolarmente e' molto facile agganciandosi
all'OnMessage del form principale. Io l'ho fatto diverso tempo fa per
gestire il tasto invio come tasto terminatore dell'input per far
passare da un TEdit all'altro.
In pratica si intercetta l'evento WM_CHAR e si setta una variabile
EnterKeyHit a true se wParam (membro del tipo tagMSG) e' uguale a 13,
altrimenti a false e si fa in modo che l'evento risulti non gestito
(in modo che si attivi l'OnKeyPress di TEdit), poi dentro TEdit si
controlla che sia EnterKeyHit a true o meno e si agisce di
conseguenza.


all'OnKeyDown...
Daro' un'occhiata :-)


 Quella soluzione che ti propongo dovrebbe funzionare...che ne pensi?
Ripeto, teoricamente dovrebbe funzionare ma mi pare un po' azzardata...
Mhmm... cerco di spremermi un po' le meningi per inventarmi qualcosa,
speriamo che la mia buona stella mi illumini ;-)
Ciao :-)


speriamo che la mia buona stella mi illumini ;-)
OK, non ti preoccupare, tutto sommato ho chiarito i dubbi che avevo, e
in ogni caso posso vivere anche senza un Controller :-)


design pattern (o meglio, un idioma, in questo caso)
ma non c'e' gia' qualcosa tra i design patterns che riguarda i
controller ?


controller ?
Sai dirmi se e' reperibile in rete (purtroppo la mia unica fonte di
info per i DP, tuttora :( )? 
(Non ti scrivo in privato perche' penso che possa interessare ad
altri)


info per i DP, tuttora :( )? 
A dire il vero non ho cercato bene, pero' su 
www.programmazione.it
c'e' una sezione sull'OOD. Fai una prova.


 SENZA dover ogni volta fare la conversione da stringa a numero?
Erediti un componente da TEdit (o da suo discendente) facendo
File-->New-->Component e selezionando come ancestor TEdit...
Una volta che Delphi ti ha creto la unit aggiungi fra le proprietà published
una
property ValoreIntero:Integer read GetValoreIntero write SetValoreIntero;
dove GetValoreIntero e SetValoreIntero sono due procedure/funzioni private
della tua nuova classe:
procedure TTuaClasse.SetValoreIntero(valore:integer);
begin
 if valore<>Fvalore
     then begin
             Fvalore:=valore;
             Text:=IntToStr(Fvalore);
             end;
end;
procedure TTuaClasse.GetValoreIntero:Integer;
begin
Result:=StrToInt(Text);
end;
Attento che qui sopra non ho previsto nessun trattamento particolare per le
eccezioni, puoi usare dei blocchi try..except per trappare l' EConvertError
oppure usare la StrToIntDef ...


c'e' una sezione sull'OOD.
Si' uqella sezione l'avevo scaricata per intero in locale. Il
controller non e' stato ancora affrontato. Cmq, grazie
Saluti
