Realizzare controllo griglia in Access
Michela DiGiacomo
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...
@Alex
wrote:
> 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...
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
Michela DiGiacomo
> 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..,
Diciamo che non sono una fan di Excel, anche se poi per fare 4 somme,
stampare una tabellina o un grafico lo uso. Ma se fosse solo per me,
Excel sarebbe ormai un software dimenticato :-)))
A parte questo, vorrei evitare di obbligare l'installazione di Excel
oltre che di Access dove viene usata la mia applicazione - anche se è
difficile da me trovare un pc che di default non abbia Excel.
Magari, per curiosità, qualche prova la faccio.
> 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...
>
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'...
BFS
>
> 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.
>
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
BFS
importante questo per completezza:
http://vbaccelerator.com/home/The_Site/Usage_Policy/article.asp
ciao
BFS
@Alex
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
Michela DiGiacomo
> ....
>
> 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...
Questa possibilità non l'avevo considerata, però come osservi tu ha
dei limiti e non sempre è utilizzabile.
E poi dovrei entrare in più di 700 controlli a modificare - forse si
può fare col solito For - Next da una Sub di "servizio".
> 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...
Mah, volevo approfittare di questa occasione proprio per
familiarizzare con le classi.
Ovviamente il gioco deve valere la candela e il tempo a disposizione è
quello che è...
>
> ciao
> @Alex
Grazie
Ciao
Michela DiGiacomo
> Il 10/11/2010 18:33, Michela DiGiacomo ha scritto:
>
>
>
> > soddisfacesse, anche perch la mia applicazione non commerciale e di
> > controlli grid a pagamento non se ne parla.
>
> Se non sei allergico agli ocx, io uso spesso questa:
>
>
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.