Newsgroup: it.comp.appl.access
Titolo: Oggetti ed interfacce in VBA/Access

Sto facendo delle prove per utilizzare i moduli di classe in Access e
mi sono imbattuta nel sito di Alessandro Baraldi dove ci sono alcuni
esempi.
Qui 
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=271
 c'è un
bell'esempio di come simulare gli array di controlli utilizzando le
interfacce.
Non riesco però a capire perchè nella classe che definisce il nuovo
oggetto  (clsArrayTextBox ad esempio) viene creata un proprietà che
del tipo della classe che è l'interfaccia (IItemTextBox) a cui poi
viene assegnato come valore l'oggetto form che contiene effettivamente
gli oggetti (textbox) che voglio gestire simil-array. Perchè il form?
Oltre a questo, stavo provando a fare un'interfaccia e per le mie
esigenze devo usare il metodo "exit", ma...  la definizione:
Public Sub Exit(ControlIndex As Access.TextBox, Cancel As Integer)
   'T
End Sub
viene rifiutata perchè Exit è una parola riservata...
Dove sbaglio? E' un limite del sistema?

Michela DiGiacomo ha scritto:






Sì non puoi usare le parole riservate
ma se già la chiami myExit funziona
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Dove sbaglio? E' un limite del sistema?
Mi perdoni @Alex ma non e' detto che ti serva tutto l'ambaradam delle 
interfacce.
Il problema della exit e'probabimente legato al  fatto che esistono le 
clausole Exit sub, exit loop, exit for e potrebbe essere un limite del 
sistema
----clsTxtBx
Option Compare Database
Option Explicit
Public WithEvents oText As TextBox
Public Function setItem(oTx As Control)
Set oText = oTx
End Function
Private Sub oText_Exit()
......blablabla
End Sub
-----su form
Option Compare Database
Option Explicit
Private colChecks As New Collection
..........
Private Sub Form_Load()
Dim objTx As clsTxtBx
Dim oCtrl As Control
For Each oCtrl In subMesi.Form.Controls
     If oCtrl.ControlType = acTextBox Then
         Set objTx = New clsTxtBx
	oCtrl.onExit = "[Event Procedure]"
         objTx.setItem oCtrl
         colChecks.Add objTx
     End If
Next
End Sub
Questa roba fa comunque il suo porco lavoro e non usa l'interfaccia
-- 
ac (x=y-1)

 > viene rifiutata perchè Exit è una parola riservata...

L'uso dell'interfaccia è un'escampoage perchè quando inserisci una
Classe in una Collection non ne puoi gestire gli EVENTI PUBLIC...!
Se invcece inserisci un Controllo in una Collection ovviamente questo
è possibile...!
Mi spiego meglio...!
La classe Eredita gli EVENTI dell'Oggetto Textbox, quindi internamente
si gestise gli EVENTI.
Se inserisco la Classe in una Collection, nel caso la Classe Avesse
EVENTI PUBLIC non li puoi ereditare nella Form, in quanto
l'inserimento nella Collection lo vieta...!
Siccome nel mezzo c'è una classe Collection.... la cosa si complica...
no in realtà, ma sembrerebbe...!
L'uso delle interfacce realizza questo nello specifico... guardalo
BENE.
@Alex

 Dove sbaglio? E' un limite del sistema?
Ciao
@Alex


Ciao Ale
Rileggendo meglio... quello che hai scritto è quello che normalmente
si fa e non fa una piega
se la Classe gestisce interamente tutto.
Nel caso in cui nella Form tu debba gestire altro codice legato al
Controllo, o nel caso in cui la classe esponga Eventi PUBLIC, quel
sistema falllisce.
Ora lascia perdere l'esempio specifico con il quale concordo con te
sulla considerazione... ma è importante sapere che anche usando
Collection è possibile
ereditare EVENTI di CLASSE...!
Ciao
@Alex

 è possibile...!
La cosa che dici non mi e' molto chiara.
Una interfaccia, al di la' di quello che dicono gli esperti, l'ho usata 
in linguaggi "evoluti" (si fa per dire) che non consentono di 
"autogestire" l'oggetto passato. Questo in qualche misura avviene anche 
in VB e VBA ma e' facilmente superabile se si passano oggetti generici 
(i.e. variant e/o control). Al contrario di altri linguaggi se passo un 
oggetto generico e so di che tipo e' quell'oggetto posso accedere a 
metodi e proprieta' sconosciute all'oggetto generico passato.
Questa cosa non e' possibile per i sunnominati linguaggi evoluti e 
quindi si e' costretti a segnalare al sistema di farsi i fatti suoi ed 
accettare un oggetto di tipo interfaccia a prescindere dall'identita' 
della classe passata e ad onorare tutti i metodi stabiliti dal 
"contratto" di interfaccia.
Per esplicitare ( a terzi ). Quando faccio una chiamata ad una funzione 
ed in tale funzione ho definito che il parametro e' di tipo x (ad es. 
string) se passo un parametro di tipo diverso il sistema si incavola, se 
invece definisco un variant il parametro passato puo' essere di 
qualsiasi tipo ed il sistema lo accetta e non si limita solo ad 
accettarlo ma mi consente di usarne metodi e proprieta'. Naturalmente e' 
mia responsabilita' sapere che tipo di oggetto si e' ricevuto e 
comportarmi di conseguenza. Se ricevo una form e' evidente che non posso 
acceder alla proprieta' Count, se ricevo una Collection e' evidente che 
non posso accedere alla proprieta' onExit.
Nella fattispecie ti posso assicurare che gli eventi innescati sul 
controllo TextBox vengono onorati da quanto definito nella clsTxtBx.
-- 
ac (x=y-1)

@Alex, sei Alessandro Baraldi?
Scusate l'ignoranza, ma pur non essendo una neofita di Access, non ho
esperienza di programmazione ad oggetti, non avendone mai prima d'ora
sentito la necessità. Io avevo capito così:
per codificare le istuzioni relative agli eventi della classe
clsArrayTextBox nel modulo del form in cui stanno i TextBox, devo
utilizzare il sistema dell'interfaccia, Quindi ogni form che usa
questi oggetti e implementa "IItemTextBox" può ridefinire il
comportamento da adottare per ogni evento.
Col metodo suggerito da Alessandro Cara, il comportamento è statico
perchè definito un volta sola nella classe.
Ma forse mi sbaglio...
Rimane il dubbio del perchè assegnare il form alla variabile oggetto
nella classe clsArrayTextBox...
Forse perchè è l'unico modo per inserire il codice relativo agli
eventi nel form stesso? non basta "Implements" ?
Istintivamente, essendo il nome "IItemTextBox" della classe-
interfaccia, io avrei assegnato un TextoBox.
Ok, forse mi rispondo da sola: siccome i TextBox sono più d'uno, (lo
scopo è proprio questo), uso come oggetto il form che per logica è il
contenitore dei TextBox stessi...
Infine mi par di capire che non c'è modo di definire l'evento "Exit"
nell'interfaccia e posso (devo) usare un'altra definizione (bah!).

 > Se invcece inserisci un Controllo in una Collection ovviamente questo

L'interfaccia in se non è nulla e non fa nulla, se non consentire ad
una Classe di implementare i Metodi/Eventi/Proprietà
esposti dalla Classe Interfaccia...
Se però io gioco con l'assegnazione degli Oggetti e se non ti scappa
nell'Esempio assegno ad una Classe l'oggetto PADRE... questo mi
ribalta esattamente la chiamata all'interfaccia nell'oggetto PADRE che
la implementa...
Guarda questo esempio... è banalissimo, ma forse è più chiaro di molte
parole...!
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=299
E' composto in 2 esempi... il primo DEMO è sostanzialmente quello
Classico Standard che hai giustamente detto tu...
Il 2° fa riferimento alle Interfacce e trovi DEMO_I... con le Classi
relative[_I]...
Nulla di chè in tutto... ma osservalo BENE come funziona... ;-)
@Alex

 nell'interfaccia e posso (devo) usare un'altra definizione (bah!).
Il problema di EXIT è che non è solo il nome di un EVENTO... ma è
proprio un'istruzione...
EXIT SUB
EXIT FUNCTION
EXIT FOR
Come vedi Exit è usato in moltissime ISTRUZIONI... ed al contrario
degli EVENTI
chiamati MOUSEMOVE o altri che sono accettati ... EXIT purtroppo
incasina molto le cose...!
Tuttavia se ti dai uno standard potresti aggirare il problema
definendo nella Classe Interfaccia
gli Eventi con un suffiso....
Public Sub I_MouseMove(.......)
   '
End Sub
Public Sub I_Exit(....)
  '
End Sub
Ciao
@Alex

... EXIT purtroppo  incasina molto le cose...!
Ok: un limite del sistema.... :-)

 Ok: un limite del sistema.... :-)
Perchè insisti sul limite del SISTEMA... non lo è ...
Prova a verificare bene come si chiama l'evento EXIT di un controllo
TextBox...
Si chiama "OnExit"... non "Exit"...
ciao
@Alex


Il limite sta nel fatto che non puo essere usato un identificatore
perchè è una parola riservata e, vabbè, fin qui è una cosa ordinaria.
Il problema è di congruenza: questo limite fa si che uno standard
creato dalla Microsoft non può essere adottato ("IlMioTextBox_Exit")
in un sistema Microsoft per i problemi già citati.
E qui mi viene in mente un'altra chicca: l'evento OnEnter. Sai quanto
tempo ci ho perso per capire che non era l'esatto opposto di OnExit?
Eppure è uno standard consolidato, ma è forviante! :-)

 nella classe clsArrayTextBox...
Magari anche @Alex ogni tanto si concede qualche licenza poetica ;-{)
[cut]
-- 
ac (x=y-1)

 Nulla di chè in tutto... ma osservalo BENE come funziona... ;-)
L'ho osservato ed ho qualche dubbio sia su quanto riporti nelle note al 
codice che nel corpo form. Riguardo sia la possibilita' di intercettare 
il controllo attivo che il fallimento dell'evento su corpo, in prima 
approssimazione, mi sembra fallisca sull'evento MouseMove dei controlli. 
Nel demo con le interfacce per evitare il ciclo sui controlli, se non 
vado errato, ti conservi una chiave da qualche parte questo e' possibile 
anche non usando l'interfaccia.Per giocare sto inserendo un terzo demo.
-- 
ac (x=y-1)

 Si chiama "OnExit"... non "Exit"...
Consentimi di dissentire.
La proprieta' che contiene i riferimenti al codice da eseguire 
sull'evento si chiama onEvento.
-- 
ac (x=y-1)

 ac (x=y-1)
Cia
@Alex


wrote:

Non ho capito.... ;-(
Ciao baffo...
P.S. se non fossi stato operato, la prossima settimana sarei stato
dalle tue parti e Vi avrei proposto il BIS...
Sono molto dispiaciuto, ma vedremo di ripetere la cosa.
@Alex

 ac (x=y-1)

 dela classe-interfaccia ....
La mia banca e' differente ;-{)
In questo @Alex ed il sottoscritto non sono sulla stessa lunghezza d'onda
-- 
ac (x=y-1)

AAAAAAAAAAAARGH!!!!!!!!  BAFFO TU MI CONFONDI!!!!
%0     <------ quella è una faccina