Newsgroup: it.comp.appl.access
Titolo: come inserire delle opzioni/personalizzazioni nei programmi? (expert?)

regola n.1 riutilizzare il codice... :)
in virtù di questa regola vorrei che il programma che sto realizzando
avesse la possibilità di essere "personalizzato" dall'utente
per esempio l'utente potrebbe personalizzare il logo da stamare sui
report, oppure il colore delle textbox che hanno lo stato
attivo..oppure ancora decidere di stampare una o due copie dei
report...etc
voi come vi comportereste?
dovrei memorizzare tutte le informazioni che mi servono nel registry?
oppure in un file *.ini? oppure in una tabelle interna al db?
...prima che imbocco una strada senza uscita mi consigliate qualcosa?
cmq il principio generale è quello di leggere tutte le
"personalizzazioni" all'apertura del db e memorizzarle in variabili
globali? così da evitare continui accessi al registro? (o al file
*.ini)?
grazie.

 ha scritto nel messaggio
news:1194473238.9...@o3g2000hsb.googlegroups.com...




grazie.
Ci sono mille strade... ma in questo caso direi che la soluzione più giusta
è quella di usare il Database
che hai sotto mano....!
Creati delle Tabelle(una 10 100000) per il salvataggio delle
personalizzazioni... meglio di così...!
Crei una Form d'interfaccia per l'utente e fai in modo che all'avviamento
vengano salvate le personalizzazioni
in Variabili ambiente se è più opportuno, se si tratta dei LOGHI direi che
su OPEN del Report o della Form si carica
il File immagine.
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.alessandrobaraldi.it
---------------------------------------------------------------------------

 ha scritto nel messaggionews:1194473238.9...@o3g2000hsb.googlegroups.com...

grazie per la risposta, ma per "variabili d'ambiente" intendi dire
variabili globali pubbliche, giusto? in questo caso devo avere una
maschera che resterà sempre aperta dentro le quali far sopravvivere le
variabili?

 ...prima che imbocco una strada senza uscita mi consigliate qualcosa?
La soluzione che ti ha proposto Alessandro è molto buona, perché il
database nasce proprio per memorizzare dati, quindi anche quelle che tu hai
chiamato "opzioni".
Tuttavia, posso parlarti della mia esperienza personale.
Mi sono trovato a dover affrontare un problema di personalizzazione di un
Add-In che utilizzo (per il momento) solo per lo sviluppo di altre
applicazioni Access.
Avevo la necessità di permettere all'utente di personalizzare questo Add-In
in alcuni suoi aspetti.
La soluzione che mi è venuta più naturale è stata quella di memorizzare le
informazioni in una tabella.
Il problema che mi si è posto è questo: le tabelle presenti all'interno
dell'Add-In non sono raggiungibili quando mi trovo all'interno di un'altra
applicazione che utilizza questo Add-In.
Come soluzione immediata ho dovuto spostare queste tabelle all'interno
dell'applicazione da sviluppare, ma non ero contento della cosa perché
questo mi pregiudicava dal poter diffondere l'utilizzo di questo Add-In a
qualsiasi applicazione Access senza fare cambiamenti alla struttura del BE
dell'applicazione.
Il problema si è poi amplificato quando ho cercato di utilizzare l'Add-In
dall'interno di progetti di Access (ADP).
E' stato a questo punto che ho deciso cambiare completamente idea e di
salvare le impostazioni all'interno di un file XML: almeno per il momento,
non me ne pento affatto.
-- 
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype:pbsoftsolution

 skype:pbsoftsolution
Mi accodo, visto che per me e' un problema quotidiano,
ovvero la procedura non sa neanche dove collegarsi
se prima dell'avvio non vengono definiti dei parametri operativi
Le tabelle proprio non sono raggiungibili.
Attualmente, per ragioni storiche, uso dei file di configurazione (.ini)
che sono obsoleti, direi che la soluzione xml e' molto intelligente.
-- 
-- 
Lorenzo 

grazie a tutti per le risposte, l'idea di un file xml non è male anche
se forse per quello che mi serve mi basta una tabella..cm

grazie a tutti per le risposte!! l'idea di un file xml non è male,
anche se forse mi sarebbe sufficiente anche una tabella dentro il db.
sai dirmi dove posso trovare informazioni sulla scrittura e lettura
dei file xml da access? grazie.
ciao.

 ha scritto:

Il formato Xml e' plain-text quindi facilmente manipolabile in vba con le 
istruzioni native.
Chiaramente bisogna capire qual'e' la sintassi e la struttura.
Documentazione la trovi, questo il primo testo che ho trovato:
http://www.libreriauniversitaria.it/access-2003-programming-by-example/book/9781556222238
Pero' si trova molto nei NG:
http://www.google.com/search?hl=en&q=vb6+xml
-- 
Lorenzo 


Io ho utilizzato solamente ADO.
L'oggetto ADODB.Recordset ha il metodo Save, che, tra le varie opzioni, ne
ha una chiamata PersistFormat.
Questa opzione permette di salvare il recordset in formato XML.
E' anche vero che puoi manipolare il file "a mano", ma, in tal caso, posso
solo augurarti buona fortuna :-)
-- 


 solo augurarti buona fortuna :-)
bellissima idea.. :) ma per leggerlo come fai?
-- 
ignazioc

> bellissima idea.. :) ma per leggerlo come fai?
Continuo a seguire il modello ad oggetti di ADO:
rst.Open percorsocompletofile.xml, , , , adCmdFile
Poi, nel Form_Open, associo quel recordset alla form che deve visualizzare
le opzioni:
Set Me.Recordset = rst


 Set Me.Recordset = rst
mi hai dato due bellissime notizie :D
- non sapevo che si potesse salvare un recordset
- non sapevo si potessa associare una form ad un recordset..
:D :D :D
-- 
ignazioc

 ha scritto nel messaggio 
news:mn.5abd7d7b5...@gmail.it...

Mi permetto solo di aggiungere/condividere ciò che ha già detto Baraldi...
se scrivi all'interno del tuo DB non avrai nessun tipo di problemi di 
compatibilità e rimane tutto dentro il DB...
che sia mdb o mde per molte opzioni non avrai problemi...
all'apertura del db sai bene che si può far leggere praticamente tutto 
...S.O, DLL installate, configurazioni, ecc.
Una volta scritta correttamente la struttura ti rimarrà sempre magari dovrai 
in alcuni caso solo apportare qualche modifica ma poi non di certo 
riscriverla tutta...
Ciao
-- 
Roberto da Parma

 che sia mdb o mde per molte opzioni non avrai problemi...
Sono quasi completamente d'accordo.
Vorrei aggiungere alle tue correttissime note il fatto che, se stai
utilizzando un file di Access come Add-In (ed il mio caso è proprio
questo), le tabelle in esso contenute non sono visibili dal database che
sta utilizzando l'add-in.
Ecco perché ho dovuto fare ricorso ad un file XML.


"Gabriele Bertolucci" <"info[at]pbsoft[dot]it"> ha scritto nel messaggio 
news:12hlygi62o26c.ns2tt2ucpmk1$.dlg@40tude.net...

Verissimo...eh a quel punto sono scelte...
