Newsgroup: it.comp.appl.access
Titolo: (semi OT) Non e' che vi ricordate come si fa a chiamare esplora risorse col vba ...

e soprattutto forzarlo a puntare su una certa directory, no ? 
Si faceva con lo shell piu' o meno ma non ... ricordo piu' bene.
 
Grazie 

 Si faceva con lo shell piu' o meno ma non ... ricordo piu' bene.
 
Ciao radica...,
intendi questo?
 
Dim sh As Shell32.Shell
 
    Set sh = CreateObject(Class:="Shell.Application")
    sh.Open "D:\Percorso"
 
    Set sh = Nothing
 
-- 
Ciao!
Maurizio


Argh ! Eccolo ! Sei un grosso ;-) 
 
pero' bisogna fare 
dim sh as object 
perche' non mi ritrovo la libreria. 
 
Grazie !  


Si', meglio Object. Comunque la Library è:
 
Library Shell32
    C:\Windows\SysWOW64\shell32.dll
    Microsoft Shell Controls And Automation
 
Grazie del riscontro.
 
-- 
Ciao!
Maurizio


No, per correttezza devo dire che e' (molto) meglio come 
dici tu perche' il late binding (me lo insegni) e' molto
piu'  lento dell' early binding. 
 
E inoltre con l' early binding  hai  l'  intellisense  a 
disposizione, cosa che non accade con il late.
 
Solo che non sapevo come si chiamava la libreria ... :-) 
 
Grazie ancora

 Solo che non sapevo come si chiamava la libreria ... :-) 
 
Ciao radica...,
 
La questione della lentezza spesso può essere trascurabile se si considerano i vantaggi del late binding riguardo conflitti di versioni su pc con s.o. diverso ecc.
 
Tuttavia la pratica più comune è sviluppare con i riferimenti alla libreria, per avere, come giustamente dici, anche l'intellisense a disposizione, poi rilasciare l'applicazione senza tali riferimenti. Spesso si usa anche una costante di compilazione condizionale per lo sviluppo con e senza riferimenti.
 
Per esempio cosi':
 
Quando si sviluppa:
Argomenti di compilazione condizionale: DevMode = 1
(E tutti i riferimenti necessari)
 
Quando si compila per il rilascio:
Argomenti di compilazione condizionale: DevMode = 0
(Si tolgono i riferimenti non necessari)
 
Nel codice, per esempio:
 
#If DevMode Then
  Dim sh As Shell32.Shell
#Else
  Dim sh As Object
#End If
 
-- 
Ciao!
Maurizio


 
 
di quanti millesimi di secondo stiamo parlando?
 
ciao

 di quanti millesimi di secondo stiamo parlando?
 
Ciao BFS.
 
Ehm... Non sono parole mie quelle. ;-)
 
-- 
Ciao!
Maurizio

 #End If
 
Capisco. Ti ringrazio.

Il giorno venerdì 20 marzo 2015 17:06:53 UTC+1, BFS ha scritto:

Di pochi, ma : 
 
e' una questione di principio, o forse, meglio, di stile di 
programmazione. 
 
In generale, io  personalmente  preferisco applicare sempre 
il metodo piu'  veloce  (qualunque sia il problema che tale 
metodo deve risolvere). 
 
Poi ... pochi millesimi di qua, pochi millesimi di la e ti 
ritrovi una applicazione LENTA, perche' come diceva Toto' : 
e' la somma che fa il totale ;-) 
 
Ciao
 


Ciao radica...,
ripassa di qui quando un tuo applicativo non girerà perché i riferimenti che sono validi per il tuo pc non lo sono per il pc dell'utente e dovrai essere tu veloce a mettere le cose a posto. ;-)
 
-- 
Ciao!
Maurizio


Si, capisco, ma io facevo un discorso di natura generale. Poi
pero' certamente possono capitare casi in cui conviene cedere 
alla lentezza per acquisire in portabilita', come questo. 
 
Sai ... poi dipende  pure dal  contesto : se non sai a priori 
su che  macchine  girera'  la tua  applicazione chiaramente e' 
tutto diverso. 
 
Ma  sinceramente  in  una situazione  siffatta non sara' certo 
il "late binding" a salvarti il culo : sai meglio di me che se
vai a  sviluppare per "non si sa chi"  le ragioni per le quali 
l' applicazione potrebbe fallire sono cosi'  tante e disparate
che ... ajajajajaja :-) 
 
 


Ciao radica...,
conosco uno che diceva "un piccolo rischio di qua, un piccolo rischio di la e ti ritrovi una applicazione ferma, perche' come diceva Toto': 
e' la somma che fa il letale".
 
;-)
-- 
Ciao!
Maurizio


Eh ! Addirittura "letale" ! E che sara' mai ... ;-) 
 
 

 Eh ! Addirittura "letale" ! E che sara' mai ... ;-)
 
Confermo, letale. Forse non per la salute, se sei un flemmatico, ma per il portafoglio sicuramente, se lo fai per professione.
</OT>
-- 
Ciao!
Maurizio


Ma mica dico che hai torto
 
Pero' ti  dissi anche : se DAVVERO fai programmi per macchine che 
non conosci a priori  posso  anch' io confermarti tranquillamente 
che  ci vuole  ben  altro  per  pararti completamente il sederino 
:-)  
 
Dai su ... 
 
In  *quel* caso, ossia se la tua applicazione puo' andare a  girare
chissa' dove,  praticamente cosi' a spanne, forse esagerando un po',
direi che  il 5%  del tempo di lavoro lo devi sacrificare a tutta una 
serie di controlli  molti  di  questi facendo abbondante ricorso a 
funzioni API. 
 
E' anche vero che pero', una volta "isolati" e "impacchettati" tutti
questi controlli poi ci metti ben poco ad esportarli alle applicazioni
successive. Quello si. 
 
 
 
 
 
 

Il giorno martedì 24 marzo 2015 14:25:31 UTC+1, 
radica...@gmail.com
 ha scritto:
[...]
 
Hai ragione.
-- 
Ciao! :-)
Maurizio

 Hai ragione.
 
E (esperienza diretta) c'e' comunque il rischio (ok : basso. Ma c'e') che
gli mandi affanculo il sistema, se proprio ti dice male male ma male come
si deve. E  allora sono cazzi amari perche' potrebbe perdere tutto, anche
roba SUA. 
 
Ecco perche' ad esempio quando  posso  preferisco costruire  applicazioni
che girano DENTRO l' access o  dentro l' Excel  o dentro il  word ecc ecc 
e non eseguibili stand alone.  In quel modo perlomeno  so  che  se  ad es. 
l' Access gli gira  bene  le  probabilita'  di  un evento  devastante  si 
riducono di molto. 
 
... ma non si azzerano :-(