Newsgroup: it.comp.appl.access
Titolo: Righe di un combobox

E' possibile recuperare il numero
di righe correntemente accessibili
ad un combobox che insiste su una
tabella ?
Cioe' :
esiste una proprieta' del combo che
le riporta ?
In caso contrario, se da VBA voglio
sapere in quel momento quanti record
ha un combo, come potrei fare ?
Grazie.


La proprietą che puoi usare in un'espressione o in VBA
si chiama ListCount.
-- 
Ciao
Karl
*********
Access FAQ: 
http://www.donkarl.com/it

 si chiama ListCount.
Ho capito. E ti ringrazio.
Ma e' affidabile, o e' come il recordcount di ADO,
che se non fai prima un movelast ti da quello che gli pare
a lui ? :-)
Un' altra cosa :
e' possibile indurre spostamenti del cursore interno del
combo al record corrente ? Anche lui ha un eof / bof ?
Come funziona ? Al limite se hai un link me lo studio.

 Come funziona ? Al limite se hai un link me lo studio.
Non è chiaro cosa intendi con "spostamento del cursore
interno" e con "record corrente" (di cosa?).
Forse puoi descrivere in un altro modo (con un esempio?)
cosa vuoi ottenere.


cursore interno" e con "record corrente" (di cosa?).
Si hai ragione, scusa.
Cerco di spegarmi meglio, e aggiungo un' altra
domanda :
0) premessa
Ho studiato che tramite la chiamata di una API
e' possibile far "apparire" la lista di un combo
tramite VBA, "come se" l' utente ci cliccasse
sopra.
1)
Ma secondo te, una volta fatta apparire la lista,
e' anche possibile (come dire ...) "simulare"
tramite VBA la selezione dei record della lista
come farebbe l' utente ? Mi spiego ?
2)
E' possibile recuperare con VBA il nome della tabella
usata correntemente dal combo ?
Grazie Karl. :-)

 usata correntemente dal combo ?
Sta scritto nel rowsource (li c'e' l'SQL di selezione)?

 Come funziona ? Al limite se hai un link me lo studio.
Basta forzare l'uguagliamento del controllo al campo relativo del
Record corrente...
Ma a questo punto perchè non usare una Combo Associata con OrigineDati
una Query e gestendo l'evento NotInList se serve...!!!!!?????
Boh...!
@Alex

 Sta scritto nel rowsource (li c'e' l'SQL di selezione)?
È tutto meno complicato del concetto combo radicale. ;-)
-- 
Ciao
Karl
*********
Access FAQ: 
www.donkarl.com/it
 

Basta forzare l'uguagliamento del controllo al campo >relativo del Record corrente...
Che vuoi dire ? Non capisco.
Io ho in una variabile il codice, diciamo "0001".
Poi ho un combo associato a una tabella a 2 campi,
diciamo codice_, descrizione_ .
Se volessi sapere a quale descrizione_ del combo
corrisponde il codice_ = "0001" senza fare una
query sulla tabella associata al combo, ma SOLO
utilizzando le proprieta' e i metodi del combo,
come potrei fare ?
Mi spiego ?

 tutto meno complicato del concetto combo radicale. ;-)
0)
Ho letto, ok. Non serve una API, ma ormai l' ho fatta ... :-)
1)
Pero' , come dicevo ad @Alex, se io ho un combo C associato
alla tabella C_T con i campi codice_,descrizione_, e ho una
variabile c = "0001" e volessi sapere qual' e' la corrispondente
descrizione_ della tabella, e' possibile saperlo direttamente
dal combo, oppuere devo necessariamente fare una query sulla
tabella : select descrizione_ from C_T where codice_ = c;  ?
2)
Ecco perche' chiedevo come fosse possibile recuperare il nome
della tabella associata al combo : era per farci la query nel caso
non fosse possibile agire sul combo come detto al punto 1).
3)
Giustamente, Cara mi dice che la posso prendere dalla
stringa C.rowsource. Ma questa e' del tipo :
 "select ... from X where ..." e quindi dovrei fare un piccolo
algoritmo che mi estrae la parola X compresa tra "from" e
"where". Si puo' fare, ma risulterebbe lento.
E se poi un domani la parola "where" in un altro combo non
vi fosse ? Allora dovrei fare un algoritmo che prende la parola
X dopo il from fino alla prossimo spazio vuoto.
E se mi sbaglio a scrivere nel combo e scrivo :
select ... from      X  ... invece di
select ... from X ... ?
Allora devo fare un algoritmo di estrazione piu' intelligente,
ma cio' lo rallenterebbe ancora.
Non so se mi spiego ...

 Non so se mi spiego ...
Ti spieghi ma il "rallentamento" sara' al massimo qualche 
millisecondo(*), sicuro che una tale latenza sia un problema?
Con un accorto uso della *split* (o un paio di *instr*) dovrebbe essere 
abbastanza semplice.
(*) sempre che dovendo andare da Firenze a Bologna tu non decida di 
passare per il polo. Ma non mi sembri il tipo.

 ...
Se assolutamente vuoi cercare nella lista sarebbe persino possibile
di ciclarla, ma č meglio usare il recordset del controllo, p.e.
Dim rs As DAO.Recordset
Set rs = Me!cboPippo.Recordset
If rs.BOF Then Exit Sub
rs.FindFirst "Descrizione = '" & c & "'"
If Not rs.NoMatch Then Debug.Print rs!Codice
Dove cboPippo č il nome della casella combinata, perché
mi rifiuto di accettare "C" come nome di un controllo. ;-)
-- 
Ciao
Karl
*********
Access FAQ: 
http://www.donkarl.com/it
 

 mi rifiuto di accettare "C" come nome di un controllo. ;-)
Perche' C e' il simbolo della velocita' della luce ? :D
................. Per Alessandro
Cara .................................
Si, anche la soluzione della query non e' malvagia, se
l' algoritmo della ricerca e' ben fatto.
Peraltro (pensa che scemo) solo ora capisco perche'
il combo NON PUO' avere una proprieta' che riporti
il nome della tabella associata !
Per il semplice fatto che la query interna potrebbe
essere del tipo :
"select ... Form T1,T2, ... ,Tn ... ;" cioe' insistere
su PIU' tabelle.

 dim rs as ADO.recordset ?
Visto che ADO - in contrario a DAO - (non solo) in Access č
obsoleto da tanti anni, piů complicato, meno leggibile, spesso
un po' piů lento ecc. sarebbe una sciocchezza.
Ma siccome ami di complicarti la vita, puoi anche usare un
recordset di ADO. Cioč, prima impostarlo per la casella:
Dim rs As ADODB.Recordset
Set rs = New ADODB.Recordset
rs.Open "SELECT Id, Foo FROM tblPippo", _
    CurrentProject.Connection, adOpenKeyset
Set Me!cboPippo.Recordset = rs
e poi per cercare p.e.
Dim rs As New ADODB.Recordset
Set rs = Me!cboPippo.Recordset
rs.Find "Foo = 'blabla'"
Debug.Print rs!Id


 un po' pi lento ecc. sarebbe una sciocchezza.
ADO obsoleto ?!?
Ma scusa, ADO e' venuto *dopo* DAO !
Boh ...

radicale.002 ha scritto:

La classica ciambella che non aveva il buco.
--
ac

 Ma scusa, ADO e' venuto *dopo* DAO !
Ah, come tanta gente hai dormito le ultime 7-8 anni?
Ci sono stato milioni (1 L ;-) di discussioni su questa cosa nei ng,
ma qui la storia in breve:
1999-2002 (A00-AX) la MS dice che DAO è morto è che tutti
devono usare il nuovo ADO e ADOX; ADO è impostato come
riferimento standard al di sopra di DAO, alcuni nuovi metodi
di JET4 sono solo integrato in ADO non DAO.
La maggioranza degli sviluppatori di VBA non acceta ADO/ADOX
perché non è adatto bene ad Access, troppo complicato ecc.
Viene usato sopprattutto per i BE SQL Server, ASP ecc.
2002/2003 La MS presenta 
ADO.NET
 e dichiara ADO "classico"
come obsoleto.
2003 (A03) DAO è reimpostato come riferimento standard
al di sopra di ADO.
2007 (A07) In un nuovo accdb c'è solo il riferimento standard di DAO.
Le proprietà e metodi per i nuovi tipi di dati sono integrati in questa
nuova versione di DAO (Microsoft Office 12.0 Access Database
Engine Object Library) non più in ADO o ADOX.
Il problema è che tanti autori di libri e gente che ha seguito il
marketing della MS di ca. 1999-2002 e non hanno osservato
bene lo svolgimento, gente che seguono ancora i vecchi rumori ecc.
fino ad oggi credono che devono scegliere ADO o persino ancora
convertire le sue applicazioni da DAO ad ADO per essere moderno.
L'impatto di questa vecchia campagna pubblicitaria della MS
quasi 10 anni fa è affascinante.


 quasi 10 anni fa affascinante.
Per me tutto questo e' uno schock ... :-(
Sigh.
Ma dici che ADO sara' addirittura abbandonato ?
Riscrivere tutti i programmi ? ARGH !

 Riscrivere tutti i programmi ? ARGH !
Direi che la MS tenta di sostituire le sue tecniche di accesso
dati circa ogni 0,5-3 anni (0,5 = LINQ To SQL --> EF), ma è
quasi impossibile di prevedere quando veramente abbandonerà
una tecnica.
ADO non viene più aggiornato da anni, ma funziona ancora
con ACE, accdb e la nuova versione A10. Quindi per oggi
ed i prossimi anni non ci saranno grande problemi.
Solo se vuoi usare alcuni nuove funzioni di A07 o A10
devi (in aggiunto) usare metodi di DAO.


 una tecnica.
(omissis)
Ho capito.
Tutto sommato, devo "pensare" comunque di riscrivere
il programma per migliorarlo.
Sai come ?
Ogni volta che accedo ai dati, invece di scrivere : :
dim X as adob.recordset
X.open " ... "
faccio una funzione Y che , a seconda dei
parametri che gli passo, mi apre un recordset di un tipo o
di un altro ecc ecc (la devo ancora pensare bene)
tipo :
X = Y(p1,p2, ...,pn)
E un' altra per la connessione, se c'e' :
C = Z(s1,s2, ... ,sm)
In questo modo, se cambiano le tecniche di accesso e
supposto di usare solo un sottoinsieme limitato delle
possibilita' di ADO o DAO, basta che cambio *quella*
funzione e tutto il programma e' a posto.
Non ti pare una buona idea ?

 Non ti pare una buona idea ?
No, mi sembra inutile e non efficiente.
Inoltre non ti aiuterą se una volta la MS sostituirą
DAO e ADO con una tecnica molto diverso come
LINQ, EF o i supermacro di accesso.


 LINQ, EF o i supermacro di accesso.
Eh ! Ma a quel punto certo ... !
Quasi come dire che lo stesso VB venga abbandonato !
(quasi).

 e poi set X = f(p1,p2, ...pn)  ?
Cosa fai con New? ;-)
Non conosco i tuoi programmi. Io (e molti altri) uso DAO/ADO
solo se non c'è la possibilità di usare SQL o altri metodi di
un DBMS o integrati in Access. Spesso questi casi sono
complessi, andare avanti e indietro nei record, ottimizzati
con parametri speciali per DAO/ADO ecc.
Sarebbe impegnativo o quasi impossibile di generalizzare
questi tipi di operazioni che sono diversi in DAO e ADO.
Con una ventina di parametri una chiamata generalizzata
non mi piace più. ;-)
Quindi credo che si avrà di nuovo codice di DAO o ADO
in qualche luogo nel progetto.


 non mi piace pi . ;-)
Beh si, certo, la cosa funziona solo se si decide di usare solo
un sottoinsieme di funzionalita' ADO e DAO, altrimenti e'
improponibile.

 improponibile.
Ovviamente, anche queste funzionalita' devono essere
intermediate da funzioni !
Per esempio non puoi fare il MOVENEXT direttamente sul
recordset, ma devi fare il "concetto" di "spostati al prossimo"
con una tua funzione , del tipo grosso modo :
Sposta_Next (oggetto)
E cosi' via per ogni funzionalita'.

 La classica ciambella che non aveva il buco.
Errore...
Un buco senza ciambella!
Bruno