Newsgroup: it.comp.appl.access
Titolo: programmazione ad oggetti e classi

Salve a tutti,
scusate l'ignoranza, ho sempre usato access/vba in modo procedurale,
domanda: è possibile usare access anche in modo orientato agli
oggetti?....ma quando si parla di classi, si parla dell'argomento
"programmazione ad oggetti"?
grazie

 ha scritto nel messaggio 
news:b07913bf-9eb9-47b8...@d45g2000hsc.googlegroups.com...
Salve a tutti,

[risposta]
VB (e, di conseguenza VBA) non è un vero limguaggio ad oggetti.
I linguaggi ad oggetti presentano tre caratteristiche precise: 
incapsulamento (l'oggetto è lunico proprietario dei suoi dati), polimorfismo 
(capacità di classi diverse di esporre interfacce simili o uguali) ed 
ereditarietà (capacità di derivare una nuova classe da una esistente, la 
nuova classe eredita proprietà e metodi della classe base).
In VB manca l'ereditarietà, almeno quella detta eredità d'implementazione. 
Ma questa può essere simulata.
Per come farlo:
"Programmare Visual Basic 6.0" - Francesco Balena - Microsoft Press
Ciao.
eSQueL 

 ha scritto nel messaggionews:b07913bf-9eb9-47b8...@d45g2000hsc.googlegroups.com...

Avrei molto da ridire sulla tua affermazione iniziale... ma mi sembra
tanto ripetuta e non nata da te....!
Incapsulamento: direi che il VB ed anche il VBA lo consentono, molto
limitato ma fattibile dipende se usi le interfacce.
Polimorfismo: Vedi le Interfacce supportate pienamente
Ereditarietà:limitato al 2° livello anche se espandibile in unione con
le Interfacce, a dire il vero un pò forzato...
Nel mio sito trovi esempi di utilizzo nel VBA della tecnica OOP che
rispetta tutti questi principi:
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=261
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=269
Questo è decisamente ottimo(dal tuo intervento)
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=271
Se serve all'OP può leggere anche qesto:
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=286
Saluti
@Alex


Avrei molto da ridire sulla tua affermazione iniziale... ma mi sembra
tanto ripetuta e non nata da te....!
Incapsulamento: direi che il VB ed anche il VBA lo consentono, molto
limitato ma fattibile dipende se usi le interfacce.
Polimorfismo: Vedi le Interfacce supportate pienamente
Ereditarietà:limitato al 2° livello anche se espandibile in unione con
le Interfacce, a dire il vero un pò forzato...
Nel mio sito trovi esempi di utilizzo nel VBA della tecnica OOP che
rispetta tutti questi principi:
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=261
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=269
Questo è decisamente ottimo(dal tuo intervento)
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=271
Se serve all'OP può leggere anche qesto:
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=286
Saluti
@Alex
________________
mm ... se scrivo che "è possibile utilizzare la proprietà DoCmd per accedere 
all'oggetto DoCmd in sola lettura e ai metodi a esso correlati" è una cosa 
ripetuta. Ma anche scrivo "quando il cielo si copre di nubi, probabilmente 
pioverà" è una cosa ripetuta. Tuttavia, mentre sono all'aperto e noto che le 
nubi si stanno addensando, quindi noto che inizia a piovere ... allora 
considero autonomamente che i due eventi sono correlati e che la presenza 
del primo facilmente determinerà il secondo.
Ho indicato piuttosto chiaramente la fonte del "sapere" esposto ma, come 
nell'esempio fatto, ciò non significa che non abbia potuto considerare 
autonomamente l'evidenza di quelle affermazioni. Oh, è certamente possibile 
che mi sia fatto influenzare dal grande Balena :)
In ogni caso, ti ringrazio per i link che hai voluto fornirmi.
Ciao :))
eSQueL 

 le Interfacce, a dire il vero un pò forzato...
Ma vale anche per A97? Sul tuo sito gli esempi sono riferiti a
versioni successive (escluso /DettaglioFaq.asp?IdFAQ=286).
Nelle diverse versioni di VBA sono state introdotte funzioni e/o
metodi per la programmazione OOP, o soltanto funzioni tipo split,
join, etc.?
ciao,
Panathos

 eSQueL
Balena è un Famoso... ma le letture dei libri vanno sempre prese in
modo critico.
Nel libro di Balena non viene fatto alcun riferimento all'uso delle
Interfacce per l'implementazione di
Ereditarietà allargata... ecc...!
Questo non significa che quello che dice sia sbagliato... sicuramente
nel contesto in cui lo hai letto
è corretto...!
Il problema è che come lo hai riportato tu sembrava una verità
assoluta sulla quale ti ho invitato a riflettere.
Se tu avessi i concetti di cui hai parlato non avresti risposto come
hai fatto ma avresti capito quello che ti
ho detto dandomi ragione... per questo non è bello recitare quello che
dicono altri se non lo si conosce.
@Alex

 Panathos
A97 non supporta molte cose del VBA delle versioni dal 2000 in avanti.
Non supporta le Interfacce ma le classi esistono anche se con qualche
limite ulteriore(non supporta ENUM ad esempio)
In ogni caso se si volesse parlare del sesso degli angeli eSQueL ha
anche detto una cosa giusta... ma va razionalizzata e credo che il
Limite OOP di Access e VB sia ben difficile da trovare realizzando
applicativi Gestionali... però spesso dare aria alla bocca è bello...
@Alex

 ha scritto nel messaggio 
news:ed2ce170-12d9-4e66...@b64g2000hsa.googlegroups.com...
[cut]
Mi spiace che la prendi cosě male. 

 applicativi Gestionali... però spesso dare aria alla bocca è bello...
Sono assolutamente d'accordo a metà (TM).
Secondo me non è questione di comodità, ma di aderenza ai concetti già
conosciuti. Siamo abituati a pensare in certi 'modi', usare certe
parole per formalizzarli, e quando mancano le parole comincia a farsi
difficile.
VBA è un linguaggio povero di keyword e concetti, credo che su questo
siamo tutti d'accordo... no?
Il linguaggio ricco, più che ai geni, farebbe comodo agli sviluppatori
"smart" che dovrebbero usare un RAD come Access per sviluppare
applicazioni in poco tempo. Costoro (me compreso) alla fine devono
tenersi la propria collezione di funzioni personali per (mal)
compensare le carenze del linguaggio.
ciao,
Panathos

"Fabrizio Conti (Panathos)"
Sono assolutamente d'accordo a metà (TM).
Secondo me non è questione di comodità, ma di aderenza ai concetti già
conosciuti. Siamo abituati a pensare in certi 'modi', usare certe
parole per formalizzarli, e quando mancano le parole comincia a farsi
difficile.
VBA è un linguaggio povero di keyword e concetti, credo che su questo
siamo tutti d'accordo... no?
Il linguaggio ricco, più che ai geni, farebbe comodo agli sviluppatori
"smart" che dovrebbero usare un RAD come Access per sviluppare
applicazioni in poco tempo. Costoro (me compreso) alla fine devono
tenersi la propria collezione di funzioni personali per (mal)
compensare le carenze del linguaggio.
----------------------------------------------------------------------------
-----------
Io d'accordo con te non lo sono affatto  ;-)
C'è anche troppa carne al fuoco per un DB-RAD: parlane con un neofita...
Ciao: Oscar

> Mi spiace che la prendi così male.
Ma non l'ho presa male... ho solo detto che hai parlato di una cosa
senza conoscerla... ma solo per averla letta in modo passivo.
Non prenderla male tu è uno stimolo al tuo studio.
@Alex

 Ciao: Oscar
Io concordo... per le cose che deve fare con un prodotto come Access(e
non stò affermando sia un prodotto
di 2° o 3° livello) direi che spesso ci si lascia prendere la mano
dalle velleità di scrivere codice... ;-)
Siccome poi metto VB6 circa allo stesso livello di Access(nonostante
abbia in se anche altre potenzialità) anche
per VB6 valgono gli stessi concetti...
Infondo chi deve sviluppare oggetti di un certo livello(interazioni
con il Socket o OPC o altri affini...) di certo non usa(diciamo non
dovrebbe) VB6 nè Access ma C o C++
Se si usa Access è perchè è comodo e veloce implementare il 90% di
quanto serve con Codice quasi ZERO.
@Alex

 ha scritto nel messaggio 
news:4f7d2823-b567-4ac9...@y21g2000hsf.googlegroups.com...



@Alex
La libertà di pensiero è un bene prezioso. Così, va tutelata a prescindere.
Ciao :)
eSQueL 

 eSQueL
Non confondere la libertà di pensiero con la libertà di dire le cose
solo per dirle...
Il 1° è un concetto democratico.
Il 2° è un concetto di educazione sociale.
Il 1° va tutelato
Il 2° si può tollerare ma non è bello.
Io ho applicato il 1° dicendoti quello che pensavo... vale a dire che
tu hai applicato il 2°.
@Alex

tu hai applicato il 2°.
Ecco, qui si torna in tema di tutela assoluta della libertà di pensiero. 
"Non condivido ciò che dici, ma lotterò fino alla morte perché tu possa 
esprimerlo" [cit.]
Ciao.
eSQueL 

Rendi conto semplicemente che hai solo CopianCollato testo senza
nemmeno capirlo... al quale
hai attribuito un senso assoluto non corretto.
Ognuno è libero di dire cose... anche sbagliate... poi si assume la
responsabilità di ciò che ha detto con ciò che ne consegue.
Se poi ti da fastidio che ti abbia fatto notare che quello che hai
scritto non lo conosci(viste le considerazioni)... la prossima volta
non scrivere... altrimenti accetta che un maleducato come me ti faccia
notare che hai voluto fare lo "sborone"...
@Alex

 quanto serve con Codice quasi ZERO.
Quasi zero? Ma se per avere un array ordinato bisogna tornare a scuola
e implementare un algoritmo di sort... quando con i linguaggi più
evoluti basta usare una riga.
ciao,
Panathos

 C'è anche troppa carne al fuoco per un DB-RAD: parlane con un neofita...
In generale sì, concordo.
Ma io parlavo solo di VBA e dei suoi limiti in termini di keyword e
concetti.
Vero che si fa presto ad impararlo (e grazie... saranno meno di 100
keyword); ma già se vuoi un semplice array ordinato devi saperti
scrivere l'algoritmo, oppure trovarti il codice su internet.
E se per qualche motivo si volesse usare un array associativo,
serializzare dati in un unico campo, parsare un directory tree in base
ad una espressione regolare... il programmatore deve perdere tempo a
reimplementare sempre la stessa acqua calda (finché lo sa fare) perché
mancano parole e concetti (serializzare, dir_walk, regexp); o sono
"importabili" tramite dubbi riferimenti... o ci si attacca al tram.
Il non-programmatore deve sperare che qualcuno passato da quelle parti
prima di lui abbia lasciato il codice.
Va da sé che l'obiezione "se uno non è un programmatore allora non ha
bisogno del codice" non vale, andando avanti con Access prima o poi le
corna ce le lascerà anche lui (vedi la maggior parte delle richieste
che passano di qui).
ciao,
Panathos

 ha scritto nel messaggio 
news:9bd11059-7a4e-476c...@8g2000hsu.googlegroups.com...



@Alex
_______
mm ... stai più attento al fegato (che ce n'è uno solo :P)
plonk

 C'è anche troppa carne al fuoco per un DB-RAD: parlane con un neofita...
In generale sì, concordo.
Ma io parlavo solo di VBA e dei suoi limiti in termini di keyword e
concetti.
Vero che si fa presto ad impararlo (e grazie... saranno meno di 100
keyword); ma già se vuoi un semplice array ordinato devi saperti
scrivere l'algoritmo, oppure trovarti il codice su internet.
E se per qualche motivo si volesse usare un array associativo,
serializzare dati in un unico campo, parsare un directory tree in base
ad una espressione regolare... il programmatore deve perdere tempo a
reimplementare sempre la stessa acqua calda (finché lo sa fare) perché
mancano parole e concetti (serializzare, dir_walk, regexp); o sono
"importabili" tramite dubbi riferimenti... o ci si attacca al tram.
Il non-programmatore deve sperare che qualcuno passato da quelle parti
prima di lui abbia lasciato il codice.
Va da sé che l'obiezione "se uno non è un programmatore allora non ha
bisogno del codice" non vale, andando avanti con Access prima o poi le
corna ce le lascerà anche lui (vedi la maggior parte delle richieste
che passano di qui).
----------------------------------------------------------------------------
-----
Beh, Fabrizio, vent'anni fa si creavano gestionali monumentali (a parte le
GUI, certo) con linguaggi che ti costringevano a scrivere mucchi di codice
perfino per gestire le Date...
Che dire: io quel tram-tram l'ho vissuto, seppur per poco, e di Visual Basic
proprio non riesco a lamentarmi  ;-)
Tu hai fatto esempi calzanti, ma molto specifici.
Sinceramente non vedo particolari limitazioni di linguaggio che costringano
a operare salti mortali; quantomeno in ambito gestionale.
Dove Access appare limitato è nella gestione della grafica, ma il fatto che
cose come queste siano realizzabili senza OCX:
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=53
E' un'evidenza di quanto (al di là della complessità) potente e flessibile
sia il sistema.
Ciao: Oscar

 plonk
Sanissimo...!
Dai che a forza di insistere lo ammetti che hai fatto lo "sborone"...!
@Alex

 sia il sistema.
Complimenti all'autore; ma a dirti la verità, della grafica me ne
importa relativamente poco.
ciao,
Panathos

 Tu hai fatto esempi calzanti, ma molto specifici.
Il punto è che prima o poi tutti dobbiamo farci le routine di verifica
di un file sull'hd, Tecnicamente sarà pure un esempio molto specifico,
ma a mio avviso è invece un esempio dei 'fondamentali' mancanti.
Perché milioni di utenti dovrebbero farsi la 'loro' routine, quando al
90% può bastare una funzione di sei righe che restituisca un boolean?
Chiaro che scrivere sei righe può non essere un problema... ma il
punto non è questo.
----------------------------------------------------------------------------
--------
'Momento: la presenza di un file sull'HD puoi verificarla con l'oggetto
<FileSearch>
----------------------------------------------------------------------------
------------
Ciao: Oscar

"Fabrizio Conti (Panathos)"
Il punto è che prima o poi tutti dobbiamo farci le routine di verifica
di un file sull'hd, Tecnicamente sarà pure un esempio molto specifico,
ma a mio avviso è invece un esempio dei 'fondamentali' mancanti.
Perché milioni di utenti dovrebbero farsi la 'loro' routine, quando al
90% può bastare una funzione di sei righe che restituisca un boolean?
Chiaro che scrivere sei righe può non essere un problema... ma il
punto non è questo.
Risposta:
Conosci la funzione DIR() ?
Saluti. 

 <FileSearch>
Sì ma non era questo il punto del discorso.
ciao,
Panathos

 <FileSearch>
Sě ma non era questo il punto del discorso.
ciao,
Panathos
Scusa l'intromissione, ma fai capire qual č il punto...
Tu dici che ci sono centinaia di seccanti limitazioni: fai esempi
concreti (oltre all'algoritmo d'ordinamento da terza superiore), per capire
e parlarne.
Se il tuo grande problema č verificare la presenza di un file su disco lo
puoi fare con una sola istruzione:
if DIR(<percorso file>)<>""     (vuol dire che esiste).
Dato che, parole tue, la grafica non t'interessa sono curioso di capire dove 
le vedi tutte ste manchevolezze.
Sicuro di conoscere bene il prodotto e quello che ci si puň fare?
Saluti.

 Conosci la funzione DIR() ?
Leggi le ultime due righe che avevo scritto; e magari anche quelle
prima.
Capisco di avere fatto un esempio poco felice, ma il concetto generale
direi che resta purtroppo valido.
ciao,
Panathos

 Conosci la funzione DIR() ?
Leggi le ultime due righe che avevo scritto; e magari anche quelle
prima.
Capisco di avere fatto un esempio poco felice, ma il concetto generale
direi che resta purtroppo valido.
Risposta:
Resta valido per te  ;-)
Dovresti fare almeno una decina d'esempi di funzionalità assenti in Access:
1 - Non grafiche, dato che non manifesti interesse alla cosa (giusto?)
2 - Ricorrenti in fase di sviluppo.
3 - Ottenibili solo con uno sforzo consistente di programmazione.
Guarda che non sono polemico (non farti ingannare), solo curioso.
Saluti. 

 Sicuro di conoscere bene il prodotto e quello che ci si può fare?
Affatto, Access lo uso da meno di tre anni e non penso di conoscere
così bene "il prodotto", sul quale ho già concordato riguardo le
potenzialità, e del quale non ho parlato; focalizzandomi sul solo VBA.
Il punto che ho proposto lo ripeto: VBA è un linguaggio povero di
keyword e di concetti rispetto ai linguaggi moderni (da Perl in poi).
La sua apparente semplicità si ritorce contro allo sviluppatore che
deve tenersi una collezione di funzioni più "evolute" (compreso il
sort citato anche da te), più o meno autoprodotte, delle quali si
potrebbe fare volentieri a meno se fossero native.
In considerazione di tutto questo, ho anche commentato che VBA è ben
lungi dall'essere un linguaggio che richiede la scrittura di poco
codice; e che nonostante tutto lo trovo divertente (sia Access come
prodotto, che VBA come linguaggio).
ciao,
Panathos

 e parlarne.
Però non vorrei che i toni uscissero dal seminato e si cominciassero a
travisare parole: mai parlato di "centinaia", e gli esempi concreti li
ho già fatti.
Il punto è che secondo me VBA è un linguaggio limitato poiché mancano
concetti da tempo presenti in molti altri linguaggi; e keyword adatte
a manipolarli.
In un altro messaggio ho citato array associativi, l'esempio di
ricerca file tramite espressioni regolari in un albero di cartelle, ed
a un 'serializzatore' nativo. Mi paiono esempi concreti.
Trattandosi di discussione un po' fine a sé stessa, non intendevo
elencare cosa c'è e cosa manca, ma solo fare un discorso in generale.








Risposta:
Le limitazioni del prodotto sono davvero centinaia, ma in termini "all 
purpose".
Nell'ambito per cui è stato creato (sviluppo d'interfacce per DB) ne vedo 
molto poche: soprattutto se consideriamo le release recenti.
Ma si devono fare esempi concreti e in tema.
In dieci anni di sviluppo d'applicazioni con Access, sinceramente, non ho 
avuto a che fare con:
"ricerca file tramite espressioni regolari in un albero di cartelle, ed
a un 'serializzatore' nativo"
Forse perchè mi sfugge il senso pratico-gestionale (e lo dico col cuore in 
mano, non polemicamente) di queste definizioni.
I problemi concreti legati al File System che s'incontrano si possono 
risolvere con Visual Basic, almeno da Access 97 in avanti:
Ricerca di files nel sistema tramite oggetto FileSearch
Verifica dell'esistenza di files o cartelle con  DIR().
Verifica degli attributi (lettura, nascosto, sistema, etc) di un 
file/Cartella con GetAttr o scrittura degli attributi con SetAttr
Verifica data creazione file o dimensione file con i vari FileLen, 
FileDateTime
....
Immagino che scrivendo un software di masterizzazione si abbia bisogno di 
altre informazioni sui files: ma qui si parla di DataBases.
In rapporto alle "poche" keywords di Visual Basic: ti faccio presente che 
sono centinaia solo quelle esposte da Microsoft Graph.
Dopo lustri d'utilizzo del prodotto ancora ci sono dettagli che mi sfuggono, 
e tu parli di grande *semplicità d'apprendimento*, scarsezza di 
funzionalità, etc.
Mah, sarà forse che sono più imbecille del previsto  ;-)
Saluti

 Mah, sarà forse che sono più imbecille del previsto  ;-)
Ma no, basta intendersi sui significati delle parole. VBA è nato come
"collante leggero" (passami il termine :-)) per le applicazioni
Office, è estensibile tramite OCX e DLL... chiaramente se consideriamo
tutta l'architettura COM+ c'è di che sentirsi molto piccoli di fronte
ad una montagna enorme. Ma io parlavo solo di VBA, eh...
ciao,
Panathos

 Mah, sarà forse che sono più imbecille del previsto ;-)
Ma no, basta intendersi sui significati delle parole. VBA è nato come
"collante leggero" (passami il termine :-)) per le applicazioni
Office, è estensibile tramite OCX e DLL... chiaramente se consideriamo
tutta l'architettura COM+ c'è di che sentirsi molto piccoli di fronte
ad una montagna enorme. Ma io parlavo solo di VBA, eh...
-----------------------------------------
Beh, chiaramente se ti riferisci a Visual Basic puro e semplice è come dici.
Ma chi lavora con Access ha giocoforza a che fare con un "ambiente" che 
mette insieme librerie e modelli a oggetti diversi.
Quindi che senso ha operare un distinguo?
Saluti: Simone

 Quindi che senso ha operare un distinguo?
Ha senso operare distinguo perché SONO distinti! Sia fisicamente nelle
varie librerie, che logicamente nei vari oggetti i quali -essendo
appunto esterni- devono essere referenziati.
ciao,
Panathos

 Quindi che senso ha operare un distinguo?
Ha senso operare distinguo perché SONO distinti! Sia fisicamente nelle
varie librerie, che logicamente nei vari oggetti i quali -essendo
appunto esterni- devono essere referenziati.
----------------------------------------------------------------------------------------
Proprio non ti capisco: soprattutto a livello pratico. Ripeto che non sei 
costretto a contraddirmi per forza.
La discussione nasceva dal fatto che, secondo te, l'ambiente ha molte 
limitazioni che costringono a soluzioni proprietarie che "mal risolvono" i 
problemi.
Vuoi forse dire che tu non prenderesti in considerazione l'oggetto 
FileSearch perchè è esposto da MSO.DLL piuttosto che da VBAXXX.dll?
O l'oggetto PRINTER, per manipolare le impostazioni di stampa, perchè viene 
esposto da MsAccess.OLB?
Altro che masochismo   ;-)
Secondo me molti (magari non tutti, ma certamente molti) dei tuoi problemi 
hanno soluzioni native. E ovviamente, che tali soluzioni siano "esposte" da 
una libreria piuttosto che da un'altra te ne frega meno di niente.
E quando parlo di "librerie", non mi riferisco a roba da comprare, ma a 
componenti PREINSTALLATE da qualunque versione di MS Access, per non dire 
indispensabili al suo funzionamento.
Probabilmente ci sono alcuni aspetti dell'ambiente che non hai ancora 
spulciato e, in secondo luogo, dovresti prendere in considerazione una 
versione meno obsoleta di Access.
Eh?    ;-)
Saluti: Simone


Beh, Fabrizio,  ti stai un tantino arrampicando sui vetri: dai ammettilo.
Saresti nel giusto se si parlasse di ActiveX o altro, ma le suddette
librerie sono il "midollo osseo" di Access.
I problemi teorici che hai sollevato non si applicano assolutamente a questo
prodotto. O alle installazioni Runtime, in totale esenzione da royaltees.
Del resto, metti nel cestino MsAccess.Olb o Mso97.dll ... che succede?
Ciao!

 Eh?    ;-)
Eh :-) E' dalla fine dell'anno scorso che sono perfettamente
autorizzato a comprare una versione per sviluppatori, ovviamente 2007.
Prima aspettavo l'SP1 in italiano, poi sono rimasto da solo con la
baracca da tirare avanti; e francamente di scoprire quali rogne
potrebbe portare l'upgrade (anche mio personale, con tutte le cose
nuove che ci sono) in circa sessanta macchine ed ottanta utenti
inferociti perché non trovano più l'icona che avevano fino al giorno
prima, ne ho proprio poca voglia.
ciao,
Panathos

 Del resto, metti nel cestino MsAccess.Olb o Mso97.dll ... che succede?
Che è tardissimo. Buona notte :-)
ciao,
Panathos

 librerie sono il "midollo osseo" di Access.
Ma scusa, � da svariati post che faccio differenza fra VBA e OCX.
Simone parla in termini di 'ambiente' e 'prodotto', rimarcando che non
ha molto senso fare la distinzione che faccio. Ora arrivi tu e dici
che quelle librerie "s�" e gli OCX "no"?
Io sarei anche d'accordo con te, ma parlavo di linguaggio VBA. Di per
s�, se i riferimenti a DAO sono corretti (350.dll <> 360.dll), allora
funziona correttamente (viceversa, ho visto una applicazione piantarsi
perch� non riconosceva la keyword left()).
Ma se parliamo di 'ambiente', allora dico che i problemi che ho
sollevato sono tutt'altro che teorici: MSgraph, a quanto mi risulta,
non � downgradabile; e l'ho scoperto a mie spese avventurandomi in una
disinstallazione file per file, chiave per chiave (seguendo istruzioni
ms) di qualsiasi cosa fosse imparentata con Office, che mi � costata
diverse ore di certosina pazienza e grossa incazzatura.
----------------------------------------------------------------------------
Ascolta Fabrizio, � inutile scrivere km di post per cose evidenti e fuori
discussione.
Un'installazione standard di Access, e un'installazione qualunque di Access
Runtime pre-installano (tra le tante cose):
MsAccess.OLB  (se assente non si avvia Access)
MSO.DLL   (se assente, non si avvia Access)
Componenti DAO  (non usate solo da files ADP)
Componenti ADO
Office Web Components
MsGraph (versione Runtime se installi Access Runtime)
Libreria VBAxxx.Dll
..............
(ovviamente
Quindi, "de facto", non ha senso (e, per favore, non discutere questa
realt�) fare una distinzione tra Office/Visual Basic e le propriet� e metodi
esposte dalle  librerie "midollo osseo".
Chiunque sviluppi con Access utilizza con la massima naturalezza sia le
funzioni interne di VBA che quelle esposte dal "midollo": concretamente sono
una cosa unica.
Qualche post pi� sotto ho ammesso un mio errore senza problemi (la questione
delle librerie MDE di Vincenzo Turturro): non c'� nulla di male Fabrizio.
Che poi, in casi particolari possano esserci problemi di "Lost References"
usando MSGraph � un'altra questione.
Questione che si risolve utilizzando l'associazione tardiva (che io uso
anche con l'insieme CommandBars esposto da MSO.DLL) oppure, meglio,
affidandosi per la distribuzione a prodotti come questo:
www.sagekey.com
Ma � una questione OT, dal discorso "limitazioni Access/Visual Basic", che
evidentemente comprende tutte le propriet�, metodi e costanti esposte dalle
componenti "midollo osseo".
Ciao   ;-)

 Eh? ;-)
Eh :-) E' dalla fine dell'anno scorso che sono perfettamente
autorizzato a comprare una versione per sviluppatori, ovviamente 2007.
Prima aspettavo l'SP1 in italiano, poi sono rimasto da solo con la
baracca da tirare avanti; e francamente di scoprire quali rogne
potrebbe portare l'upgrade (anche mio personale, con tutte le cose
nuove che ci sono) in circa sessanta macchine ed ottanta utenti
inferociti perché non trovano più l'icona che avevano fino al giorno
prima, ne ho proprio poca voglia.
[Risposta]
Fabrizio, ho tagliato quasi tutto non per maleducazione, ma per questioni di 
praticità: una risposta davvero Kilometrica  ;-)
Voglio solo tornare all'essenziale: dici di non aver mai avuto a che fare 
con distribuzioni Developer e col solo Access.
Va bene, ma resta il fatto che in una qualunque installazione Standard e 
corretta di Access, quelle che Oscar definisce librerie 'midollo osseo' sono 
presenti:
MsAccess.Olb
Mso.dll
DaoXXX.dll
Componenti MS Graph  (forse, dico forse, non installate di Default col 97, 
ma non posso ricordare)
I problemi di "Lost references" e i casini d'installazione Microsoft che hai 
giustamente evocato, sono altra cosa: dicesi bugs (con relativi workarounds 
su cui si potrebbe aprire altro thread).
Prendendo alla lettera il tuo discorso, non dovresti utilizzare oggetti DAO 
visto che hai avuto problemi con DAO350.Dll. Quindi dovresti ricorrere a 
files .TXT e non a tabelle di Access per memorizzare i dati.  Fai così? 
;-)
Qui si parla di limitazioni di VBA, che indubbiamente esistono .... ma non 
puoi fare un distinguo tra le keywords di VbaXXX.Dll e quelle esposte dal 
"midollo" (mi piace la definizione)
In particolare, e qui evoco Oscar, l'eventuale assenza di MsAccess.OLB o 
MsoXX.Dll impedirebbe perfino l'esecuzione di Access...
Se in futuro dovrai cercare files su disco, non ho dubbi che sfrutterai 
FileSearch.
Certo, ammesso che in una versione tanto obsoleta di Access funzioni   ;-)
Saluti: Oscar

 Saluti:     Oscar
Sě, al terzo caffč mattutino!   ;-)
Saluti: Simone! 

 una cosa unica.
Fatto sta che io parlavo di strutture di linguaggio, non di oggetti
istanziabili; e per quanto mi sforzi non riesco a vederle come una
'cosa' unica.
Ho anche parlato di ordinamento di matrici, di codice autoprodotto per
avere matrici ordinate, di assenza di concetto di hash.
Il punto centrale è che lo 'smart-developer' -secondo me-, opinabile
finché vuoi, è tale quando NON deve scriversi il codice di base. Il
resto che ho scritto sono stati esempi (non solo di lost references),
e un po' di sfogo personale :-). Di errori francamente non ne ho
visti.
ciao,
Panathos


Come ti scrive Simone, sarebbe interessante capire per quale ragione tu
utilizzi sovente strutture che in Access non servono praticamente mai.
Il tuo errore consiste nel voler negare l'evidenza. Se tu non hai usato
FileSearch (ad. ex) è perchè non lo conoscevi: altre spiegazioni
confinerebbero col masochismo. O con la convinzione, altrettanto errata, che
possa non essere presente sul PC la libreria d'oggetti Office (MsoXX.DLL).
Ciao: Oscar
P-S:  si trattava in effetti di una "E" accentata

 possa non essere presente sul PC la libreria d'oggetti Office (MsoXX.DLL).
Altre spiegazioni invece si avrebbero portando avanti il discorso
senza pregiudizi, travisazioni o dubbie derivazioni emozionali.
Ho già spiegato che a VB sono arrivato 'partendo' da altri linguaggi e
forma mentis, ed ho anche già buttato lì che "probabilmente, usare le
matrici non è il modo giusto di pensare", riferito a VB.
Ed ho anche fatto un esempio molto concreto di un lavoro che ho fatto,
nel quale ho 'implementato' serialize() e unserialize(), e dove gli
array associativi mi servivano per associare controlli ai loro valori
in stringhe ASCII. Cose sulle quali forse sarebbe stato opportuno
rispondere, invece di muovere accuse infondate.
ciao,
Panathos

 Certo, ammesso che in una versione tanto obsoleta di Access funzioni   ;-)
Boh, farò sapere :-)
ciao e grazie,
Panathos

 parlo dal primo messaggio, e se esistono non me l'avete ancora detto)
collection
-- 
ac
y-1=x

 Se tu non hai usato FileSearch (ad. ex) è perchè non lo conoscevi:
Questa è bella: siete stati tu e Simone a citare FileSearch, in
risposta ad un accenno di esempio di carenze di linguaggio ("ricerca
in un directory tree in base ad espressioni regolari"). Avete fatto
presente che l'oggetto esiste, e va bene, ma il punto del discorso ERA
IL LINGUAGGIO. Ora mi accusi di negare una "evidenza" perché secondo
te non conoscevo FileSearch.
E' dall'inizio del thread che specifico di separare linguaggio ed
oggetti, ho fatto esempi coerenti con questa premessa. Come fai a dire
che "glisso", "non ammetto", "nego l'evidenza"?
----------------------------------------------------------------------------
----------
Certo che non conoscevi FileSearch, altrimenti l'avresti usato!
E' dall'inizio del Thread che ti si cerca di spiegare l'acqua calda: non ha
senso fare un distinguo tra VBA e gli oggetti esposti dalle librerie base di
Access.
Ricapitolando, dato che in Access tu *considereresti* solo le keywords
esposte da Vbaxxx.Dll, si evincerebbe che:
1 - Non utilizzi l'insieme CommandBars per lavorare sulle barre dei menù e
FileSearch per sfrugugliare nel File System  (Mso97.Dll)
2 - Non utilizzi proprietà e metodi esposti da Graph per operare sui grafici
statistici    (MsGraph.Olb)
3 - Non utilizzi proprietà, metodi e Routines Evento per manipolare Forms,
Reports e relativi Controlli   (MsAccess.OLB)
4 - Non utilizzi oggetti Recordsets, Database, Tabledef (etc) per manipolare
i records memorizzati nelle tabelle  (Dao350.dll)
Giusto?
Facci capire, a questo punto, come usi Access e cosa sfrutti per memorizzare
i dati: sul serio files .txt gestibili con VBA?
Ciao: Oscar

 collection
Grazie Alessandro, questa è una buona risposta. Peccato ci siano pochi
metodi per gestirle. Però stamattina ho fatto a meno della 'solita'
matrice...
ciao,
Panathos

 Se utilizzi un prodotto, abituati alla filosofia di quel prodotto.
Ecco, la sostanza delle tue argomentazioni sta tutta qui: se non c'è
vuol dire che non serve.
Ne prendo atto, e visto che non ho più nulla da aggiungere rispetto a
quanto detto finora, chiudo il thread.
ciao,
Panathos

 "midollo" (mi piace la definizione)
Veramente sì, perché le keyword di un linguaggio ed i metodi/proprietà
di oggetti istanziabili continuano ad essere cose differenti... le
espressioni regolari sono implementate come oggetti istanziabili;
mentre le matrici no.
Gli array associativi esistono in qualche 'forma'? (chiedo perché ne
parlo dal primo messaggio, e se esistono non me l'avete ancora detto)
Risposta:
Fabrizio, insisti su sta cosa di "matrici" associative o meno: ma in Access 
gli Array si usano assai di rado.
Saluti.

 gli Array si usano assai di rado.
Uhm. Potrei postare le funzioni in cui uso le matrici e discuterne
qui. Male che vada imparerò qualcosa di nuovo, cosa che non mi
dispiace affatto.
ciao.
Panathos

 Che vuol dire non č downgradabile?
Vuol dire che se su una macchina hai una versione di Office, ed
installi una versione successiva, il controllo MSgraph te lo tieni
aggiornato e basta (il che praticamente obbliga ad usare late binding
per istanziare questo tipo di oggetti, sennņ si fa poca strada).
Risposta:
Posto che il problema non si pone con un adeguato installer per il Runtime 
... evviva l'associazione tardiva!
Saluti.

 Se utilizzi un prodotto, abituati alla filosofia di quel prodotto.
Ecco, la sostanza delle tue argomentazioni sta tutta qui: se non c'è
vuol dire che non serve.
----------------------------------------------------------------------------
--
Mie argomentazioni?
In questo ng, furbacchione, si trattano PHP, Perl et similia, o MS Access?
Se a te piace perder tempo con le matrici, su cose che ammettono soluzioni
agili (con QUESTO prodotto), è un problema tuo. Non pretendere che altri ti
seguano per forza...
Non realizzi che molti di quelli che ti rispondono sono professionisti che
hanno alle spalle procedure aziendali *vere*, non cacchiate a perditempo.
La sostanza delle mie argomentazioni è: impara a sviluppare con ACCESS.
Oppure continua ad utilizzare prodotti più consoni con la tua forma mentis.
----------------------------------------------------------------------------
--
Ne prendo atto, e visto che non ho più nulla da aggiungere rispetto a
quanto detto finora, chiudo il thread.
----------------------------------------------------------------------------
--
Ciccio, troppo comodo dire "chiudo il Thread quando lo dico io".
Ti ho cortesemente posto delle domande e sono estremamente curioso di
ricevere le risposte.


 ha scritto nel messaggio 
news:b07913bf-9eb9-47b8...@d45g2000hsc.googlegroups.com...
Salve a tutti,
scusate l'ignoranza, ho sempre usato access/vba in modo procedurale,
domanda: è possibile usare access anche in modo orientato agli
oggetti?....ma quando si parla di classi, si parla dell'argomento
"programmazione ad oggetti"?
grazie
---------------------------------------
Mica te lo credevi di accendere questa interessante discussione!
Almeno un interventino lo potevi fare...sei sparito.
Ciao, Carlo

 Oppure continua ad utilizzare prodotti più consoni con la tua forma mentis.
D'accordo. Detto questo, siccome abbiamo concetti di educazione
lievemente differenti; e siccome non sta scritto da nessuna parte che
ti siano dovute delle risposte, tantopiù visto l'atteggiamento
sfottirorio, ritorno a salutarti. Partecipare ed imparare mi
interessa, mentre di stupidi flame al momento non ho proprio voglia.
ciao,
Panathos

 Oppure continua ad utilizzare prodotti più consoni con la tua forma
mentis.
D'accordo. Detto questo, siccome abbiamo concetti di educazione
lievemente differenti; e siccome non sta scritto da nessuna parte che
ti siano dovute delle risposte, tantopiù visto l'atteggiamento
sfottirorio, ritorno a salutarti. Partecipare ed imparare mi
interessa, mentre di stupidi flame al momento non ho proprio voglia.
--------------------------------------------------------------------------
Sfottirorio?
Ma queste sono quisquillie rispetto ai flames che si sono visti da queste
parti.
Ormai pare di stare in politica: tutti preoccupati del politicamente
corretto.
Mah.
Ciao: Oscar
P.S: Ma capiterà un tuo post in cui s'evince che il Visual Basic di ACCESS
lo sfrutti in tutte le sue appendici ... eccome se capiterà...

 lo sfrutti in tutte le sue appendici ... eccome se capiterà...
Magari capitasse, prima dovrei esserne capace di sfruttare VBA in
tutte le sue appendici; e se lo fossi veramente probabilmente farei
meno fatica a fare una parte del mio lavoro.
Ci sono cose che semplicemente non ho mai fatto, ad esempio creare
barre degli strumenti personalizzate a runtime.
Altre cose le realizzo probabilmente "male" concettualmente, perché
uso mischioni di tecniche diverse apprese alla meglio durante gli anni
e non è detto che siano 'buone pratiche' in VBA, anzi. Ma del resto
non uso solo VBA, e non è sempre facile switchare fra linguaggi e
filosofie diverse.
Ad esempio ho dei frontend che per aggiornarsi generano batch a
runtime; i quali usano curl.exe per downloadare quel che devono (batch
più corto e con l'indicatore di operazione incluso nel prezzo). Uno
sviluppatore VB probabilmente tirerebbe la catena turandosi il naso
solo a pensarci; mentre il sottoscritto ha risolto in modo rapido una
serie di problemi.
A me NON viene chiesto di fare lo sviluppatore tout-court, ma di
fornire dati e far lavorare delle persone in modo efficiente; come
questo avvenga tecnicamente non frega niente a nessuno. Neanche a me,
fino ad un certo punto.
P.S.: ti invito a rileggere la frase da cui è scaturita la mia parte
di thread. Probabilmente alla luce delle cose che ho scritto finora
puoi capire meglio da quale contesto è scaturita.
ciao,
Panathos


Beh, soprattutto mi fa piacere che non te la sia presa troppo  ;-)
Certo la diplomazia non è il mio forte (ma nemmeno di Alex Baraldi!) ... ma
non c'è cattiveria nelle risposte che ho dato. Qella dell'altro giorno,
riletta ora, appare stronza oltre le intenzioni del momento.
Chiedo venia.
Au revoir:  Oscar!

 Au revoir:  Oscar!
E' tornato Natale e nessuno me lo ha detto? ;<)
-- 
ac
y-1=x


wrote:

Ed io che c'entro ora... ho fatto un fioretto e non ho voluto
intervenire oltremodo visto che tecnicamente vi erano ottimi elementi
ed ora dici che TU sei uno smanettone del tanto che vada... eppure che
IO non sono diplomatico...?? CHI IO....????
;-)
Buona giornata della Liberazione....!
@Alex

 Au revoir: Oscar!
Ed io che c'entro ora... ho fatto un fioretto e non ho voluto
intervenire oltremodo visto che tecnicamente vi erano ottimi elementi
ed ora dici che TU sei uno smanettone del tanto che vada... eppure che
IO non sono diplomatico...?? CHI IO....????
;-)
----------------------------------------------------------------------------
--
Smanettone del tanto che vada?
Boh
Ciao: Oscar

 Chiedo venia.
Qua la mano :-)
ciao,
Panathos

 Ciao: Oscar
Ciao
@Alex


Il fatto è che non le ho scritte io le frasi che mi attribuisci: a quanti
caffè stiamo oggi?   :-)
Ciao: Oscar


wrote:

Vuoi dire che ho sbagliato l'interpretazione del quoting....?
Bischeri... che non siete altro...!
Chiedo VENIA anche io allora... ;-)
@Alex