Newsgroup: it.comp.lang.delphi
Titolo: Metodo migliore per controllare dati in DBEdit

Qual'č il metodo migliore per controllare dati inseriti in un componente
DBEdit, tipo se un numero č compreso tra o se una stringa č presente in un
altra tabella, e cosě via...
Conviene usare l'evento OnExit del controllo, OnChange, oppure... Accetto
consigli, grazie!
  Claudio

   Claudio
Beh... se puoi fai lavorare il BD: applica se possibile l'integrità
referenziale tra le tabelle..... se non si può lavora sui valori
minimi e massimi presenti in definizione del DB (con le giuste
cautele.... allargare il range significherà modificare la tabella)....
oppure se preferisci puoi usare codice a programma. Il metodo di
associare codice a eventi come OnExit o OnChanghe non è male.... ma
secondo me è preferibile associare una routine di controllo all'evento
del Campo del DB stesso: hai a disposizione
OnChange,OnGetText,OnSetText,OnValidate.... c'e' l'imabarazzo della
scelta! ;)
Ciao

"Claudio Zanetta"ha scritto

come giŕ detto da ElleCi fare un DB robusto č sicuramente buono ...
fare un dataModule ancora + robusto ... usando i dataChange ed i vari eventi
dei datasources e dataset č altrettanto buono ... cosě come porre dei
costrain sui campi
ma purtroppo molte volte arrivano dei db vecchi e brutti di cui non puoi
cambiare niente ed
in cui i valori sono spezzettati in una moltitudine
di campi e tu li devi rimettere insieme ... girare voltare etc..
(es. una stringa di 70 Char divisa o meglio troncata in due campi da 35,
tipiche cose da output a caratteri di una decina d'anni fa forse)
tornando ai DBEdit essendo questi legati mediante un DataLink ad un
datasource e quindi
direttamente agli eventi del dataset, li puoi sfruttare correttamente per
porre un primo
filtro sull'input dell'utente (e questo forse gia lo sapevi ;) )...
la scelta dell'evento dipende da cosa vuoi ottenere
per esempio
-se non voglio che in un DBEdit legato ad un campo di tipo Char vengano
inseriti numeri
uso l'evento keyPress che mi passa il Key premuto dall'utente ...
se il key non mi piace lo pongo uguale a #0 (valore ascii nullo) e non mi
stampa il carattere.
se invece questo stesso controllo l'avessi messo solo nel DataChange del
dataSource per esempio
credo che l'utete il numerello l'avrebbe visto lo stesso e poi al post
avrebbe avuto una sgradevole finestra di
errore chiedendosi "perchč me lo fanno mettere e poi mi dicono che ho
sbagliato a metterlo?" ;)
- se invece voglio controllare l'intera stringa immessa nel DBEdit ogni
volta che questo cambia
uso l'evento OnChange attivato ad ogni cambiamento del Text
dovuto o all'utente che scrive o ad un cambiamento di record del DB
quindi l'onChange puň essere usato anche per rilevare un cambiamento
"indipendente" dall'utente.
comunque rimane il fatto che ogni singolo caso ha l'evento e la classe che
meglio lo soddisfa ...
generalizzare si puň ma č sempre meglio analizzare bene il problema e a che
livello si vuole intervenire,
e poi l'evento giusto viene fuori da se ... :) (magari fosse sempre cosě
;) )
non so il tuo caso specifico ... ma gli eventi a cui di solito mi affido
meno
sono gli eventi OnExit, OnEnter perchč non rispecchiano una reale azione
dell'utente sul valore
anche se nei controlli DB come DBedit etc in loro corrispondenza avviene un
lettura/verifica/immissione del dato
ma a questo punto preferirei andare ad un livello piů basso tipo datasource
o dataset
se posti qualche info in piů, magari, possiamo vedere di scrivere quelcosa
di meno generico ;)
scusa l'italiano delle due di notte...
  ciao
  Mak

altra tabella, e cosě via...
Io delego questo tipo di controlli all'uscita dalla maschera, per
esempio ad un tasto "Conferma".
-- 
Andrea Laforgia
www.geocities.com/andrealaforgia
"640kb of memory should be enough for anyone." -- Bill Gates.

Vorrei evitare di controllare tutto solo all'uscita, ma bensì in fase di
inserimento da parte dell'utente, nella maniera più precisa possibile, ad
esempio io di solito uso OnKeyPress per non lasciare inserire lettere dove
vanno numeri o cmq caratteri non permessi (anche in posizioni non permesse,
usando DBEdit.SelStart, che mi permette di controllare l'input in maniera
precisissima), vorrei sapere però dove sostituire i controlli che adesso io
metto OnExit, tipo se il testo inserito è già presente nella tabella o se un
numero è compreso tra altri (SENZA intervenire nel DB, ma solo sui
componenti DBEdit).
OnExit mi sembra poco preciso, in quanto obbliga l'utente a spostarsi su un
altro campo prima di vedersi validare il dato.
Ciao
    Claudio

"Claudio Zanetta" ha scritto nel messaggio

In un TDBEdit, l'input è dipendente dal tipo dati e dalle caratteristiche
del campo TField associato.
Per evitare il ripetersi del codice io utilizzo in particolar modo tutte le
proprietà che agevolano l'editazione senza costringermi a scrivere codice.
Dal mio punto di vista la maschera dovrebbe contenere meno codice possibile
e delego tutti i controlli agli eventi OnValidate dei TField associati. Nel
BeforPost della tabella, eventualmente, richiamo in cascata tutte le
procedure OnValidate ed eventualmente aggiungo il codice specifico.
Questo ovviamente se utilizzo dei TField persistenti.
Ciao.
Gianluca.

 e delego tutti i controlli agli eventi OnValidate dei TField associati.
e anche qui non posso che essere in accordo
per i controlli di validità da punto di vista di valore DB
o concretezza del dato (range accettabili, condizioni, etc ...)
è più che giusto ...
ma se io ho un'applicazione a più form
che gira stulla stessa table, imho, delegare i controlli
dei cambiamenti di altri componenti dell'interfaccia
(esempio: sincronizzare una tabella grafica ripetto al valore del DBEdit)
o restrizione sull'input dell'utente
(esempio emblematico: non voglio numeri in un DBEdit su campo stringa ...),
ai singoli DBEdit (o simili) sia una cosa che semplifica.
in più l'utente è avvisato nel momento in cui digita
o comunque sta compiendo l'azione di input
e non quando il controllo perde il fuoco (OnExit)
(questo si basa sul fatto che mi ricordo che i componenti di controllo DB
chiamano la validazione del dato sull'uscita dal controllo ...
correggetimi se sbaglio ;) )
  ciao
  Mak

esempio ad un tasto "Conferma".
Cosi' faccio anch'io.
Creo una funzione privata che ha lo scopo di verificare tutti i dati che
stanno per essere inviati al db, in caso di errore posiziono l'input sul
controllo colpevole.
Ecco un template della mia procedura standard (applicativi ramo gestionali)
Quando l'utente clicca sul bottone Salva, scatena questo evento:
procedure TfrmAnagraficaClienti.btSalvaClick(Sender: TObject);
var s : string;
begin
   if CheckAllData then begin
      try
         AnagraficaClienti.Post;
      Except on E: Exception do begin
         s :='Errore durante il salvataggio!'+#13+#10+'Errore: '+E.Message;
         MessageDlg(s, mtError, [mbOK], 0);
         MainForm.DbgMainFrm.LogError(s);
         end;
      end;
   end;
end;
Mentre la procedura di controllo (CheckAllDAta) e' cosi' strutturata.
function TfrmAnagraficaClienti.CheckAllData: Boolean;
begin
   Result := True;
   if trim(DBRagSoc.Text) = '' then begin
      result := False;
      MessageDlg('La ragione sociale è obbligatoria', mtError, [mbOK], 0);
      DBRagSoc.SetFocus;
   end;
   if ((Result) and (Trim(AnagraficaClientiIndir.AsString) = '')) then begin
      result := False;
      MessageDlg('L''indirizzo è obbligatorio', mtError, [mbOK], 0);
      DBIndirizzo.SetFocus;
   end;
   if ((Result) and (Trim(AnagraficaClientiComune.AsString) = '')) then begin
      result := False;
      MessageDlg('Il comune è obbligatorio', mtError, [mbOK], 0);
      DBComune.SetFocus;
   end;
end;
-- 
Morde. 
morde[at]programmer[.]net

altro campo prima di vedersi validare il dato.
Ti consiglio di evitare di mettere dei blocchi sull' OnExit. 
Alcuni utenti si infuriano quando cliccano da un'altra parte e l'input viene
catapultato sempre sullo stesso controllo, imho (moolto imho) l'utente
dovrebbe essere libero di poter fare qualsiasi cosa sulla maschera, tranne
bloccarlo e cazziarlo nel solo momento in cui clicca sul "Salva".
L'utente deve avere la massima liberta' sulla maschera.
Ciao


Ho postato un paio di giorni fa questa domanda, ma non ho ancora
ricevuto risposta, penso che tra voi ci sia (quasi) sicuramente chi
possa sapere come fare. Quindi riposto la domanda nella speranza che
qualcuno mi risponda. Grazie...
Salve!
Ho il seguente problema: nella mia form devo visualizzare alcuni campi
che tiro fuori da un db Access, e tra questi ho un campo del tipo
'orario'.
Ossia voglio che mi venga mostrato l'orario con il formato hh:nn:ss
(ore:minuti:secondi). Ho impostato correttamente il data-base dicendo
che il campo deve essere di tipo 'ora estesa'.
Per quanto riguarda delphi, nel mio data-set (linkato da un data-source)
ho cambiato (a design time) le proprietą di FieldDefs mettendo DataType
= ftTime (al posto di ftDateTime), e in Fields ho messo DisplayFormat =
hh:nn:ss e EditMask = 00:00:00;1;_
A questo punto, se lancio l'applicazione, il mio campo viene
visualizzato correttamente (supponiamo 12:34:56) ma se tento di
editarlo, spostando il focus, il campo si trasforma in 30:34:56.
Il 30 immagino derivi dal fatto che la data 0 altro non č che
30/19/1899.
C'č qualcuno che mi sa dire come risolvere questo problema?
Eventualmente posso inviare il codice sorgente.
Saluti! e grazie.
Ale.Ber
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG