author: Carlo Costarella

text:
"Dino" <
verreng...@alice.it
> ha scritto nel messaggio
news:fbde37cb-de5a-4f79...@r28g2000vbp.googlegroups.com...

Che modo strano di scrivere codice...
Dovrebbe funzionare cosě:
If Me.tipo = "GRAFICA" Then
Me.fm_01_C_completa.visible = true
Me.fm_01_C_completa_RADIO.visible = false
ElseIf Me.tipo = "RADIO" Then
Me.fm_01_C_completa.visible = False
Me.fm_01_C_completa_RADIO.visible = True
end if
Ancora meglio:
If Me.tipo = "GRAFICA" Then
Forms![NomeMAscheraPrincipale]![fm_01_C_completa].Form.Visible = True
Forms![NomeMAscheraPrincipale]![fm_01_C_completa_RADIO].Form.Visible = False
ElseIf Me.tipo = "RADIO" Then
Forms![NomeMAscheraPrincipale]![fm_01_C_completa].Form.Visible = False
Forms![NomeMAscheraPrincipale]![fm_01_C_completa_RADIO].Form.Visible = True
End If
Ciao, Carlo


title: Problemi con scelta automatica di subform da codice

author: Dino

text:
On 5 Mar, 12:17, "Carlo Costarella" <
carlocoslib...@libero.it
> wrote:
> "Dino" <
verrengia.d...@alice.it
> ha scritto nel messaggionews:fbde37cb-de5a-4f79...@r28g2000vbp.googlegroups.com...
>
>
>
>
>
> > Ciao a tutti sono Dino.Avrei questa esigenza:
> > In una form vorrei far apparire a seconda della condizione che si
> > verifica una subform piuttosto dell'altra.
> > Nel corpo della form ho inserito entrambe le subform.
> > Poi sull'evento Open della form ho scritto il seguente codice (Riporto
> > di seguito i nomi reali delle form)
>
> > If Me.tipo = "GRAFICA" Then
> >
Me.Form.Name
 = "fm_01_C_completa"
> >    Me.Form.Visible = True
> >
Me.Form.Name
 = "fm_01_C_completa_RADIO"
> >    Me.Form.Visible = False
> > ElseIf Me.tipo = "RADIO" Then
> >
Me.Form.Name
 = "fm_01_C_completa_RADIO"
> >    Me.Form.Visible = True
> >
Me.Form.Name
 = "fm_01_C_completa"
> >    Me.Form.Visible = False
>
> > All'apertura della form vedo pero' entrambe le form.Dove ho
> > sbagliato???
> > Conoscete un metodo migliore???
> > Grazie in anticipo Dino
>
> Che modo strano di scrivere codice...
> Dovrebbe funzionare così:
> If Me.tipo = "GRAFICA" Then
> Me.fm_01_C_completa.visible = true
> Me.fm_01_C_completa_RADIO.visible = false
> ElseIf Me.tipo = "RADIO" Then
> Me.fm_01_C_completa.visible = False
> Me.fm_01_C_completa_RADIO.visible = True
> end if
> Ancora meglio:
> If Me.tipo = "GRAFICA" Then
> Forms![NomeMAscheraPrincipale]![fm_01_C_completa].Form.Visible = True
> Forms![NomeMAscheraPrincipale]![fm_01_C_completa_RADIO].Form.Visible = False
> ElseIf Me.tipo = "RADIO" Then
> Forms![NomeMAscheraPrincipale]![fm_01_C_completa].Form.Visible = False
> Forms![NomeMAscheraPrincipale]![fm_01_C_completa_RADIO].Form.Visible = True
> End If
>
> Ciao, Carlo- Nascondi testo citato
>
> - Mostra testo citato -
Ciao Carlo grazie per la risposta.Ho provato con entrambe le
soluzioni,ma le subform le vedo entrambe.Da cosa puo' dipendere???
Grazie ancora
Dino


text:
"Dino" <
verreng...@alice.it
> ha scritto
cut
Ciao Carlo grazie per la risposta.Ho provato con entrambe le
soluzioni,ma le subform le vedo entrambe.Da cosa puo' dipendere???
Grazie ancora
Dino
Prova a seguire il codice passo passo e poi, dove metti il codice che hai
scritto?
Ciao, Carlo


author: Alessandro Cara

text:
Dino ha scritto:
[cut]
> Ciao Carlo grazie per la risposta.Ho provato con entrambe le
> soluzioni,ma le subform le vedo entrambe.Da cosa puo' dipendere???
> Grazie ancora
> Dino
Per me le due maschere partono con "Visible" e il me.tipo non contiene i
valori testati.
Comunque, dino, se impari a usare il debug queste cose le vedi subito
--
ac


text:

Grazie a tutti.Provo e vi faccio sapere
Dino


text:

OK trovata la problematica.Tutti i metodi vanno bene.Il prob. era a
monte.Nell'istruzione IF la condizione Me,Tipo = "grafica" andava
sostituita con Me.Testo288= "grafica" .
Probabilmente sto' invecchiando.
Grazie ancora per i vostri consigli
Dino


title: Aiuto su valori di default generati da data corrente

author: Carmix

text:
Come č possibile inserire quali valori di default di due controlli in una
form, in una il mese (possibilmente per esteso es. Gennaio) e nell'altra
l'anno corrente?
Grazie per l'aiuto
Carmix
--
Una volta ho bevuto un amaro cosě schifoso che anche sull'etichetta c'era un
frate che vomitava...


author: Silvio Berruti

text:
"Carmix" <
kette...@hotmail.com
> ha scritto nel messaggio
news:hXJk7.19949$MO.7...@news.infostrada.it...
> Come è possibile inserire quali valori di default di due controlli in una
> form, in una il mese (possibilmente per esteso es. Gennaio) e nell'altra
> l'anno corrente?
Prova rispettivamente con:
=format(date();"mm")
=format(date();"aaaa")
--
Silvio
il sito comune di it.comp.appl.access:
http://www.sitocomune.com


text:
"Silvio Berruti" <
sber...@libero.it
> ha scritto nel messaggio
news:L3Kk7.20002$MO.7...@news.infostrada.it...
>
> "Carmix" <
kette...@hotmail.com
> ha scritto nel messaggio
> news:hXJk7.19949$MO.7...@news.infostrada.it...
> > Come è possibile inserire quali valori di default di due controlli in
una
> > form, in una il mese (possibilmente per esteso es. Gennaio) e nell'altra
> > l'anno corrente?
>
> Prova rispettivamente con:
> =format(date();"mm")
Scusa x il nome esteso del mese usa
=format(date();"mmmm")



text:
"Silvio Berruti" <
sber...@libero.it
> ha scritto nel messaggio
news:g5Kk7.20011$MO.7...@news.infostrada.it...
> Scusa x il nome esteso del mese usa
> =format(date();"mmmm")
>
Grazie, funziona alla grande! L'unico limite è che non mi dà l'iniziale del
mese maiuscola, ma posso passarci sopra :))
Di nuovo grazie
Carmix


author: CarloCos

text:
"Carmix" <
kette...@hotmail.com
> ha scritto nel messaggio
news:EUKk7.20326$MO.7...@news.infostrada.it...

Una strada:
UCase(Left(Format(Date, "mmmm"), 1)) & Mid(Format(Date, "mmmm"), 2, 15)


author: Karl Donaubauer

text:
"CarloCos" ha scritto:
> "Carmix" <
kette...@hotmail.com
> ha scritto:
> > "Silvio Berruti" <
sber...@libero.it
> ha scritto:
> > > Scusa x il nome esteso del mese usa
> > > =format(date();"mmmm")
> > >
> > Grazie, funziona alla grande! L'unico limite è che non mi dà l'iniziale
> > del mese maiuscola, ma posso passarci sopra :))
>
> Una strada:
> UCase(Left(Format(Date, "mmmm"), 1)) & Mid(Format(Date, "mmmm"), 2, 15)
Un vicolo ;-):
=StrConv(Format(Date();"mmmm");3)
--
HTH
Karl
*********
Access-FAQ (tedesco):
http://www.donkarl.com


title: macro per automatizzare la casella combinata

author: Franco

text:
qual è il comando in una macro che da casella combinata
mi può accodare una lunga sequenza di records (in sottomascherà)?
Grazie


text:
"Franco" <
Franco.D...@libero.it
> ha scritto nel messaggio
news:4f8299f0$0$1390$4faf...@reader2.news.tin.it...
> qual è il comando in una macro che da casella combinata
> mi può accodare una lunga sequenza di records (in sottomascherà)?
> Grazie
>
come  fare per selezionare il pulsantino della casella combinata da codice?

Grazie


text:
"Franco" <
Franco.D...@libero.it
> ha scritto nel messaggio
news:4f8560a3$0$1384$4faf...@reader2.news.tin.it...

meglio
come fare a selezionare il controllo della combo da codice


author: Fabrizio Alessandri

text:

Non ho Access sotto mano, ma dovrebbe essere Me.MioControllo.SetFocus
.


text:
cut
> >>
> > come  fare per selezionare il pulsantino della casella combinata da
> > codice?
> >
> > Grazie
> meglio
> come fare a selezionare il controllo della combo da codice

>Non ho Access sotto mano, ma dovrebbe essere Me.MioControllo.SetFocus

grazie
ma io cerco il codice per l'inserimento proprio materiale
dei vari records, come se selezionassi il controllo della combobox.
con il puntatore del mouse.
Da pulsante ho inserito questo codice da completare:

    Forms![Fatture3].SetFocus
    Forms![Fatture3]![Dettaglio Fatture Sottomaschera].SetFocus
    DoCmd.GoToControl "IDfatturafornitore"
    DoCmd.GoToRecord , , acNewRec

ecc. ecc.

grazie per l'aiuto

.


author: tommaso

text:

http://www.donkarl.com/it/?FAQ4.14

Ciao
Tommaso


text:
"tommaso" <
tommaso...@gmail.com
> ha scritto nel messaggio
news:8797215.484.1334260724591.JavaMail.geo-discussion-forums@ynbr30...

grazie Tommaso
è proprio quello che cercavo

e per far  ripetere l'operazione ad esaurimento dei records?


text:
cur
>
http://www.donkarl.com/it/?FAQ4.14

>
> grazie Tommaso
> è proprio quello che cercavo
>
> e per far  ripetere l'operazione ad esaurimento dei records?
su click di un pulsante
vorrei simulare l'inserimento dei records da una casella combinata
ad una sottomaschera

chiedo aiuto per completare questo codice

 DoCmd.GoToControl "cbo_fatturafornitore"
    DoCmd.GoToRecord , , acNewRec
    Forms![Fatture3]![Dettaglio Fatture
Sottomaschera]!IDfatturafornitore.Dropdown

vorrei che il Dropdown della combo non sia visibile
cioè che avvenga il passaggio dei records senza
il Dropdown  del menu della combo

Grazie


title: numero serie hard disk

author: Pasquale Antonacci

text:
Vorrei sapere come fare per associare la funzione da te sviluppata con una casella di testo per avere il numero di serie dell'hard-disk.
Grazie!!!
--
Posted from
sirio.tno.it
 [138.66.200.5]
via Mailgate.ORG Server -
http://www.Mailgate.ORG


title: guide Access

author: mas

text:
Ho cercato invano in internet guide manuali tutorial su Access. Potreste
indicarmi qualche indirizzo dal quale scaricarli, possibilmente in italiano
e in un formato facilmente stampabile.
Grazie
maS


title: guide Access

author: lbo dal portatile

text:
>Ho cercato invano in internet guide manuali tutorial su Access. Potreste
>indicarmi qualche indirizzo dal quale scaricarli, possibilmente in italiano
>e in un formato facilmente stampabile.
non per disistimare il lavoro di chi realizza di queste guide, ma in
libreria si trovano ottimi libri a partire da 30-40mila.  che ti hanno
fatto di male?
--
il sito comune di it.comp.appl.access:
http://members.xoom.it/it_db_access/


title: guide Access

author: Carlo Ve

text:
lbo dal portatile ha scritto nel messaggio
<
38c3f6a2...@news.interbusiness.it
>...
>>Ho cercato invano in internet guide manuali tutorial su Access. Potreste
>>indicarmi qualche indirizzo dal quale scaricarli, possibilmente in
italiano
>>e in un formato facilmente stampabile.
>
>non per disistimare il lavoro di chi realizza di queste guide, ma in
>libreria si trovano ottimi libri a partire da 30-40mila.  che ti hanno
>fatto di male?
Be, credo che  rispetto al contenuto dei libri da 30/40mila  di oggi forse
conviene cercare qualcosa su internet,  diverso magari se qualcuno vuole
approfondire seriamente il discorso e allora non c'e' corso internet che
tenga e le 30/40 mila bisogna moltiplicarle per avere un buon libro.
A  meno che uno non si metta a raccogliere selezionare e studiare tutti i
msg di questa ml, e credo che
alla fine potrebbe saltare fuori l'equivalente di un buon libro
o no?
Carlo Ve


title: guide Access

text:
>>non per disistimare il lavoro di chi realizza di queste guide, ma in
>>libreria si trovano ottimi libri a partire da 30-40mila.  che ti hanno
>>fatto di male?
>
>Be, credo che  rispetto al contenuto dei libri da 30/40mila  di oggi forse
>conviene cercare qualcosa su internet,  diverso magari se qualcuno vuole
scusa, ma in che senso conviene?  a me pare soltanto che ci sia gente
(e non e' la prima voilta che lo dico) che considera internet una
specie di pozzo senza fondo da cui sia possibile estrarre di tutto.
sara' anche vero, ma questo ingenera dei comportamenti
menefreghistici.  voglio dire, scaricare guide da internet, ma fare un
salto in liberia no?  quanto glie ne puo' fregare di imparare ad usare
access ad uno che si aspetta che le cose gli cadano dal cielo?  con
che spirito si avvicina ad imparare access?  cosa credono, che basta
scaricare un file e si impara access?
e non lo dico per access in se', del quale me ne frega poco, ma lo
dico per un discorso piu' generale.  imparare qualcosa non e' mettersi
una supposta scaricata da internet e aspettare che faccia effetto.  e'
anche sbattersi un po', anche comprarsi meno figurine e sigarette e un
libro in piu', e magari perdere il tempo di leggerlo.  senno' si
ripetono le cose a pappagallo, e la cosa mi fa molto rodere il culo,
perche' vedo che l'ambiente informatico e' composto in buona parte da
copiaincollatori che non capiscono un cazzo di quello che fanno e
vengono giustamente tenuti all'ultimo gradino della considerazione.



title: guide Access

text:
lbo dal portatile ha scritto nel messaggio
<
38c63a9...@news.interbusiness.it
>...
>>>non per disistimare il lavoro di chi realizza di queste guide, ma in
>>>libreria si trovano ottimi libri a partire da 30-40mila.  che ti hanno
>>>fatto di male?
>>
>>Be, credo che  rispetto al contenuto dei libri da 30/40mila  di oggi forse
>>conviene cercare qualcosa su internet,  diverso magari se qualcuno vuole
>
>scusa, ma in che senso conviene?  a me pare soltanto che ci sia gente
>(e non e' la prima voilta che lo dico) che considera internet una
>specie di pozzo senza fondo da cui sia possibile estrarre di tutto.
>
>sara' anche vero, ma questo ingenera dei comportamenti
>menefreghistici.  voglio dire, scaricare guide da internet, ma fare un
>salto in liberia no?  quanto glie ne puo' fregare di imparare ad usare
>access ad uno che si aspetta che le cose gli cadano dal cielo?  con
Guarda che condivido
io appartengo alla categoria di quelli che quando ha pensato che era bene
imparare ad usare access
hanno dovuto arrangiarsi,  dato che  internet era ancora
fantascienza, e nessuno era in grado di spiegarmi qualche cosa salvo
costosissimi corsi che non
potevo permettermi. L'unico modo per impararlo era quello di arrangiarsi
magari  girando nelle librerie a sfogliare qua e la e "rubacchiando" dai
vari libri
e a volte comprandone qualcuno, (continuo a farlo)
Resto sempre dell'idea  che per incominciare piuttosto che spendere le 30/40
mila per un bignami  o un libro di 40 pagine che ti dice poco o nulla e dopo
averlo letto una volta lo puoi buttare via, conviene inizialmente cercarsi
qualcosa di base anche su internet e magari iniziare a smanettare un po',
dodopoche' volendo approfondire seriamente ti compri qualche buon libro
chiaramente integrando le 30/40 mila.
Spero che qualcuno non creda di poter diventare un buon programmatore
solamente cercando i corsi o tutorial su internet o database aperti da
copiaincollare,
anche se sono sono dell'idea che da questo ng si possa ricavare parecchio
materiale da studio
che non sempre trovi nei libri.
Carlo Ve


title: programmazione ad oggetti e classi

author: pippo

text:
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


title: programmazione ad oggetti e classi

author: eSQueL

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


title: programmazione ad oggetti e classi

author: Alessandro Baraldi

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


title: programmazione ad oggetti e classi

text:
"Alessandro Baraldi" <
ik2...@libero.it
> ha scritto nel messaggio
news:1829d4f4-264a-4063...@k37g2000hsf.googlegroups.com...
On 14 Apr, 13:12, "eSQueL" <
eSQ...@virgilio.it
> wrote:
> "pippo" <
sda...@gmail.com
> ha scritto nel
> messaggionews:b07913bf-9eb9-47b8...@d45g2000hsc.googlegroups.com...
> 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


title: programmazione ad oggetti e classi

author: Fabrizio Conti (Panathos)

text:
On 14 Apr, 13:27, Alessandro Baraldi <
ik2...@libero.it
> wrote:
> 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


title: programmazione ad oggetti e classi

text:
[cut]
> 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


title: programmazione ad oggetti e classi

text:
> 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


title: programmazione ad oggetti e classi

text:
"Alessandro Baraldi" <
ik2...@libero.it
> ha scritto nel messaggio
news:ed2ce170-12d9-4e66...@b64g2000hsa.googlegroups.com...
[cut]
Mi spiace che la prendi cosě male.


title: programmazione ad oggetti e classi

text:
On 14 Apr, 18:05, Alessandro Baraldi <
ik2...@libero.it
> wrote:
> 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à.
> 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


title: programmazione ad oggetti e classi

author: Oscar Manfredini

text:
"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


title: programmazione ad oggetti e classi

text:
> 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


title: programmazione ad oggetti e classi

text:
> 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


title: programmazione ad oggetti e classi

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


title: programmazione ad oggetti e classi

text:
On 15 Apr, 09:28, "eSQueL" <
eSQ...@virgilio.it
> wrote:
> "Alessandro Baraldi" <
ik2...@libero.it
> ha scritto nel messaggionews:4f7d2823-b567-4ac9...@y21g2000hsf.googlegroups.com...
>
> > 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


title: programmazione ad oggetti e classi

text:
"Alessandro Baraldi" <
ik2...@libero.it
> ha scritto nel messaggio
news:0e6b8200-4e6a-41c7...@l64g2000hse.googlegroups.com...
On 15 Apr, 09:28, "eSQueL" <
eSQ...@virgilio.it
> wrote:
> "Alessandro Baraldi" <
ik2...@libero.it
> ha scritto nel
> messaggionews:4f7d2823-b567-4ac9...@y21g2000hsf.googlegroups.com...
>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
>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


title: programmazione ad oggetti e classi

text:
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


title: programmazione ad oggetti e classi

text:
On 15 Apr, 08:14, Alessandro Baraldi <
ik2...@libero.it
> wrote:
> 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.
> 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.
> 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


title: programmazione ad oggetti e classi

text:
On 14 Apr, 20:15, "Oscar Manfredini" <
oscar.manfred...@libero.it
>
wrote:
> "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


title: programmazione ad oggetti e classi

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


title: programmazione ad oggetti e classi

text:
"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


title: programmazione ad oggetti e classi

text:
> 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


title: programmazione ad oggetti e classi

text:
On 15 Apr, 14:31, "Oscar Manfredini" <
oscar.manfred...@libero.it
>
wrote:
> 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.
> 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.
> 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.
> 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
> 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.
Complimenti all'autore; ma a dirti la verità, della grafica me ne
importa relativamente poco.
ciao,
Panathos


title: programmazione ad oggetti e classi

text:
"Fabrizio Conti (Panathos)"
> 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...
----------------------------------------------------------------------------
-
> 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


title: programmazione ad oggetti e classi

author: Simone Calligaris

text:
"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.


title: programmazione ad oggetti e classi

text:
On 16 Apr, 09:14, "Oscar Manfredini" <
oscar.manfred...@libero.it
>
wrote:
> '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


title: programmazione ad oggetti e classi

text:
"Fabrizio Conti (Panathos)"
> '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.


title: programmazione ad oggetti e classi

text:
On 16 Apr, 10:32, "Simone Calligaris" <
simoc...@libero.it
> wrote:
> 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() ?
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


title: programmazione ad oggetti e classi

text:
"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.
>
> Risposta:
>
> 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.


title: programmazione ad oggetti e classi

text:
On 16 Apr, 11:49, "Simone Calligaris" <
simoc...@libero.it
> wrote:
> Scusa l'intromissione, ma fai capire qual è il punto...
Figurati, essendo ng pubblico più che intromissione è partecipazione.
> 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.
> Se il tuo grande problema è verificare la presenza di un file su disco lo
> puoi fare con una sola istruzione:
Altra tua travisazione: non ho scritto che il mio problema fosse
quello.
> 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.
> 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


title: programmazione ad oggetti e classi

text:
"Fabrizio Conti (Panathos)"
> 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.








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


title: programmazione ad oggetti e classi

text:
On 16 Apr, 15:20, "Simone Calligaris" <
simoc...@libero.it
> wrote:
> 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).
> 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.
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.
> 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
[...]
Ok grazie, se aggiungi l'oggetto FileSearch ottieni quelle funzioni...
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).
> 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.
> 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


title: programmazione ad oggetti e classi

text:
> "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.
> 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
[...]
<Ok grazie, se aggiungi l'oggetto FileSearch ottieni quelle funzioni...<
>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.
> 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.
> 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


title: programmazione ad oggetti e classi

text:
On 17 Apr, 09:46, "Simone Calligaris" <
simoc...@libero.it
> wrote:
> >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().
> >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.
> 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.
> 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? :-)
> 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


title: programmazione ad oggetti e classi

text:
"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?
------------------------------------------------------------------------------------------------------
> >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  ;-)
------------------------------------------------------------------------------------------------
> 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?
------------------------------------------------------------------------------------------------
> 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.
-----------------------------------------------------------------------------------
> 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


title: programmazione ad oggetti e classi

text:
"Fabrizio Conti (Panathos)"
(cut)
> 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!


title: programmazione ad oggetti e classi

text:
On 17 Apr, 17:24, "Simone Calligaris" <
simoc...@libero.it
> wrote:
> "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.
> 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.
[...]
> 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).
> 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.
[...]
> 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.
> 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à.
> 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.
> 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.
> 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.
> 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.
> 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'.
> 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 :-)
> 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.
> 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.
> 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).
> 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.
> 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


title: programmazione ad oggetti e classi

text:
On 17 Apr, 18:08, "Oscar Manfredini" <
oscar.manfred...@libero.it
>
wrote:
> 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.
> 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.
> 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.
> Del resto, metti nel cestino MsAccess.Olb o Mso97.dll ... che succede?
Che è tardissimo. Buona notte :-)
ciao,
Panathos


title: programmazione ad oggetti e classi

text:
"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.
----------------------------------------------------------------------------
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   ;-)


title: programmazione ad oggetti e classi

text:
"Fabrizio Conti (Panathos)"
(cut)
> 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


title: programmazione ad oggetti e classi

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


title: programmazione ad oggetti e classi

text:
On 18 Apr, 10:34, "Oscar Manfredini" <
oscar.manfred...@libero.it
>
wrote:
> 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


title: programmazione ad oggetti e classi

text:
"Fabrizio Conti (Panathos)"
> 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


title: programmazione ad oggetti e classi

text:
On 21 Apr, 13:09, "Oscar Manfredini" <
oscar.manfred...@libero.it
>
wrote:
> 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!
> 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.
> 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.
> Il tuo errore consiste nel voler negare l'evidenza.
Ma ti sembra???
> Se tu non hai usato FileSearch (ad. ex) è perchè non lo conoscevi:
Questa è bella: siete stati tu e Simone a citare FileSearch, in
risposta ad un accenno di esempio di carenze di linguaggio ("ricerca
in un directory tree in base ad espressioni regolari"). Avete fatto
presente che l'oggetto esiste, e va bene, ma il punto del discorso ERA
IL LINGUAGGIO. Ora mi accusi di negare una "evidenza" perché secondo
te non conoscevo FileSearch.
E' dall'inizio del thread che specifico di separare linguaggio ed
oggetti, ho fatto esempi coerenti con questa premessa. Come fai a dire
che "glisso", "non ammetto", "nego l'evidenza"?
> 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


title: programmazione ad oggetti e classi

text:
On 19 Apr, 10:19, "Simone Calligaris" <
simoc...@libero.it
> wrote:
> 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ù :-)
> Componenti MS Graph  (forse, dico forse, non installate di Default col 97,
> ma non posso ricordare)
Sì ci sono anche questi.
> 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.
> 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).
> 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)
> 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


title: programmazione ad oggetti e classi

author: Alessandro Cara

text:
Fabrizio Conti (Panathos) wrote:
[cut]
> 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


title: programmazione ad oggetti e classi

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


title: programmazione ad oggetti e classi

text:
On 21 Apr, 19:25, Alessandro Cara <
alessandro.c...@ay-1asistemi.it
>
wrote:
> [cut]> Gli array associativi esistono in qualche 'forma'? (chiedo perché ne
> > 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


title: programmazione ad oggetti e classi

text:
On 21 Apr, 20:37, "Oscar Manfredini" <
oscar.manfred...@libero.it
>
wrote:
> 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


title: programmazione ad oggetti e classi

text:
"Fabrizio Conti (Panathos)"
> 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?
> 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.
> 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.


title: programmazione ad oggetti e classi

text:
On 22 Apr, 19:10, "Simone Calligaris" <
simoc...@libero.it
> wrote:
> Nel caso di MSgraph, non so se sia un bug ma MS dichiara che non è
> downgradabile.
>
> Risposta:
>
> 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).
> 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"
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.
> 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.
> 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


title: programmazione ad oggetti e classi

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