Newsgroup: it.comp.appl.access
Titolo: Realizzare controllo griglia in Access

Dunque, come dicevo nel post precedente, ho un controllo griglia
emulato in Access.
Devo revisionarlo e sto valutando se inglobare il tutto in
un'intefaccia ad oggetti.
La versione di Access su cui lavoro è la 2003.
Attualmente il sitema griglia è composto da una sottomaschera che
contiene fisicamente tutti i textbox che rappresentano le celle, le
intestazioni e una listbox che sposto e accendo alla bisogna.
Le intestazioni di riga sono posizionate nel form principale per
evitare lo scorrimento orizzontale.
Il numero massimo di colonne fisiche max attuale è 23, le righe 31...
Come si capisce nella sottomaschera ho 23*31 celle + 23 intestazioni +
1 listbox = 737 controlli !!!
Molto vicino al limite massimo di controlli utilizzabili in un form.
Il tutto è parametrizzato tramite delle tabelle in modo che righe e
colonne siano diminuite (nascoste) all'apertura in caso ne servano
meno, le colonne fisiche sono raggruppate in colonne logiche che hanno
una stessa intestatione che cambia di volta in volta, i valori
inseribili sono definiti a priori, esistono regole per cui un valore
può comparire in una sola o più colonne logiche (specificando le
compatibilità), l'inserimento avviene digitando con completamento
automatico, con mouse ed elenco a discesa, con mouse selezionando un
valore da  un elenco e cliccando sulla cella dove inserirlo, nella
maschera principale ho dei totali relativi al "peso" assegnato alle
colonne logiche (per riga, per gruppo di righe, per tutta la griglia)
Uff, mi pare sia tutto...
Il limite delle 23 colonne fisiche è quello dato dalla stampa: perchè
siano leggibili, su un foglio A4 in orizzontale sono riuscita a
mettere al max 23 colonne.
Ora purtroppo servono più colonne e dovrò stampare su più pagine, ma
questo è un problema successivo.
In una versione più "antica" avevo realizzato un form appoggiato su
una tabella temporanea con una combo per ogni colonna. Il risultato
era efficace ma bruttino da vedere e con alcuni limiti.
Vorrei adesso mixare le due cose utilizzando magari un recordset ADO
"al volo", come illustrato ad esempio sul sito di @Alex:
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=267
 e creare
una sorta di frontend ad oggetti (griglia, cella, riga etc) che
avvolga tutto questo accrocchio.
Ovviamente non ho trovato un controllo grid già pronto che mi
soddisfacesse, anche perchè la mia applicazione non è commerciale e di
controlli grid a pagamento non se ne parla.
Si accettano consigli e opinioni...

 Si accettano consigli e opinioni...
Non puoi più facilmente aprire EXCEL via OLE e poloparlo usando il
VBA...????
Nel caso l'idea non fosse soddisfacente, ma ti invito a prenderla in
serissima considerazione perchè EXCEL è la GRIGLIA più potente
che esiste sul mercato e da Access è FULL_ACCESS puoi ereditare anche
gli Eventi del Foglio se usi EarlyBinding e tutto quello che serve..,
sarebbe bene prendere visione di un Demo, perchè sinceramente io non
userei tanto nè classi nè interfacce, quanto più un'array
Bidimensionale di controlli sfruttando il Nome delle textbox in modo
intellignete...
Es:
Riga 1 Colonna 1 ---> txtCella_1-1
Riga 1 Colonna 2 ---> txtCella_1-2
....
Riga 31 Colonna 23 ---> txtCella_31-23
In questo modo riesci a relazionare gli indici della matrice con il
Nome stesso del controllo...
Chiaramente questa è una pura riflessione ad alta voce... molto banale
non comprendendo a pieno l'esigenza.
Saluti
@Alex


Ok, mi trovi d'accordo con questo metodo, anche perchè è più o meno è
quello che uso attualmente :-)
Di fatto non ho usato array aggiuntivi, perchè i dati sono già
contenuti nei campi e con i nomi così strutturati posso scorrere righe
e colonne abbastanza agevolmente.
Ad esempio:
For n = 1 to MaxColonne
    Me("txtCella_01" &  format (n, "00")).FontBold = True
Next
La parte più rognosa e cioè la gestione degli eventi per ogni singolo
controllo, è stata risolta in un modo un poco maccheronico ma
efficace: con un modulo di comodo mi sono generata il codice per far
puntare tutti gli eventi dello stesso tipo ad una singola Sub o
Function, portando dietro il nome del controllo:
Open "c:\pincopallino.txt" for output as #1
For n = 1 to MaxRighe
   For m = 1 to MaxColonne
         Print #1, "Private Sub txtCella_" & Format(n, "00") & "_" &
Format(m, "00") & "_Exit(Cancel As Integer)"
         Print #1, "   Cancel = CampoExit(""txtCella_" & Format(n,
"00") & "_" & Format(m, "00") & """, Cancel)"
         Print #1, "End Sub"
         Print #1, ""
   next
netxt
close #1
Quindi aprendo pincopallino.txt e copia-incollando il codice nel
modulo del form per poi ignorarlo per sempre, devo solo crearmi la :
Function CampoExit(NomeCampo As String, Cancel As Integer)
     ' Gestione dell'evento exit in funzione del nome del campo....
End Function
Certo che, quando devi gestire 5 o 6 eventi, il codice di appoggio
diventa mezzo chilometro, però lo lasci in fondo al modulo e non lo
guardi più.
Il problema che ora devo affrontare è quello di raddoppiare il numero
di colonne fisiche gestibili.
Col sistema attuale, la cosa diventerebbe già improponibile per il
numero elevato di controlli, in più c'è il limite imposto da Access al
numero di controlli in un form.
Devo quindi tornare ad un recordset di appoggio (magari in memoria) e
un form multiriga.
Il bello sarebbe stato il conglobare tutto in un rigoroso oggetto Grid
a cui accedere con proprietà e metodi e magari utilizzare una
collection invece del generatore di codice "casalingo" per le colonne.
Altro discorso sarebbe stato il poter gestire maualmente lo scroll del
form e tenere nel form stesso solo il numero di colonne visibili + 1
(o 2) e visualizzare solo una finestra di un array che contiene tutti
i dati.
Forse si sarebbe potuto visualizzare i dati con Label e utilizzare un
unico Textbox solo quando si entra nella cella da editare.
Ma non ho trovato in giro niente per lo scroll e temo che i tempi di
risposta (aggiornamento di tutte le celle) sarebbero stati
insoddisfacenti.
Mi sono dilungata un po'...


Se non sei allergico agli ocx, io uso spesso questa:
http://vbaccelerator.com/home/VB/Code/Controls/S_Grid_2/S_Grid_2/article.asp
fornita comunque con codice sorgente se te la vuoi modificare, 
analizzare, studiare...di una semplicità da gestire disarmante.
Fai praticamente tutto, puoi pure inserirti immagini nelle varie celle
ciao
BFS


importante questo per completezza:
http://vbaccelerator.com/home/The_Site/Usage_Policy/article.asp
ciao
BFS

....
Per la gestione Eventi chiaramente l'uso delle Classi è molto comodo
come hai giustamente intuito, ma provo a suggerirti un'alternativa
BANALE... ma ci provo...
Se tu crei una Function interna alla maschera... scritta così:
Prvate Function EseguiControllo(NomeControllo as String)
    MsgBox "Evento da gestire sul controllo " & NomeControllo
    ' ovviamente lo recuperi così
    ' Me.Controls(NomeControllo)....
End Function
Nella maschera delle proprietà dei controlli alla TAB(Eventi)
sull'evento che ti interessa gestire, invece di scrivere o selezionare
"Procedura Evento" per scrivere del codice... scrivi questo:
=FunzioneControllo("NomeDelControllo")
Chiaramente ha molti limiti, come la gestione dei parametri rilasciati
dagli eventi e la possibilità di usare il CANCEL, ma pensaci
ugualmente potrebbe
semplificarti le cose...
Io rimango fedele alle Classi in quanto con queste mi trovo
decisamente più a mio agio.... ;-) e sentendoti sinceramnete mi sembra
tu abbia un'ottima
cultura tecnica, quindi credo che qualche esercizio chiarificatore
potrebbe benissimo completare i tuoi dubbi...
ciao
@Alex

 @Alex
Grazie
Ciao


No, non sono allergica agli ocx e effettivamente l'avevo già provato.
Il problema degli ocx è che non sai mai se saranno utilizzabili con
aggiornamenti futuri (Acces, Windows, Service Pack...)
Altro problema è che ormai ho creato il mo standard per i "dropdown":
il tastino per l'elenco a discesa non lo voglio, fisso è brutto su
tutte le colonne e farlo apparire quando si entra nella cella mi
toglie spazio nel campo, ho così imbastito un sitema con una listbox
al click dx del mouse.
Avevo fatto delle prove in merito con s_grid, ma avevo avuto dei
problemi utilizzando listbox di Access e griglia ocx.
Attualmente non ho VB a disposizione e quindi non potrei modificarmi
l'OCX.
D'altra parte se uassi correntemente VB non avrei utilizzato
Access :-)))
Ad ogni modo grazie.