Newsgroup: it.comp.lang.visual-basic
Titolo: VB6 - Chi ha perso il focus?

Avrei bisogno di sapere quale controllo ha perso
il focus nel momento in cui č stato premuto un
CommandButton di un form.
Io saprei farlo solo intervenendo su tutti i controlli
del form e memorizzando una variabile al LostFocus
di ogni controllo.
C'č un modo piů semplice?
Grazie per l'eventuale aiuto.
Sauro

 C'č un modo piů semplice?
Purtroppo metodi semplici non esistono (almeno .. io non ne conosco).
Io uso verificare la presenza del focus (_Gotfocus) sul controllo ed
memorizzare il riferimento al controllo durante l'evento in una variabile
dichiarata a livello di modulo.
Non funziona particolarmente bene perchč il focus potrebbe perderlo il form
container e l'evento GotFocus non viene alzato.
Saluti

 CommandButton di un form.
Scusa ma a che ti serve sapere chi ha perso il focus?
Deborah!

 C'č un modo piů semplice?
Piu' semplice non credo, pero' per evitare la duplicazione del codice su
tutti i controlli, potresti inserire un timer che periodicamente verifica
qual'e' il controllo attivo (ciclando tra gli oggetti contenuti nel form
container) e memorizza l'informazione da qualche parte.
Ovviamente il timer dovra' escludere i tuoi commandButton.
Attenzione perche' se usi degli oggetti contenitore all'interno del tuo form
ti tocca fare ciclare anche all'interno di questi.
Spero di esserti stato d'aiuto.
--
Starman

 Saluti
Anch'io sono arrivato fino al punto che descrivi.
Quello del container non sarebbe un problema, almeno per me, perchè
in realtà mi interessa sapere qual'è l'ultimo controllo "reale" che ha perso
il focus anche se subito dopo lo ha perso il container.
Grazie Fox Mulder per la tua risposta; almeno adesso so che questa è
la strada obbligata.
Ciao, Sauro

 Starman
Mah, non so.
Se il ciclo č poco frequente non č attendibile, se troppo frequente potrebbe
appesantire il tutto.
Ipotizziamo che una persona veloce digiti TAB (sul controllo 25) ancora TAB
(sul controllo 26) e poi Click sul CommonButton.
Il timer deve avere sicuramente scatenato il ciclo tra l'ultimo TAB ed il
Click
sul CommonButton.
Quanto tempo puň essetre trascorso? 1/10 di secondo? ancora meno?
Cosě tanto per discutere...
Ciao e grazie per l'interessamento.
Sauro

 Deborah!
Penso possa essere utile in diversi casi ma te ne descrivo almeno il mio:
Una dozzina di controlli indicizzati con 16 elementi ciascuno piazzati
su sedici righe del form.
Supponiamo (solo per semplificare l'esempio) 12 campi di un RecordSet
per 16 records nel form.
Quando l'utente clicca "Cancella record" bisogna sapere su che riga era
il focus per cancellare il record corrispondente.
Ciao Deborah.
Sauro

 Sauro
Andrea

 era il focus per cancellare il record corrispondente.
O_o fossi matto ! Non ci penso nemmeno a considerare il focus come una
proprieta' !!!
I tui 16 elementi hanno la proprieta' index , quindi tu elimini il
record(INDEX) !
PS: se vuoi proprio usare il focus allora la variabile la devi memorizzare
al GOT_focus e non al lost.
Il lost focus non viene correttamente scatenato, quindi rischi di cancellare
il record sbagliato. e poi scusa, con un Delete del record ti basi su eventi
cosi strani ?
Se sono griglie,liste ecc. allora elimini il record che corrisponde alla
linea selezionata, se sono textbox, label e simili ... umm... non eliminerei
nulla ^_^
-- 
<Gigio2K>
--- 
http://www.g2kweb.it/gigio2k
 ---
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/

 Andrea
Dai Andrea, non scherzare.
Senza offesa, prima di rispondere,
verifica che il cervello sia collegato o per
lo meno leggi meglio la domanda.
Ciao, Sauro

 Evento LostFocus.
:-/
Ma voi eliminereste un record di un DB basandovi sull'evento buggato
_lostfocus ?
Io non credo !


 container) e memorizza l'informazione da qualche parte.
minchia, buscarsi una polmonite per evitarsi un raffreddore, eh 
he he.
Duplicare due righette di codice triviale (che settano la 
variabile globale e stop) aumenta di un filo le dimensioni del 
programma.
Avere un timer attivo (tra l'altro con buona risoluzione 
temporale, "interval" molto frequente, se non vuoi rischiare 
frequenti falsi nella cattura dello status attivo, e non hai cmq 
la garanzia in quanto il timer fa un polling a tempi fissi, ma 
l'evento di cambio di focus č asincrono ed il possesso del focus 
ha durata assolutamente imprevedibile, senza un tempo minimo) ti 
influenza le prestazioni globali a livello di sistema 
complessivo ....
e' facile da implementare, ma non mi sembra una strada molto buona
ciao
CCCP++Mario


 Cosě tanto per discutere...
Era una soluzione proposta per fornire un'alternativa.
Io utilizzavo un metodo simile in VB5 quando volevo selezionare il testo
degli oggetti text quando ottenevano il focus.
Certo avrei potuto farlo sulla got_focus di ogni oggetto, ma e' quantomeno
scomodo duplicare il codice e aggiungerlo ogni volta che aggiungi un campo
nei form.
E' vero che TEORICAMENTE non si dovrebbe complicare l'esecuzione
dell'applicazione per favorire la stesura del codice, ma certe volte
preferisco prendermi delle "licenze".
--
Starman

 programma.
si ma che palle ricordarsi di doverle aggiungere ogni volta che aggiungi un
nuovo controllo al form.
Certo si potrebbero creare i controlli come matrice, ma mi da fastidio
perdere i nomi significativi.
Cmq si, in questo caso sono daccordo con te. La soluzione proposta e' poco
attendibile se l'utente vuole metterla in crisi.
Ma se dovessi sviluppare un programmino per me, io l'adotterei al volo.
--
Starman

 Ciao, Sauro
Ciao,
Andrea

[Sauro Vicchi = 
circa...@inwind.it
 in
2CEIc.49463$
c_1.1...@twister1.libero.it
] ha scritto:

Faccio un po' di casino anch'io?
La risposta esatta sarebbe proprio LostFocus, se funzionasse bene...
Sconsiglio vivamente qualsivoglia istruzione all'interno dell'evento
LostFocus.
Io lavoro al contrario. Ho un Controllo_Precedente e un Controllo_Corrente.
Lavoro sul GotFocus e magari anche sul Click (perchè con la tastiera e con
certi controlli tali eventi possono invertirsi nella sequenza normalmente
attesa). Quando sento il Got so anche chi era Controllo_Precedente e, magari
prima di assegnare Controllo_Corrente, ci faccio tutti i test del caso. Poi,
una volta esaurito il lavoro sul controllo abbandonato, assegno
Controllo_Precedente e Controllo_Corrente a quello che ha preso il fuoco.
No ho trovato un modo per non fare chiamate in ogni evento interessato (di
ogni controllo), ma mi sono fatto un programma che legge il file .FRM come
file di testo e introduce, riscrivendolo, tutti gli eventi per tgutti i
controlli che già non abbiano istruzioni negli stessi. In pratica modifico
il Form (introduco controlli e anche istruzioni, ma non negli eventi
interessati). Salvo il progetto, lo faccio passare a quel programma e lo
ricarico. Mi trovo tutto pronto. Le istruzioni ci sono e sono tante
(comunque una sola riga per evento interessato che chiama poi S/F comuni e
concentrate, ovviamente generiche e rfiutilizzabili), ma almeno non le ho
scrfitte a mano e non me ne posso dimenticare. Se capita, faccio girare il
programma. Ah, quel programma mi mette anche in ordine alfabetico di nome
tuttue le S/F, comprese quelle degli eventi.

 istruzioni negli stessi.
Bella idea ^_^ complienti !


 Bella idea ^_^ complienti !
Compli....   che ?

 tuttue le S/F, comprese quelle degli eventi.
Bella idea!
Ciao, Sauro

 (io non ne trovo nessuno)
"Prima" non ho ritenuto opportuno rispondere perchè non mi sento abbastanza
sicuro in VB.
Ma ora, visto il post di Lupo che ha ritenuto addirittura utile/necessario
di scrivere una routine che modifica i FRM per gestire questa problematica,
....
Ciao, Sauro

[Deborah = 
circa_debora...@hotmail.com
 in
hawIc.78159$
G%.43858@tornado.fastwebnet.it
] ha scritto:

Un buon applicativo deve essere anche operativo, anche nel senso che deve,
per quanto e più possibile, prevenire i possibili (e leciti) errori
dell'operatore, oltre che, naturalmente, segnalarli dopo.
Immagina di impostare in un campo una data non valida, per esempio 31022004.
Perchè mai il programma dovrebbe accettarla? Lo segnala e (secondo me) non
ci si deve spostare dal campo, fintanto che non si imposta un valore
compatibile con quanto il programma s'aspetta.
Ora immagina che abbandonare un campo (LostFocus) voglia anche dire, come
normalmente avviene, accedere ad una altro (GotFocus). Non importa quando,
come e dove le verifiche del campo abbandonato vengano fatte, ma, nel caso
esemplificato, può essere assolutamente necessario che le istruzioni
eventualmente previste nel GotFocus (o altrove) del nuovo controllo non
vengano eseguite, per esempio perchè potrebbero dare per scontato quello che
non è, generando situazioni imprevedibili.
Se io riesco a "bloccare" il GotFocus e, con tutta tranquillità, analizzare
il controllo precedente, posso anche forzare un nuovo GotFocus (con
Setfocus) al controllo precedente, uscendo dal GotFocus del corrente che, di
fatto, non ha fatto nulla e costringendo l'operatore a impostare
correttamente il campo che ha prima sbagliato.
Un altro esempio: Ho un bottone di ricerca comune sulla finestra e/o un
tasto che in tutta la procedura applicativa vuol dire "Cerca nel contesto",
supponiamo F5.
Sto caricando una fattura, il controllo corrente potrebbe essere il cliente
oppure l'articolo. L'operatore preme F5 e decide di cercare. Il tasto F5
attiva il bottone di ricerca e può facilmente stabilire quale fosse il
controllo precedente, cercando fra i clienti piuttosto che fra gli articoli.
Insomma, so perfettamente che molti programmi controllano l'intera finestra
solo quando si clicca su un bottone OK cumulativo, ma a me sembra un'emerita
sciocchezza, anche perchè in funzione dei valori man-mano impostati, la
finestra deve potersi adeguare alle nuove situazioni. Io controllo la
validità di ogni campo esattamente quando tende ad essere abbandonato (in
ogni modo, tastiera, mouse) e non faccio niente altro se non prima aver
controllato la perfetta coerenza nel contesto di quel campo. Se non va bene
riforzo il fuoco allo stesso (bada bene, nel frattempo è diventato il
precedente, quello di cui stiamo parlando) e l'operatore non potrà altro che
impostare un valore valido o uscire dal programma. Se no sta lì cent'anni!

 cent'anni!
E se clikko dal testo1 al testo3 ?
Cmq sia a me non piacciono + questi tipi di gestione maschere. Preferisco
quella rapida di "verifica finale"
Se e' ok -> Salva
Se non lo e' -> Avverti l'utente, "evidenzia" i campi mancanti e  manda il
focus al primo campo incriminato.
Tanto stiamo parlando di "Gestionali" che persone usano di frequente. Dopo
il primo mesetto (tempo medio utOnto) ci si abitua e se devo inserire solo
il campo A e C so che la data verra' inserita automaticamente se non la
specifico.
Poi come al solito solo regole di funzionamento che variano molto da
programma a programma e da programmatore a programmatore.
Poi adesso sto vedendo che gli utenti tastierofili stanno lasciando molto il
posto a quelli mousofili ... quando dico di premere F5 a volte ho paura che
premano F e 5 :-/


 volte ho paura che premano F e 5 :-/
In un gestionale si devono introdurre/consultare dati. Io curo molto (e
favorisco) l'uso della tastiera. Ti posso garantire che, tranne casi molto
particolari (intendo dire eccezioni anche per l'utente nel suo lavoro), coi
miei applicativi il mouse (sempre usabile, sia ben chiaro) può essere usato
molto, molto poco. Zero?, Sì, anche 0.

 chiaro) può essere usato molto, molto poco. Zero?, Sì, anche 0.
Idem! Poche settimane fa sono andato a fare una assistenza e una segretaria
mi ha stupito ! Usava il mio programma (gestionale light) con una velocita'
impressionante,
l'unica regola che mi sono inventato e' che facevo i tasti dinamici, cioe'
da 1 a 9 per le macrosezioni e poi le lettere per le sotto sezioni, vedevi
questa arzilla 40enne che premeva delicatamente numeri e lettere alla
velocita' della luce ... O_o
PERO' Sto cazzo di vizio di premere ok senza leggere il msgbox non se lo
toglie nessuno !
Mo gli tolgo il tabstop e li costringo a clikkare "Si" , poi "No" , poi "I
Agree"  e infine gli propongo un indovinello random e se rispondono giusti
gli stampo il messagebox iniziale e li faccio andare avanti !!!
PS: Viva il controllo alla fine, abbasso gli eventi buggati :p


 Posso ripetermi? Assurdo.
E perche'??? E' una modalita' a cui l'utente ormai si sta abituando o
comunque dovra' abituarsi lavorando sempre piu' spesso su web, dove
necessariamente la verifica avviene esclusivamente dopo il SUBMIT.
-- 
Starman

 necessariamente la verifica avviene esclusivamente dopo il SUBMIT.
Questo è semplicemente FALSO. Con JavaScript molte validazioni
possono essere fatte "on the fly". Non tutte, ma molte si.
Ciao,
Andrea

 possono essere fatte "on the fly". Non tutte, ma molte si.
Si va bene. Puoi fare le validazioni "assolute", cioe' quelle che non
dipendono da altre tabelle del database o roba del genere.
Non puoi controllare se un codice inserito e' valido, non puoi controllare
se un campo chiave e' gia' presente in archivio, ecc.
Si puo' fare qualcosina, e' vero, ma niente di "importante". La maggior
parte delle validazioni viene fatta dopo il submit.
-- 
Starman

 La maggior parte delle validazioni viene fatta dopo il submit.
Si, molte cose sono possibili solo dopo il submit ma - ripeto -
questo non comprende TUTTE le cose.
Ciao,
Andrea

 essere controllato prima.
parlo di controllo di esistenza in una tabella. A meno che non carichi in un
array tutti i valori per quel campo, ma e' improponibile nel caso di tabelle
molto popolate.
Cmq le situazioni variano caso per caso, cliente per cliente, applicazione
per applicazione, ecc.
-- 
Starman

 applicazione per applicazione, ecc.
Esatto.
Quello che sto dicendo io dall'inizio.
Andrea