Newsgroup: it.comp.lang.delphi
Titolo: Aggiornamento Controlli Data-Aware

Salve!
Ho un piccolissimo problema con i controlli data-aware in generale.
Ho notato che essi aggiornano il dataset associato quando perdono
il focus. Ciň non č grave, ma vorrei che aggiornassero i dati quando
ci clicco su!
GRAZIE!
--
SecretFox

Usi i campi persistenti?
Bye
A

 
Clicca due volte sull'oggetto query o table oppure tasto destro -> Field 
editor se vedi l'elenco dei campi sono persistenti altrimenti no.
In sostanza quello che voleva dire Alberto (credo) e che se usi i campi 
persistenti puoi sfruttare proprietą/eventi dei singoli campi.
-Alberto correggimi se sbaglio-
cioa

"SecretFox" ha scritto nel messaggio

In genere il comportamento standard dei controlli data-aware č proprio
quello di aggiornare i campi a cui fanno riferimento nel momento in cui li
abbandoni. Mentre invece l'effettivo aggiornamento del contenuto della
tabella avviene solo quando esplicitamente viene attivato il metodo Post.
Cosa intendi con "ci clicco su"? Quale azione dovrebbe intraprendere
l'Utente?
Per aggiornamento del dataset, intendi aggiornare i valori dei singoli campi
ancora in memoria oppure direttamente il salvataggio in tabella?
Ciao,
Gianluca.

 L'importante è che aggiorni il campo associato sull'evento OnClick.
Per favore, cerca di quotare meglio... (se non sai cos'è il quoting
vai qui:  
http://go.to/iosononiubbo/
  [grazie Fabrizio Mancini per questo
link che credo userò spesso!])
Alcuni componenti (come DevExpress) hanno un meccanismo che fa esattamente
quello che chiedi. Un modo per imitarlo è sfruttare i vari OnChange,
OnClick... e aggiornare il campo del dataset "a mano".
Se scrivi codice sufficientemente generico (sfruttando per bene il parametro
Sender degli eventi, per esempio) puoi cavartela scrivendo due righe di
codice e riutilizzandole per tutti i componenti che ti servono...
HTH,
--
Andrea /\/\agni
ICQ#: 174108000


    Via De Gasperi, 14 - 42019
    Scandiano (Reggio Emilia)

 Ho un piccolissimo problema con i controlli data-aware in generale.
Non amo i controlli data-aware in generale, se non per prototipi.
Andrea

 Non amo i controlli data-aware in generale, se non per prototipi.
Non sarą di grande aiuto al nostro amico questo suggerimento. :-)


non so nelle ver successive, ma in d4 e forse in d5, se usi i campi
persistenti le modifiche non vengono "passate" direttamente dal controllo
dbaware al dataset sottostante, ma solo alla perdita del focus del controllo
stesso.
Ci ho perso un po la testa l'anno scorso
A

> Non amo i controlli data-aware in generale, se non per prototipi.
Domanda da 1 euro (vista la crisi che c'č...): xche?
A

Grazie a tutti per i suggerimenti!
Ma ho risolto...
...sostituendo i controlli data-aware con quelli standard :-(
GRAZIE!
--
SecretFox
"SecretFox" <nos...@ecspam.cxz> ha scritto nel messaggio
news:DLBOa.303$it4....@news1.tin.it...


 A
Andrea

 SecretFox
Andrea

 "particolari".
Può anche capitare che i DataControl eseguano funzioni che il
programmatore potrebbe dimenticare... ;-)


 programmatore potrebbe dimenticare... ;-)
Si, puň darsi, tuttavia continuo a preferire i controlli standard.
Vorrei ricordare, a chi l'avesse dimenticato, che i campi
persistenti numerici - per esempio - dispongono di una
funzione "DisplayFormat" che assolve perfettamente al compito di
fornire una base per la visualizzazione formattata.
Il discorso, insomma, č che utilizzare dei controlli data-aware
rischia di trasformarsi in un'arma a doppio taglio.
Le uniche eccezioni secondo me a questa regola di fondo e
generale sono i componenti DevExpress come la QuantumGrid.
Ciao
Andrea

 generale sono i componenti DevExpress come la QuantumGrid.
Quei componenti sono FAVOLOSI.
In una app risolvemmo forse l'80% delle richieste di visualizzazione dati
configurabile da parte degli utenti mettendo una quantum grid su un form e
settando poche property.
L'unico neo è che 'sta griglia ha una MAREA di property nella quale di
perdi.
Bye
A

 rischia di trasformarsi in un'arma a doppio taglio.
Qualche esempio?


generale sono i componenti DevExpress come la QuantumGrid.
allora il problema è su come sono programmati i controlli DB-Aware 
rilasciati con Delphi  ... :)
Io alcuni controlli DB di delphi li ho dovuti modificare a seconda 
delle esigenze, appunto per non far fare ad un metodo di chi 
contiene o usa il mio controlloDB qualcosa che in realtà potrebbe fare 
il controlloDB stesso.
Per esempio, se voglio che quando il mouse passa sul mio DBEdit questo 
deve aggiornare il suo valore dal db 
(cosa assurda che <<chissà perchè>> :P non ci hanno pensato 
gli analisti dei componenti di delphi)
farei in questa maniera.
erediterei da TDBEdit e farei l'Override del metodo protetto MouseMove 
definito in TControl classe presente nella gerarchia di TDBEdit
Procedure MouseMove(Shift: TShiftState; X, Y: Integer); Override;
lo inplementerei
procedure TMIODBEdit.MouseMove(Shift: TShiftState; X, Y: Integer);
begin
  inherited; //richiama il metodo nella prima classe
                 //della gerarchia che lo implementa o
                 //o lo reimplementa
  //qui va il codice per l'aggiornamento
  //nel qual caso chiamerei il metodo che il
  //TDBEdit usa per rileggere il dato dal Datasource
  //Al momento non mi ricordo :P
end;
e funzionerebbe su tutta l'applicazione senza dover andare a cercare
tutti i metodi di form o altri contenitori che fanno fare ai componenti i
vari compiti.
se voglio che questo comportamento funzioni solo in alcuni casi
aggiungo alla classe del mio componente una proprietà del tipo 
DisableMoveUpdate: Boolean Stored True;
in maniera che posso disabilitare questo comportamento dal Controllo stesso ...
così facendo non dico che non uso i DB-Aware anzi ne correggo o accresco
le funzionalità a seconda delle richieste e dei comportamenti 
che tale controllo deve avere.
Infatti prima di creare l'interfaccia grafica dell'applicazione mi faccio un conticino
di tutte i componenti visuali, e non, che userò e creo un mio package
con tutti i componenti che mi servono semplicemente ereditati da quelli di Delphi,
li uso e poi sono sicuro che posso intervenire al livello che mi pare su tutta l'applicazione
ed il codice sarebbe scritto in un posto solo.
Con il mio post non volevo essere polemico su una cosa che, magari,
dipende da esperienze passate (e forse io ne ho passate poche rispetto a te ;) )
ma semplicemente difendere la technologia DB-Aware che mi semplifica così
tanto la vita ;D 
forza DataSource ;)
	Ciao
	MassimoB
 

 Qualche esempio?
Uno su tutti, l'esempio che ha scatenato questo thread :-)
Un'altra cosa che non mi va, per esempio, è che sei "costretto" ad
avere per forza un dataset se vuoi fare un pò di data-entry e provare la
validazione, per esempio.
Ancora, per esempio, la "pesantezza" dei controlli stessi nei confronti di
quelli standard.
Senza contare che, alla fine, il vero punto di avere un controllo
data-aware è semplicemente quello di avere un aggiornamento
automatico dei campi, che si può fare meravigliosamente attraverso delle
funzioni scritte apposta che - tra parentesi - riescono meglio a separare la
parte di codice da quella visuale, cosa molto importante se per esempio
volessi portare la stessa applicazione su CGI/ISAPI ed in locale e magari
via
DCOM o altri sistemi di remoting.
Se usi i controlli data-aware uno scenario simile diventa molto
complicato da gestire, poiché in pratica hai due basi diverse di codice.
Se si centralizza la gestione solo in un punto, invece, mantenere il tutto
diventa molto più semplice.
Ciao
Andrea

 a separare la parte di codice da quella visuale, cosa molto
 
Sono d'accordo con te Andrea quando ti riferisci alla pesantezza
(specialmente del traffico di rete) dei componenti dbaware.
Sono d'accordo anche sul fatto che l'aggiornamento dei campi lo puoi /
dovresti separare dal db, svincolando l'interaccia utente dalla base di
dati. Forse però, piuttosto che sviluppare delle funzioni che assolvano
a questo compito, occorrerebbe ridisegnare praticamente tutta
l'applicazione in modo che sia OOP e si sganci un pò di più dal RAD. In
questo modo hai un BOM separato completamente dall'interfaccia utente
che può essere di qualsiasi tipo.  Se non adotti un database OO si deve
ripiegare su un OPF che tra l'altro offre il vantaggio di poter offrire
migrazioni tra db trasparenti, sempre che lo strato di persistenza
supporti il db.
I tempi di sviluppo sono più elevati rispetto al RAD, anche il tempo di
disegno dell'applicazione è maggiore. Il vantaggio, oltre a quello da
te citato, dovrebbe essere un miglior controllo, manutenzione e
robustezza del codice.
Ciao
Antonio

 MassimoB
Andrea

 tutto diventa molto più semplice.
Appunto. Se devo influenzare il modo in cui un valore di un campo viene
letto/scritto/rappresentato, lo faccio una volta per tutte sul campo
persistente associato al DataSet in uso, affinchè qualsiasi controllo
collegato veda le modifiche. Supponi di dover visualizzare in due form
diversi aventi controlli standard il valore di un campo che deve essere
moltiplicato per 10 in fase di lettura: dovresti modificare tutte le
procedure che leggono il valore del campo e lo moltiplicano per 10 per
visualizzarlo su controlli standard. Questo non mi sembra si possa
definire "centralizzato".
L'unica cosa di cui si può prendere atto è che i controlli data aware
sono fatti per costruire velocemente maschere di inserimento dati,
pertanto non contemplano tutti i casi e tutte le necessità presenti al
mondo, altrimenti l'ExpressGrid che hai citato non avrebbe mercato. :-)
Inoltre, a volte hanno dei piccoli bug, che sono del resto presenti
anche in altri controlli standard di Delphi...basta saper aggirare il
problema con qualche "workaround".


 robustezza del codice.
Mi ritengo un buon programmatore, ma penso che Borland abbia raggiunto
un livello *nettamente* superiore negli anni di implementazione e
miglioramento dei Data Control...più di quanto possa fare io nel
riscrivere da capo una nuova generazione di Data Control che
richiederebbero da parte mia la rivalutazione di tutti i casi d'uso,
ecc.
Forse, finirei con lo scartare i miei stessi Data Control per usare
quelli standard... ;-)


 Ci sarebbe da discutere, ad ogni modo DataSource <> Data-Aware :-)
Forse Massimo si riferiva al legame che ha il DataSource con il mondo
Data Aware...non voleva fare il confronto carattere per carattere delle
due parole intese come stringa... ;-)


Ci sarebbe da discutere, ad ogni modo DataSource <> Data-Aware :-)
Datasource + Datalink = Data-Aware :)
	Ciao
	MassimoB
 

 delle due parole intese come stringa... ;-)
ROTFL...
Io intendevo qualcosa di un pò diverso... :-)
Mi riferivo alle caratteristiche dei data source... vabbeh è una
cosa mia, lascia stare :-)
Andrea

 quelli standard... ;-)
Sono d'accordo anche su questo. Con qualche rara eccezione (vedi la
classe TList e TOBjectList e un mio post di qualche giorno addietro) i
programmatori di Borland hanno sviluppato un framework davvero
flessibile.
Ciao
Antonio

 quelli standard... ;-)
Sono d'accordo anche su questo. Con qualche rara eccezione (vedi la


 prima di parlare di database
Anche qui, non sono d'accordo (in generale): e' come se, invece di poter
compilare e ottenere una lista di tutti gli errori inseriti nel codice,
Delphi ti *costringesse* alla correttezza formale di ogni singola riga.
Sarebbe un incubo persino per un VBista <eg>.
L'utente imho ha il diritto di immettere tutte le schifezze che vuole;
l'importante e' che quelle schifezze non provochino il malfunzionamento
dell'applicazione. Esempio tipico: un controllo edit per l'inserimento
di valori numerici che non accetta cose tipo 1.25E5 e ti obbliga a
digitare tutti gli zeri.
Se poi l'utente effettivamente inserisce dati errati, e' utile che il
programma sia in grado di fare di meglio che mostrare l'eccezione
sollevata dal DB (magari nella forma "SQL Error: invalid char pos pp,
line ll").
Quanto sopra, ovviamente, quando non sia richiesto esplicitamente che
l'inserimento dati si deve bloccare al primo errore.
Infine, quanto alla questione generale del data-aware, personalmente
sono per il loro uso in read-only e, per i controlli normali in fase di
editing (mai vista la quantumGrid, potrei altrimenti avere un'idea
differente).
Saluti
Paolo Arosio

 Ciao
Ciao!


 cosa mia, lascia stare :-)
Beh, visto che si discute, tutti sarebbero curiosi di conoscere le "cose
tue"...se non me le dici, come posso confutarle? ;-)
Penso che sia una "cosa tua" anche la presa di posizione sui controlli
data aware, da escludere categoricamente a priori.
Non dico siano perfetti, ma sicuramente sono la soluzione più rapida da
adottare per realizzare velocemente applicazioni di accesso ai dati. Per
casi particolari, esistono i controlli DevExpress e tanti altri
controlli commerciali adatti allo scopo (interessanti quelli della
JediVCL).
Se il problema è nella "pesantezza" (da definire) di tali controlli e
poi tu mi implementi manualmente nel tuo progetto tutto il codice
affinchè un normale Edit si comporti come un DBEdit, praticamente
ottieni la stessa pesantezza con la differenza che hai dovuto scrivere
del codice aggiuntivo, sicuramente introducendo più errori di quanti ve
ne siano nel codice scritto, collaudato e ottimizzato negli anni dalla
Borland stessa.
Ciao!


 essere sufficiente.
In generale, hai ragione.
Però potrebbe verificarsi il caso in cui può essere utile validare i
dati dal lato client: se sai che un dato è errato già a livello
dell'applicazione, è inutile generare traffico di rete inviando lo
statement SQL di aggiornamento...sai già che il DB server lo rifiuterà.
Si tratta comunque di una finezza, inerente a questioni di
ottimizzazione e di performance, più che alla vera consistenza dei dati,
siccome la validazione da parte del server database deve comunque
avvenire.
Ciao!


differente).
io invece li uso in tutte le maniere ;) lettura/scrittura
solo che ho implementato un paio di metodi che modificano il
loro comportamento a seconda che siano in scrittura o lettura.
Cosa che tra l'altro già fanno anche se in maniera molto standard.
Infatti alle volte le richieste del cliente/programmatore sono tali
che il loro comportamento normale SEMBRA errato ;)
	Ciao
	MassimoB
 

 curiosità, ma poi non ne ho avuto il tempo. :-(
Basta semplicemente guardare la classe TList e l'introduzione a partire
da Delphi5 in poi del metodo virtuale Notify che non ha codice al suo
interno, inserito praticamente solo per supportare nella nuova classe
del framework, TOBjectList, la possibilità di distruggere gli oggetti
ivi contenuti.
E' ovvio però che per ogni cancellazione di elemento in un oggetto di
tipo TList viene chiamato un metodo che anche se non fa nulla, aggiunge
un considerevole overhead. Ma soprattuto quello che a me non piace è
l'aver modificato una superclasse solo per realizzare qualcosa nella
sottoclasse. E' molto poco OOP, IMHO. Secondo me l'uso della
delegazione sarebbe stato migliore.
Ciao
Antonio

 che il loro comportamento normale SEMBRA errato ;)
manfatti
Saluti
Paolo Arosio

quasi mai :/
Ok ... ma perchč abbandonare una technologia che secondo me semplifica la vita
come quella del DB-Aware ... questo detto al di la del fatto che i Controlli forniti
con delphi siano incompleti o troppo standard ... 
alla borland si sono dati tanto da fare per isolare i componenti
di visualizzazione del dato, dal dato vero e proprio, e dalla Technologia 
di accesso ai dati che vuoi usare, vedi DataSet,DataSetProvider,ClientDataset 
ed in fine proprio Datasource e Datalink (DBAware), perchč non usarli?!?.
ammetto di avere (forse) poca esperienza, ma per come lavoro
e per le richieste che ho, il DB-Aware va benissimo
poi le modifiche di comportamento le posso fare o migliorare anche
io, questo era il punto (credo di esserne capace :P ), l'unica cosa che mi interessa č che
il controllo mi mantenga un puntatore al "Dato" (Datasource->Dataset(->Fields)),
che possa sapere quando questo dato cambia e che possa 
dirgli quando e come cambiarlo. :)
	Ciao
	MassimoB
 

 della delegazione sarebbe stato migliore.
Ho controllato il caso del metodo Notify in TList. Beh, non la vedo una
soluzione così sporca.
Recentemente, sto sviluppando un'applicazione che fa uso intensivo di
componenti i quali necessitano di liste di oggetti creati dinamicamente.
Molto spesso, ho implementato manualmente il meccanismo di notifica che
la Borland ha pensato di inserire nella classe TList.
Basta pensare poi che questo supporto alla notifica di inserimento,
estrazione e rimozione di un oggetto vale per tutte le liste
discendenti, quindi anche per quelle realizzate ex novo dal
programmatore. Poi, le classi TObjectList e TComponentList sono state
ottimizzate per sfruttare questo metodo generalizzato. A mio avviso, non
si tratta di una violazione dei principi OOP: la Borland si è
semplicemente accorta, così come potrebbe accadere a qualsiasi
programmatore, che una certa funzionalità viene utilizzata in due punti
diversi (o potrebbe esserlo), pertanto ha provveduto a centralizzare
questa funzionalità (che ha senso appartenga alla classe base TList,
piuttosto che ad un discendente) in modo che possa valere per tutte le
classi TList discendenti.
In definitiva, sono stati modificati nomi di metodi? E' stata alterata
la struttura dei metodi preesistenti? E' necessario riscrivere codice
per adattare le proprie classi TList alla nuova struttura? No? Bene così
allora. :-) Ovviamente, IMHO.


 così allora. :-) Ovviamente, IMHO.
Vedi sopra, se la classe doveva avere un'efficienza straordinaria
secondo me probabilmente devi sostituire completamente la classe TList
con un'altra classe.
Ciao
Antonio

 con un'altra classe.
Ecco, secondo me, se c'era bisogno di un'efficienza straordinaria, si
doveva già sostituire da prima la classe TList con un'altra classe. ;-)


 Ciao!
Ciao
--
Andrea Raimondi
FAQ Datasnap
http://www.used-disks.com/Delphi/Datasnap

 base dati che rimanga uguale se cambio tecnologia di accesso ai DB??
tiOPF ;-) Puoi cambiare lo strato di persistenza addirittura a
run-time. Database supportati: SQL Server, MS Access, BDE Paradox,
Interbase, XML, Oracle via DOA e sto provando a sviluppare   uno strato
per FlashFiler 2.13, ma non è detto che ci riesca ;-).
Ciao
Antonio 

 Oppure non usi la OOP? :-)
???
Non ho ben capito la domanda sul "duplichi il codice?" o "uso la
OOP"?...
Parliamo di dati che non provengono da un DB?? Come ti ho scritto sopra,
in questo caso è inutile usare i Data Control, ma non è questa la
tipologia di esempio che dimostra la tua tesi.
Scusa, ma mi dimostri l'inefficienza di un Data Control citando un caso
in cui non si può utilizzare??
Siccome tu sostieni che non debbano *mai* essere utilizzati, dimostrami
per quale motivo io che sviluppo un'applicazione con dbExpress e
InterBase non dovrei usare i Data Control...rimango in attesa.
