Newsgroup: it.comp.appl.access
Titolo: Aggiornamento Riferimenti

Ciao a tutti!
Sto lavorando con il mitico Access 2003. Per fare una buona
compattazione del BE - FE ho migrato tutti gli oggetti su due database
nuovi di zecca. Tutto ok, tranne per i riferimenti. Uno infatti non lo
trovo nella libreria: Microsoft Calendar Control 11.0. Evidentemente è
il retaggio di un Database versione 2000.. Mi sapete dire a quale
riferimento corrisponde in Access 2003? Oppure qual'è l'indirizzo in
cui lo posso trovare? Grazie mille !! ; )

Mettiamo che quel riferimento sia indispensabile per un determinato
codice. Se lo tolgo e faccio il Debug, Access dovrebbe dirmi che manca
un riferimento, giusto? Quindi se il Debug passa liscio ANCHE senza
quel riferimento significa che per QUEL database il riferimento non
serviva? Quindi vuol dire che ho inserito quel riferimento chissà
quando e perchè, e per distrazione è rimasto lì? Voi concordate?
In parole povere c'è un sistema per capire (senza testare di nuovo
tutto il programma) se un riferimento serve oppure no?
Come al solito GRRRAAAZIEEEEEEEEEEE!!!!

?"Francesco Salvagnini"  ha scritto nel messaggio 
news:38672914-b5b7-4984...@j11g2000yqh.googlegroups.com...
Mettiamo che quel riferimento sia indispensabile per un determinato
codice. Se lo tolgo e faccio il Debug, Access dovrebbe dirmi che manca
un riferimento, giusto? Quindi se il Debug passa liscio ANCHE senza
quel riferimento significa che per QUEL database il riferimento non
serviva? Quindi vuol dire che ho inserito quel riferimento chiss�
quando e perch�, e per distrazione � rimasto l�? Voi concordate?
In parole povere c'� un sistema per capire (senza testare di nuovo
tutto il programma) se un riferimento serve oppure no?
Come al solito GRRRAAAZIEEEEEEEEEEE!!!!
__
sul sito di @Alex trovi una routine che testa se i riferimenti sono corretti
sezione moduli
MA

 MA
Io ho girato spesso il sito di alex , pero devo dire che quella
funzione non ho capito come farla funzionare grrrr


Scusate l'ignoranza... dove lo trovo il sito di @Alex?
Nei post e nel suo profilo non lo vedo.. :(

Forse ho trovato.
Si tratta di una funzione denominata ListeReferences giusto?
Però non mi sembra che queste references siano le stesse che si
trovano nei Riferimenti dei moduli di Access..
Guardo meglio sto pomeriggio. Intanto buon pranzo a tutti!


wrote:

Si la funzione è quella e si i riferimenti sono gli stessi...
altrimenti mi preoccupo...!
@Alex


Whow, l'Autore in persona!
Ambiente: Access 2003
Oggetto: Riferimento Microsoft Calendar Control 11.0
Se in un database tolgo un Riferimento necessario, facendo il Debug,
Access dovrebbe darmi un errore di compilazione, giusto? (es: Tipo
definito dall'utente non definito). Se tolgo il riferimento sopra
citato, invece,
1) il programma viene compilato correttamente,
2) Non lo ritrovo più nella lista dei Riferimenti.
Come mai?
Ho eseguito la funzione ListeReferences anche se non ho capito bene
cosa faccia: non essendo un informatico posso solo tentare di
interpretare:
1) il programma legge i Riferimenti dell'applicazione in corso (cioè
se è Acces 2003 legge la versione 2003, se è Access 2000, la versione
2000 e così via)
2) a seconda che questi oggetti puntino o no a un riferimento valido
nel Registro di sistema, la funzione scrive 3 attributi (nome,
libreria, path) o uno soltanto (libreria).(Ma il comando Debug.Print,
dove va a scrivere?)
I Riferimenti visualizzati la mascherina dei moduli sono circa 460.
Eseguendo passo passo il programma e leggendo il valore della
variabile accRef, non vedo che i nomi siano coincidenti. Esempio: il
primo valore che trova assume
Name= VBA
Guid=000204EF-0000-0000-C000-0000000000046
FullPath=C:\Programmi\File comuni\Microsoft Shared\VBA\VBA6\VBE6.DLL
Ma nei Riferimenti non ho trovato questi nomi.. cosa mi consigli, a
parte studiare?
Nel senso, sto riferimento serve oppure no?

 Nel senso, sto riferimento serve oppure no?
Il riferimento serve... se manca avrai un'errore... il
NomeDescrittivo... non serve a nulla.
@Alex


Ma.. come mai se tolgo il flag di spunta e chiudo la maschera dei
Riferimenti
Microsoft Calendar Control scompare? Gli altri mica scompaiono.. Può
essere che fosse un Riferimento rimasto lì da chissà quale versione,
che mi sono tirato dietro?

 - Mostra testo citato -
Allora vediamo, anzi guarda cosa m'è uscito dall finestra immediata:
VBA      {000204EF-0000-0000-C000-000000000046}C:\Programmi\File comuni
\Microsoft Shared\VBA\VBA6\VBE6.DLL
Access    {4AFFC9A0-5F99-101B-AF4E-00AA003F0F07}        C:\Programmi
\Microsoft Office\OFFICE11\MSACC.OLB
DAO      {00025E01-0000-0000-C000-000000000046}         C:\Programmi
\File comuni\Microsoft Shared\DAO\dao360.dll
stdole     {00020430-0000-0000-C000-000000000046}        C:\WINDOWS
\system32\STDOLE2.TLB
ADODB    {00000201-0000-0010-8000-00AA006D2EA4}        C:\Programmi
\File comuni\System\ado\msado21.tlb
MSACAL    {8E27C92E-1264-101C-8A2F-040224009C02}        C:
\PROGRA~1\MICROS~2\OFFICE11\MSCAL.OCX
VBIDE     {0002E157-0000-0000-C000-000000000046}        C:\Programmi
\File comuni\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB
IWshRuntimeLibrary     {F935DC20-1CF0-11D0-ADB9-00C04FD58A0B}        C:
\WINDOWS\System32\wshom.ocx
JRO      {AC3B8B4C-B6CA-11D1-9F31-00C04FC29D52}C:\Programmi\File comuni
\System\ado\msjro.dll
Penso che il Riferimento sia MSACAL. Questo output significa che
questi riferimenti sono necessari, o che queste sono le librerie a cui
gli oggetti scelti (e forse non necessari) fanno riferimento? Nel
senso: se MSACAL non fosse necessario uscirebbe solo il Name? E poi,
perchè MSCAL è l'unico a non avere un indirizzo preciso? (C:
\PROGRA~1\MICROS~2 ..)
Scusa la rottura, ma per me questo è un altro mondo.. Sono fermo a if
then else, quasi.. ; )

 - Mostra testo citato -
Grazie @lex, sono riuscito a recuperare il riferimento attraverso il
pulsante sfoglia della maschera riferimenti e l'indirizzo fornitomi
dalla finestra immediata. Anche se non ho ancora capito se serve e
come mai sparisce se lo tolgo..

 come mai sparisce se lo tolgo..
Se tu inserisci tutti i riferimenti per assurdo... non otterrai alcun
errore... ma di certo non servono tutti...!
Io meno riferimenti ho più sono contento..., motivo per il quale
preferisco usare LATEBINDING(senza riferimenti preventivi) e non
EARLYBINDING(con i riferimenti preventivi).
Per l'anmalia che segnali non saprei... ripeto che a mio avviso è
dovuta al fatto che è un OCX e di fatto non viene visto se non
nell'istanza grafica della Classe form.
@Alex


Cavoli, hai aperto un'altra finestra..! Ora dovrò andarmi a studiare
anche questi late & early, magari nel tuo sito.
Grazie, alla prossima!

 - Mostra testo citato
Eccoci già alla prossima.
Premesso che i primi due Riferimenti, Visual Basic for Application e
Microsoft Access 11.0 Object Library, Access non me li lascia togliere
(per quelli come si fa a passare al metodo late?)
Prendiamo l'esempio del Riferimento Windows Script Host Object Model,
che se lo tolgo e faccio il debug Access si pianta perchè non
riconosce il codice seguente:
Dim wsh As WshShell
Set wsh = New WshShell
wsh.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Office\11.0\Access
\Security\Level", 1, "REG_DWORD"  ' ( default 2 )
wsh.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\4.0\Engines
\SandboxMode", 2, "REG_DWORD"  ' ( default 2, ma è meglio rimetterlo )
Set wsh = Nothing '
Come fare per passare al LATEBINDING ?
E poi, a te che usi Access 2010, volevo chiedere se anche in quella
versione, alla PRIMA apertura, escono i soliti messaggi
terroristici... ; )

 terroristici... ; )
Un pò di teoria....
LATEBINDING Vs EARLYBINDING
    Ci sono 2 modi per sfruttare OLE Automation al fine di controllare
applicazioni esterne(che ovviamente espongono un'interfaccia OLE)
    1) LATE BINDING (Associazione Tardiva) che sfruttando il metodo
CreateObject(per istanziare un oggetto nuovo)
    o GetObject(per usare l'istanza di un'oggetto già aperto).
    Questo metodo non fa esplicito riferimento ad una Libreria, ma
lascia l'autonomia al
    sistema di istanziare il riferimento più recente di quel SERVER di
Automazione.
    NON SERVONO RIFERIMENTI A LIBRERIE ESTERNE.
    Esempio di codice in modalità LATEBINDING per istanziare
un'oggetto EXCEL:
    Codice:
            Dim xlApp As Object
            Set xlApp = CreateObject("Excel.Application")
            xlApp.Workbooks.Open "c:\NomeFile.xls"
    Oppure apriamo l'istanza di Excel già in esecuzione:
    Codice:
            Dim xlApp As Object
            Set xlApp = GetObject("c:\NomeFile.xls")
    La variabile Oggetto [xlApp] ora contiene un'istanza di Excel
nuova o preesistente.
    Chiaramente se si cerca di usare il GetObject e non esiste nessuna
istanza del Server di Automazione(EXCEL in questo caso) verrà
    restituito un'errore Err=429, gestendo il quale si prevengono
inceppamenti, in quanto si tenta di usare GETOBJECT, si intercetta
l'errore 429 ed in tal caso si
    ricorre al CREATEOBJECT.
    VANTAGGI:
    Non richiedendo riferimenti fissi, su qualsiasi macchina venga
eseguito il codice, anche se presenti VERSIONI di SERVER OLE diverse.
    Il LATEBINDING è definito VERSION INDIPENDENT.
    Notevole miglioria soprattutto per distribuzioni MDE che non
richiederà lo scroll della collection REFERENCES con il Check della
propery
    ISBROKEN o BROKENREFERENCE membro di Application per poi caricarle
RUNTIME, ma questo richiede la selezione del File SERVER OLE, quindi
altro Codice.
    SVANTAGGI:
    Gli oggetti dichiarati in LATEBINDING non consentono di esporre
gli EVENTI, quindi se si devono intercettare EVENTI dell'oggetto EXCEL
da Access
    è impossibile con questa tecnica.
    Gli oggetti dichiarati in LATEBINDING non consentono l'elenco di
Metodi/Proprietà come in VBEditor è normale vedere con l'uso
dell'Intellisense.
    Gli oggetti dichiarati in LATEBINDING non consentono di usare le
costanti appartenenti a quella Application in quanto non inseriti.
    Gli oggetti dichiarati in LATEBINDING non consentono l'accesso
all'HELP specifico della Libreria.
    2) EARLY BINDING (Associazione Preventiva)
    Questo metodo invece richiede l'esplicito riferimento al SERVER di
AUTOMAZIONE, che dovrà essere inserito nelle LIBRERIE di riferimento
del progetto.
    Esempio di codice in modalità EARLYBINDING per istanziare
un'oggetto EXCEL:
    Codice:
            Dim xlApp As New Excel.Application
            Set xlApp = New Excel.Application
            xlApp.Workbooks.Open "c:\NomeFile.xls"
    VANTAGGI:
    E' leggermente più veloce l'istanza dell'oggetto in quanto non
serve la ricerca del SERVER OLE, che è già definito
    Possiamo ereditare EVENTI.
    Possiamo accedere all'uso delle Costanti.
    Possiamo avere, tramite Intellisense da VBeditor, l'elenco di
Metodi/Proprietà/Eventi.
    Possiamo accedere all'HELP della libreria.
    SVANTAGGI:
    Il più grosso svantaggio, che però pesa a tal punto da rendere
sconveniente questo metodo nonostante i numerosi vantaggi, è il
    fatto che proprio per essere VERSION DIPENDENT, è come avere le
mani legate, quindi le librerie del PC di sviluppo dovranno
    essere le stesse di quelle del PC di destinazione, cosa non sempre
possibile.
    In conclusinoe, se non si devono ereditare eventi, il suggerimento
è di far riferimento SEMPRE alla tecncia LATEBINDING, ma, in fase di
sviluppo
    è stupido rinunciare ai VANTAGGI di EARLYBINDING, quindi il mio
consiglio è di sviluppare inserendo i RIFERIMENTI, e prima di
distribuire
    toglierli, inserendo la parte di codice per l'istanza in
LATEBINDING sostituendo l'assegnazione delle Variabili da esplicito ad
Object.
@Alex


Mi sento onorato di aver suscitato una risposta così enciclopedica! Di
fronte alla quale però, la mia ignoranza risulta abissale.. Beh,
studieremo.
E.. per quanto riguarda gli avvisi di sicurezza, cosa dici? In Access
2010 è lo stesso?

 2010 è lo stesso?
Io come per A2007 ho elimninato la protezione per le Macro... e non ho
alcun avviso..!
@Alex


Mi son spiegato male: il problema non è mio, ma dei clienti a cui
distribuisco il programma in Run-time.
Con Access 2003 ho cercato di aggirare il problema andando a
modificare, in fase di apertura del programma, le due chiavi di
registro Level e SandboxMode (vedi codice sopra); però Access mi frega
perchè controlla le chiavi PRIMA che parta la macro Autoexec che
esegue il codice suddetto.. quindi gli avvisi di protezione, almeno
una volta, vengono lanciati lo stesso. Ovvio che se uno che di
computer non sa NULLA (è il caso della tipologia di persone a cui mi
rivolgo) risponde Blocca e Non Aprire. Ho provato anche a modificare
queste due chiavi in fase di Setup, ma il risultato non cambia. Mi
chiedevo quindi se Access 2010 era diventato più clemente nei riguardi
di noi (POVERI) programmatori....