Newsgroup: it.comp.appl.access
Titolo: Package setup wizard di ADE, Run-time  e riferimenti

Dovo aver creato una piccola applicazione con A03 ho deciso di creare un 
pacchetto di installazione con Access Developer Extension (ADE) per far 
girare l'applicazione su un Pc che non ha Access installato.
Il problema è che una volta installato il pacchetto su tale macchina 
l'applicativo si blocca subito perchè non riconosce delle elementari 
funzioni di VBA (per esempio Lef$(...)). Da quanto ho capito non è 
sufficiente installare il run time; sembra che il problema sia la mancanza 
delle librerie e cosi pure i componenti per utilizzare oggetti come il 
controllo Calendario o l'oggetto  Filedialog (insomma tutte le librerie 
selezionate nel menù Riferimenti). Il pacchetto gira benissimo sulla 
macchina dove è stato prodotto ed è installato Access. In una vecchia 
versione di ADE per A97 c'era la possibilità di aggiungere facilmente i 
componenti necessari ed il wizard provvedeva a creare le opportune chiavi di 
registro. Ora come posso fare? C'e un modo semplice per risolvere il 
problema senza essere costretto ad installare Access sulla macchian dove 
dovrebbe girare il pacchetto? Non vorrei rischiare operazioni manuali che, 
se errate,  potrebbero corrompere irrimediabilmente il registro di WinXP.
Grazie per i suggerimenti

 ha scritto nel messaggio 
news:43ad4315$0$1072$4faf...@reader4.news.tin.it...

 Dimentica le operazioni manuali sul registro...da evitare se non lo si 
conosce a fondo.
La creazione guidata pacchetti ti permette di aggiungere altri file 
all'installazione.
Questi altri file debbono essere scelti tra quelli di cui disponi la licenza 
di distribuzione.
La prima cosa da fare e controllare i riferimenti e prendere nota di tutti i 
file non standard. Per esempio ocx o dll non standard. Se il tuo applicativo 
ha un riferimento alla libreria di Office11 è evidente che anche il cliente 
deve avere Office11 altrimenti non hai le autorizzazioni per distribuire 
tale libreria. Il controllo calendario puoi liberamente distribuirlo perchè 
hai la versione developer di Access (Office), così come cmdlg32.ocx o 
comctl32.ocx o altri inclusi nella licenza del developer. Normalmente il 
pacchetto di installazione provvede automaticamente a inserire questi 
controlli ma qualora non lo facesse puoi aggiungerli manualmente usando 
"Aggiungi file" durante il wizard.
Spero di esserti stato di aiuto.
Ciao e Buon Natale
Carlo 

 ha scritto nel messaggio 
news:43ad8073$0$1051$4faf...@reader2.news.tin.it...

Ti ringrazio della risposta ma rimango perplesso.
Divido in due il problema: licenze e funzionamento:
Per quanto riqgurda le licenze io dovrei includere una liberia di office 11 
in quanto ho usato il controllo file dialog che credo faccia parte della 
libreria di Office 11. Visto quello che fa il suddetto controllo (serve per 
salvare un file con un nome a scelta) mi sembra strano che il cliente debba 
avere una licenza di Office solo per questo. Ma può essere, anche se mi 
sembra assurdo e vessatorio. Sei sicuro di questo? Se è così, a questo punto 
è inutile utilizzare il run time e creare un disco di installazione se poi 
devo far acquistare una licenza solo per usare un file di pochi kb! Come 
faccio inoltre a capire quali della lunga lista di riferimenti presenti 
posso distribuire o meno? Alcuni mi informano, quando tento di utilizzarli 
che non posso farlo perchè non ho la licenza; e va bene. Ma gli altri? La 
lista è lunga ...
Al di la del problema della licenza che cercherò di indagare meglio e su cui 
sono gradite comunque ulteriori osservazioni, non credo che il mancato 
funzionamento dipenda dalla licenza a meno che non si intenda che per far 
funzionare l'applicazione dovo installare completamente Access (anche le 
parti che non servono!).
Quanto al funzionamento, come faccio a capire quali sono i controlli 
standard e quelli non standard. Io ho provato ad aggiungere tutti i files 
dei riferimenti utilizzati ma su  un PC di prova senza Access la macro 
iniziale di autoexec si blocca subito alla chiamata di una prima funzione, 
che tra l'altro non sfrutta neanche componenti particolari ma solo 
istruzioni VBA che controllano la presenza del backend.
Ricambio gli auguri di Buon Natale
Ciao

 Ricambio gli auguri di Buon Natale
Tutte le componenti incluse nel file .zip della versione DEV sono sotto
licenza  (vale a dire praticamente tutto quello che serve).
Ma non capisco bene se tu ti riferisci a controlli OCX: spiegati meglio.
Auguri natalizi   :-)

 ha scritto nel messaggio 
news:43ad9a52$0$1082$4faf...@reader4.news.tin.it...

Il FileDialog puoi benissimo sostituirlo con il common dialog ocx 
(comdlg32.ocx) di cui hai la licenza di distribuzione.
Il fatto che il codice si blocca su semplici funzioni come Left non vuol 
dire che l'errore è da riferirsi alla libreria di VBA ma piuttosto ad un 
riferimento mancante, uno qualsiasi.
Controlla bene tutti i riferimenti e vedrai che tutto funziona. Tieni 
presente che in tutti i linguaggi di programmazione, quando distribuisci un 
applicativo con dll o ocx "esterni" o di terze parti, devi avere la licenza 
per farlo...non è un problema di Access.
Nella creazione del pacchetto di installazione puoi scegliere dove mettere 
le dll o ocx: nella cartella di lavoro, in cartelle condivise o cartelle di 
sistema. Inoltre spesso gli ocx "terzi" per funzionare hanno bisogno del 
runtime di VB6 o VB5. Questi li puoi trovare e liberamente installare sul 
sito Microsoft oppure qui:
Runtime vb5: 
www.frantoiogestione.com/vbrun50.exe
Runtime vb6: 
www.frantoiogestione.com/vbrun60sp5.exe
Prova e fammi sapere.
Ciao, Carlo 

 del runtime di VB6 o VB5.
Le DLL /OCX incluse sono le seguenti:
VBA:    VBE6.DLL
Access: MSACC.OLB
stdole: stdole2.tlb
VBIDE:  VBE6EXT.OLB
DAO:    dao360.dll
ADODB: msado21.tlb
MSACAL: MSCAL.OCX
Office: MSO.DLL
A parte il fatto che può darsi che qualcuna di queste sia pure inutile in 
quanto rimasuglio di parti di programma abbandonate o tentativi abortiti di 
soluzione di un problema , dal punto di vista delle licenze a me sembrano 
tutte appartenenti a Access/Office e non dovrebbero quindi avere bisogno del 
runtime di VB6. Se comunque con questi componenti la macchina deve avere 
Aceess  o, peggio, Office installato(dal punto di vista delle licenze), 
allora mi arrendo e rinuncio a creare il pacchetto di installazione che a 
questo punto è inutile. Però vorrei capire il perchè (o meglio dove ho 
sbagliato) nell'avere un differente comportamento fra runtime e versione 
completa (problema Filedialog a parte).
Saluti e grazie
PS Se ritardo a rispondere è solo perchè sto tentando di mettere in pratica 
i vostri suggerimenti ( a volte devo pure andare a leggere qualche pagina di 
diversi libri per poter mettere in pratica i vostri consigli in taluni casi 
un po' complessi per le mie attuali conoscenze, vedi API per esempio) oppure 
sto cercando di disintossicarmi la mente (operazione non facile quando un 
testardo come io sono sta impazzendo su un problema) andando a sciare. 
Comunque grazie ancora per la collaborazione. 

 pronto che risponde al problema specifico.
Se usate male (e se molto particolari), ma qui Alfredo parlava di due
autentici "must"   ;-)
www.sitocomune.com
Sezione General:
 6.5     Richiamare la finestra di dialogo per la selezione di una
directory.
6.22    Richiamare la finestra di dialogo per la selezione di un file.



Beh, è scontato che se per far funzionare un'applicazione è necessario
installare Access, il Runtime non servirebbe!   :-)
Dall'elenco sopra, comincia a eliminare stdole2.tlb e vbe6ext.olb (è molto
improbabile che tu le usi).
Al posto tuo rinuncerei al controllo calendario OCX  MSCAL.OCX (sul sito
comune o quello di Baraldi trovi degli splendidi calendari VBA, che puoi
pure personalizzare).
Perchè hai inserito la libreria di oggetti DAO360 in un file ADP/E  (i files
di progetto lavorano con ADO non con DAO)?
Rinunciando all'oggetto FileDialog dovresti poter eliminare dai riferimenti
anche MSO.DLL  (usi forse codice per manipolare a Runtime le commandbars?)
Ciao, Oscar

 ha scritto nel messaggio 
news:43b2510a$0$1076$4faf...@reader3.news.tin.it...


 č lungo e non documentato (o comunque non a sufficienza) ufficialmente.
Mhmmm, attenzione: a parte il problema relativo all'evento "su caricamento"
che hai esposto (problema strano e da verificare) i guai legati ai "Lost
references" non riguardano specificamente la versione DEV, ma Access in
generale.
Chiaramente in fase di sviluppo č difficile rendersene conto, per cui i
problemi emergono solo nell'atto della distribuzione
Ciao, Oscar

 semplificando il codice della tua applicazione_
Mi riesce difficile riprodurre il problema al momento in quanto la maschera 
"Inizio"  di cui ho accennato contiene è piuttosto complessa. Contiene 
infatti un controllo a schede con tre pagine:
- la prima non ha nulla di speciale: contine solo pulsanti per aprire altre 
maschere e non credo dia problemi.
- la terza contiene dei controlli testo il cui valore è dato da funzioni di 
Lookup su tabelle  collegate presenti nel backend MDB.Potrebbe forse la 
funzione cercare valori prima che il backend sia collegato in modo completo? 
Mi sembra difficile in quanto il collegamento al back end è fatto prima di 
caricare la maschera "Inizio".
- la seconda, denominata "Stampe" è assai più complessa in quanto contiene 
un controllo casella combinata che ha come origine una tabella presente nel 
FE dove ci sono i nomi dei report dsponibili; a seconda del report che viene 
selezionato viene visualizzata una sottomaschera contenente pulsanti 
utilizati per determinare intervalli fra date (tipo quale semestre oppure 
quadrimestre oppure  trimestre) e contiene codice e  fa riferimento a 
funzioni che calcolano la data di inizio e di fine del periodo che si vuole 
selezioanre (ad esempio il secondo trimestre dell'esercizio passato) e/o 
diverse caselle di riepilogo a scelta multipla per stabilire vari modi di 
filtrare i record da mandare in stampa (es. uno o più clienti, o tutti).
La routine che dava problemi è proprio quella relativa all'evento After 
update della casella combinata di scelta del report ("SelezReport") che 
evidentemente visulizza la casella di riepilogo appropriata per il report 
scelto (per scegliere di volta in volta i Clenti, oppure le Commesse oppure 
oppure le banche) e, nel caso, anche la sottomaschera per permettere la 
scelta del periodo.
Questa routine viene richiamata all'inizio per assicurarsi che i controlli 
visualizzati sino coerenti con il report selezionato (cambiando l'ordine dei 
report nella tabella cambia  il primo record  e quindi il report che viene 
visualizzato al caricamento) : se viene eseguita all'evento su caricamento 
con la versione Full  tutto funziona mentre nel Runtime si pianta.
Spero di essere statoabbastanza chiaro, anche se non esaustivo. Sicuramente 
all'inizio questo problema era mescolato, o meglio, occultato dagli altri 
problemi relativi al Filedialog e ai "lost references". Tuttavia, se questi 
riferimenti si chiamano "persi" e non "mancanti" ci sarà pure un ragione ... 
non sempre addebitabile allo sviluppatore! :-); comunque per questo problema 
non credo abbiano rilevanza in quanto alla fine li ho eliminati praticamente 
tutti.
In sintesi la mia impressione è che nella versione run time l'ordine di 
esecuzione sembra essere diverso da quello della versione Full e pertanto 
vengono fatte chiamate a funzioni non ancora disponibili. Oppure due 
oprazioni svolte in parallelo terminano in tempi differenti a runtime (ad 
esempio A finisce prima di B nella versione Full mentre B finisce prima di A 
a runtime) con conseguenze deleterie a valle. Se ho detto una bestialità 
sorridete pure ma non crocefiggetemi, tanto ritengo di essere in buona 
compagnia in quanto i programmatori di Redmond le bestialità oltre a 
pensarle .... spesso le mettono anche in pratica :-)). Ricordo al proposito 
quanto sono impazzito per cercare di integrare Word ed Excel in 
un'applicazzione Access con l'automazione ole.
Se quanto ho aggiunto non è sufficiente dovrete pazientare un po'. Prima 
devo andare avanti per digerire le API che nonostante "il miele" di Oscar 
("Ma no, non sono complesse") mi rimangono un  po' indigeste. ;-)
Ciao
 

 un'applicazzione Access con l'automazione ole.
Non ti accuso di aver detto bestialità  :-)
Però sono come San Tommaso ... se vuoi puoi preparare una versione "Lite"
della maschera in oggetto e spedirla a
oscar.ma...@libero.it
Posso provare la cosa con la Dev di Access XP: non credo sia cambiato così
tanto dalla versione precedente alla tua.
Ciao, Oscar