Discussione:
programmazione ad oggetti e classi
(troppo vecchio per rispondere)
pippo
2008-04-14 07:03:06 UTC
Permalink
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
eSQueL
2008-04-14 11:12:02 UTC
Permalink
"pippo" <***@gmail.com> ha scritto nel messaggio news:b07913bf-9eb9-47b8-9bfe-***@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"?

[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
Alessandro Baraldi
2008-04-14 11:27:46 UTC
Permalink
Post by pippo
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"?
[risposta]
VB (e, di conseguenza VBA) non è un vero limguaggio ad oggetti.
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.
"Programmare Visual Basic 6.0" - Francesco Balena - Microsoft Press
Ciao.
eSQueL
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
eSQueL
2008-04-14 11:58:02 UTC
Permalink
Post by pippo
Salve a tutti,
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
Alessandro Baraldi
2008-04-14 16:02:08 UTC
Permalink
[cut]
Post by eSQueL
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
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
eSQueL
2008-04-14 16:27:19 UTC
Permalink
"Alessandro Baraldi" <***@libero.it> ha scritto nel messaggio news:ed2ce170-12d9-4e66-9039-***@b64g2000hsa.googlegroups.com...
[cut]

Mi spiace che la prendi così male.
Alessandro Baraldi
2008-04-15 06:09:45 UTC
Permalink
Post by eSQueL
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
eSQueL
2008-04-15 07:28:36 UTC
Permalink
Post by eSQueL
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


La libertà di pensiero è un bene prezioso. Così, va tutelata a prescindere.

Ciao :)

eSQueL
Alessandro Baraldi
2008-04-15 10:01:38 UTC
Permalink
Post by Alessandro Baraldi
Post by eSQueL
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
La libertà di pensiero è un bene prezioso. Così, va tutelata a prescindere.
Ciao :)
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
eSQueL
2008-04-15 10:21:04 UTC
Permalink
Post by Alessandro Baraldi
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.
Questo è curioso: perdona la franchezza ma sembra proprio il bue che dà del
cornuto all'asino :DD
Post by Alessandro Baraldi
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°.
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
Alessandro Baraldi
2008-04-15 11:17:44 UTC
Permalink
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
eSQueL
2008-04-15 12:22:02 UTC
Permalink
"Alessandro Baraldi" <***@libero.it> ha scritto nel messaggio news:9bd11059-7a4e-476c-8884-***@8g2000hsu.googlegroups.com...
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

_______


mm ... stai più attento al fegato (che ce n'è uno solo :P)

plonk
Alessandro Baraldi
2008-04-15 15:47:30 UTC
Permalink
Post by eSQueL
mm ... stai più attento al fegato (che ce n'è uno solo :P)
plonk
Sanissimo...!
Dai che a forza di insistere lo ammetti che hai fatto lo "sborone"...!

@Alex
Fabrizio Conti (Panathos)
2008-04-14 14:53:07 UTC
Permalink
Post by Alessandro Baraldi
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...
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
Alessandro Baraldi
2008-04-14 16:05:06 UTC
Permalink
Post by Fabrizio Conti (Panathos)
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
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
Fabrizio Conti (Panathos)
2008-04-14 17:51:36 UTC
Permalink
Post by Alessandro Baraldi
A97 non supporta molte cose del VBA delle versioni dal 2000 in avanti.
Ah be', per quel che ho visto finora (A97, appunto) parlare di
programmazione OOP in VBA è francamente eccessivo. Senza contare che,
anche una volta tirate su le classi, devi farti delle funzioni-
interfaccia per usarle nelle query... ma comunque sto iniziando ad
apprezzarne l'utilità.
Post by Alessandro Baraldi
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...
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
Oscar Manfredini
2008-04-14 18:15:01 UTC
Permalink
"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
Alessandro Baraldi
2008-04-15 06:14:59 UTC
Permalink
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
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
Fabrizio Conti (Panathos)
2008-04-15 11:39:00 UTC
Permalink
Post by Alessandro Baraldi
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... ;-)
Mica tanto velleità, se con un po' di logica applicativa riesci ad
evitare strutture fisse e quindi ingestibili di default, meglio
scrivere codice riutilizzabile ed integrato che passare il tempo a
rifare le stesse cose.
Post by Alessandro Baraldi
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++
Dipende da quello che devi fare. Se vuoi garantirti di avere certe
macchine accese puoi farti una routine che lanci dei magic packet e
non occorre tirar fuori i grossi calibri per questo. Poi, di fondo,
sono d'accordo con te.
Post by Alessandro Baraldi
Se si usa Access è perchè è comodo e veloce implementare il 90% di
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
Fabrizio Conti (Panathos)
2008-04-15 11:39:16 UTC
Permalink
Post by Oscar Manfredini
"Fabrizio Conti (Panathos)"
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...
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
Oscar Manfredini
2008-04-15 12:31:35 UTC
Permalink
"Fabrizio Conti (Panathos)"
Post by Fabrizio Conti (Panathos)
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...
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
Fabrizio Conti (Panathos)
2008-04-15 20:31:14 UTC
Permalink
Post by Oscar Manfredini
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...
Sì d'accordo, all'epoca giochicchiavo col Basic dello Spectrum,
compravo riviste con chilometri di listati (mai ribattuti, troppo
sbattimento) e trovavo divertente manipolare i registri dello Z80 con
l'assembly... quando ho iniziato a usare Access tre anni fa mi
sembrava di tornare indietro nel tempo e tuttora lo considero più un
divertente giocattolo che uno strumento lavorativo.

Però vent'anni, al di fuori del VB, si sono fatti sentire molto.
Post by Oscar Manfredini
Che dire: io quel tram-tram l'ho vissuto, seppur per poco, e di Visual Basic
proprio non riesco a lamentarmi  ;-)
Contento te :-) A me scende la catena a smazzare arzigogoli che
replicano funzioni disponibili ormai in tutti i linguaggi.
Post by Oscar Manfredini
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.
Post by Oscar Manfredini
Sinceramente non vedo particolari limitazioni di linguaggio che costringano
a operare salti mortali; quantomeno in ambito gestionale.
Così però hai drammatizzato un tantino e ti sei scelto un ambito
specifico... :-D
Post by Oscar Manfredini
Dove Access appare limitato è nella gestione della grafica, ma il fatto che
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=53
E' un'evidenza di quanto (al di là della complessità) potente e flessibile
sia il sistema.
Complimenti all'autore; ma a dirti la verità, della grafica me ne
importa relativamente poco.

ciao,
Panathos
Oscar Manfredini
2008-04-16 07:14:43 UTC
Permalink
"Fabrizio Conti (Panathos)"
Post by Oscar Manfredini
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...
Sì d'accordo, all'epoca giochicchiavo col Basic dello Spectrum,
compravo riviste con chilometri di listati (mai ribattuti, troppo
sbattimento) e trovavo divertente manipolare i registri dello Z80 con
l'assembly... quando ho iniziato a usare Access tre anni fa mi
sembrava di tornare indietro nel tempo e tuttora lo considero più un
divertente giocattolo che uno strumento lavorativo.


----------------------------------------------------------------------------
-

Io parlavo/parlo di gestionali "veri", non di giochini...

----------------------------------------------------------------------------
-
Post by Oscar Manfredini
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)
2008-04-16 09:37:52 UTC
Permalink
Post by Oscar Manfredini
'Momento: la presenza di un file sull'HD puoi verificarla con l'oggetto
<FileSearch>
Sì ma non era questo il punto del discorso.

ciao,
Panathos
Simone Calligaris
2008-04-16 09:49:31 UTC
Permalink
"Fabrizio Conti (Panathos)"
Post by Oscar Manfredini
'Momento: la presenza di un file sull'HD puoi verificarla con l'oggetto
<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.
Fabrizio Conti (Panathos)
2008-04-16 12:44:32 UTC
Permalink
Post by Simone Calligaris
Scusa l'intromissione, ma fai capire qual è il punto...
Figurati, essendo ng pubblico più che intromissione è partecipazione.
Post by Simone Calligaris
Tu dici che ci sono centinaia di seccanti limitazioni: fai esempi
concreti (oltre all'algoritmo d'ordinamento da terza superiore), per capire
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.
Post by Simone Calligaris
Se il tuo grande problema è verificare la presenza di un file su disco lo
Altra tua travisazione: non ho scritto che il mio problema fosse
quello.
Post by Simone Calligaris
if DIR(<percorso file>)<>""     (vuol dire che esiste).
Cmq prendiamo l'esempio che hai fatto tu: per come l'hai scritta, puoi
avere conferma se la stringa <percorso file> corrisponda ad un file
nel filesystem.
Il che fa piacere saperlo, ma di solito se cerco un file è perché
voglio farci qualcosa con quel file, pertanto:

- il file è in lettura/scrittura?
- se è di sola lettura, lo è per attributo impostato o perché un altro
utente vi ha accesso esclusivo?
- posso usare write/append in questo file?
- se la stringa passata in argomento fosse una directory?

Il punto del discorso che stavo facendo è che dir() da solo non basta,
così come non bastano le poche funzioni "atomiche" di VBA per scrivere
davvero poco codice.
E, francamente, non mi sembra neanche chissà quale scoperta.
Post by Simone Calligaris
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
Simone Calligaris
2008-04-16 13:20:47 UTC
Permalink
"Fabrizio Conti (Panathos)"
Post by Simone Calligaris
Tu dici che ci sono centinaia di seccanti limitazioni: fai esempi
concreti (oltre all'algoritmo d'ordinamento da terza superiore), per capire
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.
Post by Simone Calligaris
if DIR(<percorso file>)<>"" (vuol dire che esiste).
Cmq prendiamo l'esempio che hai fatto tu: per come l'hai scritta, puoi
avere conferma se la stringa <percorso file> corrisponda ad un file
nel filesystem.
Il che fa piacere saperlo, ma di solito se cerco un file è perché
voglio farci qualcosa con quel file, pertanto:

- il file è in lettura/scrittura?
- se è di sola lettura, lo è per attributo impostato o perché un altro
utente vi ha accesso esclusivo?
- posso usare write/append in questo file?
- se la stringa passata in argomento fosse una directory?

Il punto del discorso che stavo facendo è che dir() da solo non basta,
così come non bastano le poche funzioni "atomiche" di VBA per scrivere
davvero poco codice.
E, francamente, non mi sembra neanche chissà quale scoperta.
Post by Simone Calligaris
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).


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
Fabrizio Conti (Panathos)
2008-04-16 15:23:51 UTC
Permalink
Post by Simone Calligaris
Le limitazioni del prodotto sono davvero centinaia, ma in termini "all
purpose".
Scusa, avevo già fatto distinzione fra "prodotto" e "linguaggio"
dicendo che il prodotto è poco limitato mentre il linguaggio sì. Se
parti dicendo che il prodotto è molto limitato in generale, ma nel suo
ambito lo è poco, stai facendo un discorso differente (e sul quale,
detto così, concordo).
Post by Simone Calligaris
In dieci anni di sviluppo d'applicazioni con Access, sinceramente, non ho
"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.
Non ti sarebbe mai servito avere un campo in cui memorizzare il valore
di un array (o collection) di controlli; e da cui andarli ad
'esplodere' facilmente?

Per il resto, è inutile inventare esempi per trovare ipotetiche
soluzioni, potrebbe essere utile ma in un altro thread. A me può
essere servito poche volte, forse mai veramente se diciamo che ci sono
(quasi) sempre più strade per arrivare al risultato.
Post by Simone Calligaris
I problemi concreti legati al File System che s'incontrano si possono
Ricerca di files nel sistema tramite oggetto FileSearch
[...]

Ok grazie, se aggiungi l'oggetto FileSearch ottieni quelle funzioni...
però non è più VBA; è un oggetto referenziato come altri.
Post by Simone Calligaris
In rapporto alle "poche" keywords di Visual Basic: ti faccio presente che
sono centinaia solo quelle esposte da Microsoft Graph.
Che è un altro OCX; e faccio differenza fra VBA come linguaggio e come
contenitore di oggetti istanziabili (ed utilizzabili, certamente).
Post by Simone Calligaris
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.
Se parliamo del "prodotto" nella sua interezza, ti credo sulla parola;
ma riguardo VBA ( come linguaggio, ripeto) non ci credo neanche se sei
sotto tortura che hai dei dubbi. Qui sopra hai usato di nuovo la
parola "prodotto", riferendoti ad entrambe le cose.
Post by Simone Calligaris
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
Simone Calligaris
2008-04-17 07:46:43 UTC
Permalink
Post by Simone Calligaris
"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.
Non ti sarebbe mai servito avere un campo in cui memorizzare il valore
di un array (o collection) di controlli; e da cui andarli ad
'esplodere' facilmente?
Oddio ... no.
Forse perchè, appunto, i miei metodi di lavoro sono diversi dai tuoi.
Post by Simone Calligaris
I problemi concreti legati al File System che s'incontrano si possono
Ricerca di files nel sistema tramite oggetto FileSearch
[...]

<Ok grazie, se aggiungi l'oggetto FileSearch ottieni quelle funzioni...<
Post by Simone Calligaris
però non è più VBA; è un oggetto referenziato come altri.
In rapporto alle "poche" keywords di Visual Basic: ti faccio presente che
sono centinaia solo quelle esposte da Microsoft Graph.
Che è un altro OCX; e faccio differenza fra VBA come linguaggio e come
contenitore di oggetti istanziabili (ed utilizzabili, certamente).
Mhmmmmmmm ;-)

Vabbè, ma a chi può interessare che oggetti proprietà e metodi vengano
esposti da VBA332.Dll piuttosto invece che da MsAccess.OLB, Graph.OLB, DAO,
ADO o MsO.DLL?
Qui si parla di Access-Visual Basic: quindi non capisco che senso abbia fare
un distinguo.
Post by Simone Calligaris
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.
Se parliamo del "prodotto" nella sua interezza, ti credo sulla parola;
ma riguardo VBA ( come linguaggio, ripeto) non ci credo neanche se sei
sotto tortura che hai dei dubbi. Qui sopra hai usato di nuovo la
parola "prodotto", riferendoti ad entrambe le cose.
Post by Simone Calligaris
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
Fabrizio Conti (Panathos)
2008-04-17 13:54:10 UTC
Permalink
Post by Simone Calligaris
Post by Fabrizio Conti (Panathos)
Non ti sarebbe mai servito avere un campo in cui memorizzare il valore
di un array (o collection) di controlli; e da cui andarli ad
'esplodere' facilmente?
Oddio ... no.
Forse perchè, appunto, i miei metodi di lavoro sono diversi dai tuoi.
Il che è probabile, dopotutto a COM+ (diciamo così) sono arrivato
abbastanza di recente dopo Perl, PHP ed il resto del carrozzone web; e
non facendo solo lo sviluppatore di certo non sono un fulmine di
guerra come coder.

Per tornare a bomba, giusto la settimana scorsa mi era stato chiesto
di fare una maschera dove l'utente potesse salvare i parametri di una
query (circa una decina di controlli) e richiamarli in seguito (in
realtà la richiesta era più complessa, ma per l'esempio va bene).
Io l'ho risolta tramite due stringhe infilate in due campi di tabella;
una contiene i nomi dei controlli mentre l'altra i valori.

Per curiosità, tu come avresti risolto?

Cmq per fare questo giochino quantomeno occorrono split() e join(),
assenti in A97 (per la cronaca, uso quelle presenti su sitocomune). Ed
il risultato che ho ottenuto è stato di reimplementare serialize() e
unserialize().
Post by Simone Calligaris
Post by Fabrizio Conti (Panathos)
Che è un altro OCX; e faccio differenza fra VBA come linguaggio e come
contenitore di oggetti istanziabili (ed utilizzabili, certamente).
Mhmmmmmmm    ;-)
Vabbè, ma a chi può interessare che oggetti proprietà e metodi vengano
esposti da VBA332.Dll piuttosto invece che da MsAccess.OLB, Graph.OLB, DAO,
ADO o MsO.DLL?
Innanzitutto al programmatore, perché se sulla macchina di produzione
non ci sono le librerie che stanno sulla sua, sono guai. Poi al
sistemista, che dovrà provvedere affinché giri tutto correttamente.
Terzo, al titolare di quella macchina, che dovrà eventualmente
sborsare la cifra necessaria a procurarsele :-) Il che può chiamare in
causa il fornitore software, financo a quello hardware.
Post by Simone Calligaris
Qui si parla di Access-Visual Basic: quindi non capisco che senso abbia fare
un distinguo.
Perché in generale si può istanziare un oggetto COM anche da PHP,
Perl, Python; e ciò non significa che anche questi 'siano' VB. Mi pare
che se non si fanno distinzioni si può considerare VB qualsiasi 'cosa'
possa istanziare un oggetto ed interagire con esso. Fattibile, certo,
ma tutto il discorso che avevo iniziato era basato sulla premessa
opposta.
Post by Simone Calligaris
Beh, chiaramente se ti riferisci a Visual Basic puro e semplice è come dici.
Be', alla fine ad un punto di accordo ci siamo arrivati, mi fa
piacere.
Ma ora per avere matrici ordinate con natural sort devo mettermi a
scrivere codice, (piuttosto che farlo per questo mi pesto le dita)
oppure trovo un componente che posso aggiungere senza timore di varie
incompatibilità con altri esistenti; preoccuparmi che sia sempre
raggiungibile nei riferimenti, non si mangi troppa memoria, etc.? E
per gli hash c'è qualcosa del genere? :-)
Post by Simone Calligaris
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?
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
Simone Calligaris
2008-04-17 15:24:51 UTC
Permalink
"Fabrizio Conti (Panathos)" <
Post by Simone Calligaris
Post by Fabrizio Conti (Panathos)
Non ti sarebbe mai servito avere un campo in cui memorizzare il valore
di un array (o collection) di controlli; e da cui andarli ad
'esplodere' facilmente?
Oddio ... no.
Forse perchè, appunto, i miei metodi di lavoro sono diversi dai tuoi.
Il che è probabile, dopotutto a COM+ (diciamo così) sono arrivato
abbastanza di recente dopo Perl, PHP ed il resto del carrozzone web; e
non facendo solo lo sviluppatore di certo non sono un fulmine di
guerra come coder.

Per tornare a bomba, giusto la settimana scorsa mi era stato chiesto
di fare una maschera dove l'utente potesse salvare i parametri di una
query (circa una decina di controlli) e richiamarli in seguito (in
realtà la richiesta era più complessa, ma per l'esempio va bene).
Io l'ho risolta tramite due stringhe infilate in due campi di tabella;
una contiene i nomi dei controlli mentre l'altra i valori.

Per curiosità, tu come avresti risolto?

Cmq per fare questo giochino quantomeno occorrono split() e join(),
assenti in A97 (per la cronaca, uso quelle presenti su sitocomune). Ed
il risultato che ho ottenuto è stato di reimplementare serialize() e
unserialize().


--------------------------------------------------------------------------------------------------

Risposta:

Mah, nelle mie applicazioni (anzi, "nostre", dato che ho dei colleghi)
usiamo un sistema di carattere generale per permettere agli utenti di
salvare e recuperare i "filtri": una utility simile a questa

http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=280

Meno sofisticata, ma paragonabile.

In rapporto a Split() e Join(): Fabrizio tu stai utilizzando una versione di
Access a dir poco preistorica (sul mercato nel dicembre 1996) ... è già un
miracolo che sia ancora usabile.
Le funzioni in oggetto sono supportate da A '2K in avanti ... così come
decine di altre importanti features: oggetto Recordset, Printer,
FormatCondition, AddItem per Combo/Listboxes, SubDataSheets, etc etc

Ma per quale ragione utilizzi una release tanto obsoleta?

------------------------------------------------------------------------------------------------------
Post by Simone Calligaris
Post by Fabrizio Conti (Panathos)
Che è un altro OCX; e faccio differenza fra VBA come linguaggio e come
contenitore di oggetti istanziabili (ed utilizzabili, certamente).
Mhmmmmmmm ;-)
Vabbè, ma a chi può interessare che oggetti proprietà e metodi vengano
esposti da VBA332.Dll piuttosto invece che da MsAccess.OLB, Graph.OLB, DAO,
ADO o MsO.DLL?
Innanzitutto al programmatore, perché se sulla macchina di produzione
non ci sono le librerie che stanno sulla sua, sono guai. Poi al
sistemista, che dovrà provvedere affinché giri tutto correttamente.
Terzo, al titolare di quella macchina, che dovrà eventualmente
sborsare la cifra necessaria a procurarsele :-) Il che può chiamare in
causa il fornitore software, financo a quello hardware.


------------------------------------------------------------------------------------------------

???
Ma stiamo parlando di Access?

Guarda che MsAccess.OLB, Graph.OLB, DAO, ADO, MSO.DLL sono componenti
preinstallate da Access/Office e disponibili su qualunque macchina.
NON esistono licenze da pagare o problemi "d'indisponibilità" su macchine di
produzione o problemi sistemistici o altro.

Se installi Access (o le relative Runtime per la distribuzione) tutta quella
roba è "On-Line".
Anzi, in assenza di alcune di quelle librerie nemmeno s'avvierebbe MS
Access.

Guarda che non devi contraddirmi a tutti i costi ;-)

------------------------------------------------------------------------------------------------
Post by Simone Calligaris
Qui si parla di Access-Visual Basic: quindi non capisco che senso abbia fare
un distinguo.
Perché in generale si può istanziare un oggetto COM anche da PHP,
Perl, Python; e ciò non significa che anche questi 'siano' VB. Mi pare
che se non si fanno distinzioni si può considerare VB qualsiasi 'cosa'
possa istanziare un oggetto ed interagire con esso. Fattibile, certo,
ma tutto il discorso che avevo iniziato era basato sulla premessa
opposta.



------------------------------------------------------------------------------------------------

Ma qui si parla di sviluppo con Access, e relativi problemi, o di altro?

------------------------------------------------------------------------------------------------
Post by Simone Calligaris
Beh, chiaramente se ti riferisci a Visual Basic puro e semplice è come dici.
Be', alla fine ad un punto di accordo ci siamo arrivati, mi fa
piacere.
Ma ora per avere matrici ordinate con natural sort devo mettermi a
scrivere codice, (piuttosto che farlo per questo mi pesto le dita)
oppure trovo un componente che posso aggiungere senza timore di varie
incompatibilità con altri esistenti; preoccuparmi che sia sempre
raggiungibile nei riferimenti, non si mangi troppa memoria, etc.? E
per gli hash c'è qualcosa del genere? :-)


-----------------------------------------------------------------------------------

E sarei curioso di vedere che fai con Access, se ti servono di continuo
matrici ordinate.
Capisco vent'anni fa, quando le interfacce dovevamo gestirle noi, ma ora che
tutto si disegna col Mouse...

In rapporto ai componenti ActiveX (ti riferisci a quelli) parliamone.
Personalmente posso dire di non avere alcun problema con i comuni TreeView o
ListView, gli unici che uso.
Così su due piedi non capisco di quali altri controlli possa avere bisogno
un "Accessista", dato che con un minimo sforzo tutto il resto si ottiene.

Anche grazie alle centinaia di .MDB Free che si trovano sul web, che spesso
risolvono *problemoni* con quattro righe di codice.

-----------------------------------------------------------------------------------
Post by Simone Calligaris
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?
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
Fabrizio Conti (Panathos)
2008-04-18 00:29:38 UTC
Permalink
Post by Simone Calligaris
"Fabrizio Conti (Panathos)" <
Post by Simone Calligaris
Post by Fabrizio Conti (Panathos)
Non ti sarebbe mai servito avere un campo in cui memorizzare il valore
di un array (o collection) di controlli; e da cui andarli ad
'esplodere' facilmente?
Oddio ... no.
Mah, nelle mie applicazioni (anzi, "nostre", dato che ho dei colleghi)
usiamo un sistema di carattere generale per permettere agli utenti di
salvare e recuperare i "filtri": una utility simile a questa
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=280
Ho visto il link ma l'esempio è per A2002. Approfondirò con calma. A
quanto pare per un'esigenza simile, hai seguito un metodo diverso, e
la cosa mi interessa.
Post by Simone Calligaris
In rapporto a Split() e Join(): Fabrizio tu stai utilizzando una versione di
Access a dir poco preistorica (sul mercato nel dicembre 1996) ... è già un
miracolo che sia ancora usabile.
[...]
Post by Simone Calligaris
Ma per quale ragione utilizzi una release tanto obsoleta?
Per diverse ragioni ed anche circostanze. Diciamo che c'è una
situazione di transizione che sta andando avanti da tempo, e non è
detto che lo svecchiamento del parco macchine non si concluda con un
parco di thin client (nel qual caso, fine applicazioni Access).

Cmq attualmente abbiamo anche dei P3 con 128 Mb di RAM nel parco
macchine... e su queste Office 97 riesce ancora ad essere accettabile,
come tempi (chiaramente c'è sempre OE in esecuzione, almeno due
finestre di IE con applicazione Java di Direzione aperta, un antivirus-
mattone, e gli utenti che cercano di barcamenarsi).
Post by Simone Calligaris
Innanzitutt al programmatore, perché se sulla macchina di produzione
non ci sono le librerie che stanno sulla sua, sono guai. Poi al
sistemista, che dovrà provvedere affinché giri tutto correttamente.
[...]
Post by Simone Calligaris
Guarda che MsAccess.OLB, Graph.OLB, DAO, ADO, MSO.DLL sono
componenti preinstallate da Access/Office e disponibili su qualunque macchina.
Scusa ma devo contraddirti :-) Sono disponibili e preinstallate nel
momento in cui hai comprato Office, sennò non ci sono.
A me cmq questo non importa: i pc che ricevo dalla Direzione hanno
SEMPRE Office installato, ed infatti sono tre anni che tolgo la loro
versione (2000, XP, 2003... macchine con la 2007 non mi sono ancora
arrivate e forse non arriveranno mai); per installare la 'nostra'
versione.
Post by Simone Calligaris
NON esistono licenze da pagare o problemi "d'indisponibilità" su macchine di
produzione o problemi sistemistici o altro.
Mi sa che manca un altro pezzo del puzzle: io dispongo di tutti gli
Office, ma in versione Professional. Niente Developer, mai usato; ed
ho iniziato ad interessarmi dopo la CISA (pertanto ormai aspettavo
l'anno nuovo e l'SP1 per Office 2007... e mi sa che aspetterò ancora).
Tu stai pensando allo sviluppatore che rilascia pacchetti; cosa che
sono solo a metà.
Post by Simone Calligaris
Guarda che non devi contraddirmi a tutti i costi  ;-)
Figurati, io avevo solo fatto un paio di commenti sul VBA e detto cosa
pensavo riguardo il concetto di 'smart-developer'... figura
professionale nella quale giocoforza mi riconosco.
Post by Simone Calligaris
Perché in generale si può istanziare un oggetto COM anche da PHP,
Perl, Python; e ciò non significa che anche questi 'siano' VB. Mi pare
Ma qui si parla di sviluppo con Access, e relativi problemi, o di altro?
Di Access e relativi problemi. Ma è utile chiarirsi.
Post by Simone Calligaris
Ma ora per avere matrici ordinate con natural sort devo mettermi a
scrivere codice, (piuttosto che farlo per questo mi pesto le dita)
E sarei curioso di vedere che fai con Access, se ti servono di continuo
matrici ordinate.
Era un (reale) esempio tra l'ironico ed il sarcastico. Tu trovi
curioso che io pensi in termini di matrici, ed hai ragione dal momento
che, in effetti, nel tuo ambiente con le matrici non ci fai
praticamente nulla e gli hash non ci sono.
Significa che le matrici non sono il 'modo giusto' di pensare,
probabilmente.
Post by Simone Calligaris
In rapporto ai componenti ActiveX (ti riferisci a quelli) parliamone.
In effetti mi piacerebbe, perché cerco di evitarli mentre so
perfettamente che c'è parecchia roba interessante (inutile ribadire
che uso FTP via batch :-)).

Ma del resto (e qui, se ci sta leggendo, rispondo anche a Oscar)
l'anno scorso avevo inserito il 'calendario' in una applicazione.

Non ce n'era affatto bisogno del calendario perché avevo costruito un
selettore di periodi (grazie ad una matrice, fondamentalmente :-)),
per cui l'utente non avrebbe praticamente mai avuto bisogno di
scegliersi le due date del range; ma mi era sembrata una cosa tutto
sommato innocua e vagamente sfiziosa.

Dopo un po' di tempo l'applicazione smise improvvisamente di
funzionare su almeno due PC, il riferimento al controllo calendario
restituiva un errore (che francamente non ricordo). Da 'bravo'
sistemista ho tolto il calendario, messo in linea l'aggiornamento, e
non me ne sono più preoccupato perché tutto il resto funzionava
regolarmente.
Post by Simone Calligaris
Personalmente posso dire di non avere alcun problema con i comuni TreeView
o ListView, gli unici che uso.
Così su due piedi non capisco di quali altri controlli possa avere bisogno
un "Accessista", dato che con un minimo sforzo tutto il resto si ottiene.
Credo un paio di annetti fa, mi fu consegnata una pestilenziale
accozzaglia di più di 35.000 dati anagrafici, che chiamare 'elenco' è
un insulto alla tomba di Aristotele.
Senza espressioni regolari (ho usato un misto di Access, PHP e
OpenOffice per averne ragione) probabilmente avrei impiegato molto più
dei due giorni lavorativi occorsi per sistemarlo in una tabella.

Racconto queste cose (abbastanza OT) nel tentativo di spiegare perché
penso le cose che scrivo, non è che dico o contraddico per il gusto di
farlo.
Parlo di cose reali che mi sono capitate, e che mi fanno pensare che
il tutto il paradigma di Access è semplicemente perfetto nel suo
ambito, e che secondo me il 'motore' sarebbe molto migliorabile
proprio nella SUA ottica; cioè come servizio allo 'sviluppatore-
smart'.
Post by Simone Calligaris
Anche grazie alle centinaia di .MDB Free che si trovano sul web, che spesso
risolvono *problemoni* con quattro righe di codice.
Scusa ma questo c'entra relativamente poco con il discorso iniziale,
che erano i limiti di VBA. Documentazione ed esempi se ne trovano in
quantità per quasi qualsiasi linguaggio, ormai. Probabilmente un
cultore di Haskell potrebbe dire la stessa cosa; e cito quello solo
perché _io_ l'ho trovato vagamente astruso, non me ne vogliano i
puristi della matematica o i cultori di linguaggi più astrusi :-)
Post by Simone Calligaris
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.
Ma come... eppure hai concordato sul fatto che il VBA puro e semplice
è povero. Non capisco cosa non capisci. Guarda che io solo quello
stavo dicendo, nulla più e nulla meno.
Ho distinto apposta VBA dall'ambiente, non perché sia più o meno
pertinente od opportuno farlo; ma perché stavo considerando il solo
linguaggio, e commentando quello. E nei tuoi interventi hai parlato di
'prodotto' e 'ambiente', quasi mai di 'linguaggio', come se fossero
una cosa sola, indistinguibile o inutile da distinguere. Allora ho
cercato di tracciare meglio la separazione che avevo fatto, e sei
tornato a parlare di prodotto.

Se continuiamo così diventa sterile, se ritieni opportuno non separare
le cose allora ti seguo e parliamo di ambiente e prodotto. Ma non è il
discorso da cui ero partito.
Post by Simone Calligaris
La discussione nasceva dal fatto che, secondo te, l'ambiente ha molte
limitazioni che costringono a soluzioni proprietarie che "mal risolvono" i
problemi.
Vedi che anche nel passo qui sopra sei tornato a parlare di ambiente?
La discussione è nata da quello che ho chiamato 'linguaggio', avulso
dagli oggetti referenziabili (poiché sono referenziabili ugualmente in
altri linguaggi).

Se sostieni che non si può considerare VBA senza l'architettura in cui
è nato e per cui è stato pensato perché 'praticamente' ha poco senso;
mi sta benissimo, è fattibile, perché no, ma il mio discorso era
differente.
Post by Simone Calligaris
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   ;-)
Siccome non ho mai usato FileSearch (escluso breve scriptino AutoIT,
che non c'entra) e nemmeno Printer, credo di dovermi considerare
masochista o fortunato, a non averne avuto bisogno (a dire il vero
vagamente ricordo di avere manipolato le impostazioni di stampa in
Word da codice, ma printer se non sbaglio esiste da Office 2000 in
poi).
Post by Simone Calligaris
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.
Se dici così, avrai sicuramente i tuoi motivi. Ti racconto un paio di
episodi miei.
Due o tre annetti fa ci fu un periodo di tribolo perché le
applicazioni dell'ex-collega non andavano su qualche portatile. Lui
aveva referenziato DAO350.DLL, e sui portatili era mancante (c'era
DAO360.DLL).

Altresì ricordo quando l'ex collega, che aveva solo Office 97 sulla
sua macchina, aveva referenziato msgraph e i grafici davano errore
sulle macchine che avevano installato ANCHE Office 2003. Alché risolse
installando anche Office 2003 sulla sua macchina, e facendo un casino
boia perché dopo qualche giorno di smanettamenti non c'era verso di
far andare i grafici, finché mi chiese se potevo fare una
"disinstallazione totale" di tutti gli Office.

Ricordo come un incubo la pagina ms con le istruzioni per la
disinstallazione totale.
L'elenco di file da cancellare, le chiavi di registro da togliere, i
batch che ho generato copiaincollando e smanettando con l'editor di
testo; e le ore che ho perso dietro a quella faccenda perché sembrava
impossibile disinstallare e reinstallare Office, c'era sempre qualcosa
che non andava.
Alla fine ce l'ho fatta, credo di avere ancora i batch che ho usato
(in caso avessi mai dovuto rifarlo).

Non sono stati gli unici problemi che ho avuto con Office, ma sono
stati i più eclatanti. E qui se vuoi puoi tornare da capo a questo
lunghissimo messaggio, dove spiegavo i vari motivi per cui siamo
ancora a Office 97.
Post by Simone Calligaris
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?    ;-)
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
Simone Calligaris
2008-04-19 08:19:33 UTC
Permalink
"Fabrizio Conti (Panathos)"



(cut)
Post by Simone Calligaris
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? ;-)
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
Simone Calligaris
2008-04-19 08:21:16 UTC
Permalink
"Simone Calligaris"
Saluti: Oscar
Sì, al terzo caffè mattutino! ;-)

Saluti: Simone!
Fabrizio Conti (Panathos)
2008-04-21 16:48:22 UTC
Permalink
Post by Simone Calligaris
Fabrizio, ho tagliato quasi tutto non per maleducazione, ma per questioni di
praticità: una risposta davvero Kilometrica  ;-)
Chiedo venia, e ringrazio per non avere risposto su tutto sennò non si
finiva più :-)
Post by Simone Calligaris
Componenti MS Graph  (forse, dico forse, non installate di Default col 97,
ma non posso ricordare)
Sì ci sono anche questi.
Post by Simone Calligaris
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).
Nel caso di MSgraph, non so se sia un bug ma MS dichiara che non è
downgradabile.
Post by Simone Calligaris
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ì?
;-)
Oddio, il mio discorso era un po' diverso, ho citato i problemi di
librerie ma l'assunto iniziale era "struttura linguaggio <> oggetti".
Per il resto effettivamente cerco di usare meno OCX possibile (e l'ho
anche già scritto che per FTP e email uso Curl e Blat).
Post by Simone Calligaris
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)
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)
Post by Simone Calligaris
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   ;-)
Boh, farò sapere :-)

ciao e grazie,
Panathos
Alessandro Cara
2008-04-21 17:25:18 UTC
Permalink
Fabrizio Conti (Panathos) wrote:
[cut]
Post by Fabrizio Conti (Panathos)
Gli array associativi esistono in qualche 'forma'? (chiedo perché ne
parlo dal primo messaggio, e se esistono non me l'avete ancora detto)
collection
--
ac
y-1=x
Fabrizio Conti (Panathos)
2008-04-22 14:25:13 UTC
Permalink
[cut]> Gli array associativi esistono in qualche 'forma'? (chiedo perché ne
Post by Fabrizio Conti (Panathos)
parlo dal primo messaggio, e se esistono non me l'avete ancora detto)
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
Simone Calligaris
2008-04-22 17:10:00 UTC
Permalink
"Fabrizio Conti (Panathos)"
Post by Simone Calligaris
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).
Nel caso di MSgraph, non so se sia un bug ma MS dichiara che non è
downgradabile.


Risposta:

Che vuol dire non è downgradabile?
Post by Simone Calligaris
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ì?
;-)
Oddio, il mio discorso era un po' diverso, ho citato i problemi di
librerie ma l'assunto iniziale era "struttura linguaggio <> oggetti".
Per il resto effettivamente cerco di usare meno OCX possibile (e l'ho
anche già scritto che per FTP e email uso Curl e Blat).


Risposta:

E le risposte (tante, troppe ;-)) nel Thread andavano in questo senso:

"E' lapalissiano che linguaggio <> oggetti, tuttavia all'atto pratico non ha
senso enumerare le keywords di VBA e non considerare quelle esposte dalle
librerie di Access"

Quello che importa a uno sviluppatore che utilizza Access è aver disponibile
un "mezzo" per ottenere il risultato: che sia esposto da MsAccess.OLB,
Mso.Dll piuttosto che da VbaXXX.Dll non fa alcuna differenza.
Post by Simone Calligaris
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)
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.
Fabrizio Conti (Panathos)
2008-04-22 18:50:49 UTC
Permalink
Post by Fabrizio Conti (Panathos)
Nel caso di MSgraph, non so se sia un bug ma MS dichiara che non è
downgradabile.
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).
Post by Fabrizio Conti (Panathos)
"E' lapalissiano che linguaggio <> oggetti, tuttavia all'atto pratico non ha
senso enumerare le keywords di VBA e non considerare quelle esposte dalle
librerie di Access"
Non mi convincerai mai :-) Un oggetto posso istanziarmelo ed usarne i
metodi da VBA 'liscio'; e magari pure aggiornarlo. Viceversa il
linguaggio quello è e quello più o meno rimane. Comunque visto che non
lo avete ancora fatto voi, mi ci mando io affanMicrosoftScript,
istanziarlo, usarlo e se ho ancora qualcosa da ridire su VBA aprire
thread a Redmond.
Post by Fabrizio Conti (Panathos)
Quello che importa a uno sviluppatore che utilizza Access è aver disponibile
un "mezzo" per ottenere il risultato: che sia esposto da MsAccess.OLB,
Mso.Dll piuttosto che da VbaXXX.Dll non fa alcuna differenza.
Ao', io penso a matrici e non ho la testa da VBA. Del resto anni fa
usavo Perl e lo trovato commestibile come la coda di iguana; che ci
devo fare.
Post by Fabrizio Conti (Panathos)
Fabrizio, insisti su sta cosa di "matrici" associative o meno: ma in Access
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
Simone Calligaris
2008-04-22 19:06:37 UTC
Permalink
"Fabrizio Conti (Panathos)"
Post by Simone Calligaris
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.
Oscar Manfredini
2008-04-17 16:08:13 UTC
Permalink
"Fabrizio Conti (Panathos)"

(cut)
Post by Simone Calligaris
Mhmmmmmmm ;-)
Vabbè, ma a chi può interessare che oggetti proprietà e metodi vengano
esposti da VBA332.Dll piuttosto invece che da MsAccess.OLB, Graph.OLB, DAO,
ADO o MsO.DLL?
Innanzitutto al programmatore, perché se sulla macchina di produzione
non ci sono le librerie che stanno sulla sua, sono guai. Poi al
sistemista, che dovrà provvedere affinché giri tutto correttamente.
Terzo, al titolare di quella macchina, che dovrà eventualmente
sborsare la cifra necessaria a procurarsele :-) Il che può chiamare in
causa il fornitore software, financo a quello hardware.
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!
Fabrizio Conti (Panathos)
2008-04-18 00:49:46 UTC
Permalink
Post by Fabrizio Conti (Panathos)
Innanzitutto al programmatore, perché se sulla macchina di produzione
non ci sono le librerie che stanno sulla sua, sono guai. Poi al
sistemista, che dovrà provvedere affinché giri tutto correttamente.
Beh, Fabrizio,  ti stai un tantino arrampicando sui vetri: dai ammettilo.
No no, sto parlando di situazioni che mi sono vissuto, ho appena
scritto un chilometro di post a Simone Callegaris in cui ne ho
parlato.
Post by Fabrizio Conti (Panathos)
Saresti nel giusto se si parlasse di ActiveX o altro, ma le suddette
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.

Può darsi che non fosse vero, ma la kb Microsoft così diceva, e
difatti alla fine ho fatto convivere due versioni diverse di Office
(2003 e 97), quell'ocx alla fine è rimasto al suo posto ed ero
contento che almeno funzionassero le applicazioni.
Post by Fabrizio Conti (Panathos)
I problemi teorici che hai sollevato non si applicano assolutamente a questo
prodotto. O alle installazioni Runtime, in totale esenzione da royaltees.
Avrei qualche dubbio, motivato da un CD che, installatosi
correttamente, dava errore quando lanciato. Poi l'ho accantonato in
quanto i contenuti erano fruibili senza runtime.
Post by Fabrizio Conti (Panathos)
Del resto, metti nel cestino MsAccess.Olb o Mso97.dll ... che succede?
Che è tardissimo. Buona notte :-)

ciao,
Panathos
Oscar Manfredini
2008-04-18 08:34:04 UTC
Permalink
"Fabrizio Conti (Panathos)"
Post by Oscar Manfredini
Saresti nel giusto se si parlasse di ActiveX o altro, ma le suddette
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 ;-)
Fabrizio Conti (Panathos)
2008-04-21 10:43:52 UTC
Permalink
Ascolta Fabrizio, � inutile scrivere km di post per cose evidenti e fuori
discussione.
(scusa, già che ci siamo: puoi dirmi che carattere vedi nella frase
quotata qui sopra, al posto della "è" accentata? Grazie..)

Come vuoi. Se partiamo dalle "cose evidenti e fuori discussione",
allora è ovvio che non c'è discussione.
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".
Non c'è problema. Ti faccio solo notare che se fosse una realtà così
indiscutibile e incontrovertibile, tu stesso non avresti usato "de
facto" tra virgolette.
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.
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
Oscar Manfredini
2008-04-21 11:09:16 UTC
Permalink
"Fabrizio Conti (Panathos)"
Post by Oscar Manfredini
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.
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.
Eeehh Fabrizio, continui a glissare parlando d'altro.
Come s'è detto più volte in questo Thread: la separazione teorica tra
linguaggio VBA e oggetti instanziati dalle librerie di base non ha riscontri
concreti: è solo accademia.
E' inutile ripetere cose già scritte e argomentate. O forse conosci
installazioni di Access97 prive di MsAccess.OLB e/o Mso97.DLL? In tal caso
facci sapere!



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.
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
Fabrizio Conti (Panathos)
2008-04-21 16:47:58 UTC
Permalink
Post by Fabrizio Conti (Panathos)
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.
Eeehh Fabrizio, continui a glissare parlando d'altro.
Grrrr.... so benissimo di cosa stavo parlando, ho iniziato io tutto il
discorso proprio partendo da quella premessa, e specificandola bene!
Post by Fabrizio Conti (Panathos)
Come s'è detto più volte in questo Thread: la separazione teorica tra
linguaggio VBA e oggetti instanziati dalle librerie di base non ha riscontri
concreti: è solo accademia.
D'accordo, è solo accademia. Fatto sta che se ho la DLL necessaria
posso istanziarmi un oggetto per i cavoli miei ed usarlo, viceversa
spiegami come implementare una "continue", o "break", o hash, o sort()
(tanto per ribadire esempi concreti che sono stati glissati :-)) i
quali SONO elementi costitutivi del linguaggio e NON VEDO come
implementare ricorrendo ad oggetti esterni.

Per CERTE COSE si può rimediare istanziando Microsoft Script, e quindi
istanzi un oggetto esterno. Ma la struttura del linguaggio quella è e
quella rimane.
Post by Fabrizio Conti (Panathos)
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.
Come ti scrive Simone, sarebbe interessante capire per quale ragione tu
utilizzi sovente strutture che in Access non servono praticamente mai.
E possiamo sviscerarlo finché vuoi, ma non smentisce quello che ho
scritto, e il fatto che "si possa fare a meno" di determinate
strutture non significa che al linguaggio non manchino, sic et
simpliciter.
Scusa ma leggere fra le righe che dovrei ammettere di "avere
sbagliato" quando distinguo le cose, o che "glisso" su un argomento
quando non faccio altro che sviscerare e portare esempi concreti, mi
fa dubitare della buona fede di chi mi scrive.
Post by Fabrizio Conti (Panathos)
Il tuo errore consiste nel voler negare l'evidenza.
Ma ti sembra???
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"?
Post by Fabrizio Conti (Panathos)
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).
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
Oscar Manfredini
2008-04-21 18:37:57 UTC
Permalink
"Fabrizio Conti (Panathos)" <
Post by Oscar Manfredini
Come s'è detto più volte in questo Thread: la separazione teorica tra
linguaggio VBA e oggetti instanziati dalle librerie di base non ha riscontri
concreti: è solo accademia.
D'accordo, è solo accademia. Fatto sta che se ho la DLL necessaria
posso istanziarmi un oggetto per i cavoli miei ed usarlo, viceversa
spiegami come implementare una "continue", o "break", o hash, o sort()
(tanto per ribadire esempi concreti che sono stati glissati :-)) i
quali SONO elementi costitutivi del linguaggio e NON VEDO come
implementare ricorrendo ad oggetti esterni.


----------------------------------------------------------------------------
------

Ma quando mai può servire stà roba in un FE sviluppato in Access?
Se utilizzi un prodotto, abituati alla filosofia di quel prodotto.

----------------------------------------------------------------------------
-------
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
Fabrizio Conti (Panathos)
2008-04-22 14:27:07 UTC
Permalink
Post by Fabrizio Conti (Panathos)
D'accordo, è solo accademia. Fatto sta che se ho la DLL necessaria
posso istanziarmi un oggetto per i cavoli miei ed usarlo, viceversa
spiegami come implementare una "continue", o "break", o hash, o sort()
(tanto per ribadire esempi concreti che sono stati glissati :-)) i
Ma quando mai può servire stà roba in un FE sviluppato in Access?
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
Oscar Manfredini
2008-04-23 17:55:52 UTC
Permalink
"Fabrizio Conti (Panathos)"
Post by Oscar Manfredini
Ma quando mai può servire stà roba in un FE sviluppato in Access?
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.

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
Fabrizio Conti (Panathos)
2008-04-24 11:55:52 UTC
Permalink
Post by Fabrizio Conti (Panathos)
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.
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
Oscar Manfredini
2008-04-24 16:17:28 UTC
Permalink
"Fabrizio Conti (Panathos)" <
Post by Oscar Manfredini
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.
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à...
Fabrizio Conti (Panathos)
2008-04-24 20:57:49 UTC
Permalink
Post by Oscar Manfredini
Sfottirorio?
Ma queste sono quisquillie rispetto ai flames che si sono visti da queste
parti.
Vabbè ma anche attaccarsi agli errori di ortografia, dai... i flame
bisogna farli bene, sennò non sono divertenti.
Post by Oscar Manfredini
Ormai pare di stare in politica: tutti preoccupati del politicamente
corretto. Mah.
Questa mi ha fatto riflettere e anche ridere :-)
Post by Oscar Manfredini
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à...
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
Oscar Manfredini
2008-04-25 07:03:19 UTC
Permalink
"Fabrizio Conti (Panathos)" <
Post by Oscar Manfredini
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à...
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.
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!
Alessandro Cara
2008-04-25 10:07:34 UTC
Permalink
Oscar Manfredini wrote:
[cut]
Post by Oscar Manfredini
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!
E' tornato Natale e nessuno me lo ha detto? ;<)
--
ac
y-1=x
Alessandro Baraldi
2008-04-25 10:54:34 UTC
Permalink
Post by Simone Calligaris
"Fabrizio Conti (Panathos)" <
Post by Oscar Manfredini
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à...
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.
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!
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
Oscar Manfredini
2008-04-25 12:20:30 UTC
Permalink
"Alessandro Baraldi" <
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!
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
Alessandro Baraldi
2008-04-25 20:38:30 UTC
Permalink
[cut]
Post by Oscar Manfredini
Smanettone del tanto che vada?
Boh
Riporto tue testuali e fraintendibili parole...!
"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."

Chiaramente con un pò di volontà e malizia ci ho visto quello che ho
detto... !

Scherzavo ovviamente.
Post by Oscar Manfredini
Ciao: Oscar
Ciao
@Alex
Oscar Manfredini
2008-04-25 22:03:36 UTC
Permalink
"Alessandro Baraldi" <
Post by Oscar Manfredini
Smanettone del tanto che vada?
Boh
Riporto tue testuali e fraintendibili parole...!
Non proprio mie...
"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."

Chiaramente con un pò di volontà e malizia ci ho visto quello che ho
detto... !

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

Ciao: Oscar
Alessandro Baraldi
2008-04-26 07:35:47 UTC
Permalink
Post by eSQueL
"Alessandro Baraldi" <
Post by Oscar Manfredini
Smanettone del tanto che vada?
Boh
Riporto tue testuali e fraintendibili parole...!
Non proprio mie...
"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."
Chiaramente con un pò di volontà e malizia ci ho visto quello che ho
detto... !
Scherzavo ovviamente.
Il fatto è che non le ho scritte io le frasi che mi attribuisci: a quanti
caffè stiamo oggi?   :-)
Ciao: Oscar
Vuoi dire che ho sbagliato l'interpretazione del quoting....?

Bischeri... che non siete altro...!

Chiedo VENIA anche io allora... ;-)

@Alex

Fabrizio Conti (Panathos)
2008-04-25 16:09:08 UTC
Permalink
Post by Oscar Manfredini
non c'è cattiveria nelle risposte che ho dato. Qella dell'altro giorno,
riletta ora, appare stronza oltre le intenzioni del momento.
Chiedo venia.
Qua la mano :-)

ciao,
Panathos
Simone Calligaris
2008-04-16 08:32:21 UTC
Permalink
"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.
Fabrizio Conti (Panathos)
2008-04-16 09:54:45 UTC
Permalink
Post by Fabrizio Conti (Panathos)
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.
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
Simone Calligaris
2008-04-16 10:20:41 UTC
Permalink
"Fabrizio Conti (Panathos)" <
Post by Fabrizio Conti (Panathos)
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.
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.
Carlo Costarella
2008-04-23 18:31:20 UTC
Permalink
"pippo" <***@gmail.com> ha scritto nel messaggio news:b07913bf-9eb9-47b8-9bfe-***@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
Loading...