Lettura file XLS

[colde]

Ciao a tutti,
devo poter leggere la prima colonna di un file xls, associare un dato
per ogni campo e salvarlo in un file txt.
Il file xls viene già letto dall'applicazione tramite ADOQuery ma qui
avrei un problema per riuscire a capire quale cella è stata letta
l'ultima volta. La colonna che contiene i dati che mi servono sono la
prima, la colonna A; dato che il file non lo leggo interamente in
un'unica volta ma in più volte, devo avere una sorta di "segnalibro"
che mi indichi da dove ripartire con la lettura dei dati da xls.
E' possibile?


ADOQuery1.ConnectionString := 'Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=C:\Documents and
Settings\Colde\Desktop\WT_Ver_NODETECT\WT2006_Scarico dati
passivo_WT\DataImport\BIPPAGGIO.xls;Extended Properties=Excel 8.0;';
ADOQuery1.SQL.Text := 'select * from [FOGLIO1$]';
ADOQuery1.Open();
ShowMessage(ADOQuery1.Fields[0].Value);
ADOQuery1.Next;

In questo modo ogni volta che accede al file xls per la lettura riparte
sempre dal primo campo. Ho pensato di leggere tutti i dati da xls per
memorizzarli in un array ma non posso farlo perchè i campi da
memorizzare sono sempre oltre i 3000.

Come posso fare? GRAZIE

P.S.
ho provato ad installare i componenti della TurboPower (OfficePartner)
ma per una serie di errori che ho incontrato non sono riuscito a
terminare l'installazione.

[alberto salvati]

Ti salvi il numero dlel'ultima colonna processata in un file ini o similare.

A.

[colde]

il salvataggio del numero non � un problema, per quello va bene una
semplice variabile ma la stringa SQL come dovr� diventare? Cio�, come
posso dire tramite SQL, di partire con la lettura dei dati dal valore N
(che sar� il valore recuperato dalla variabile) della prima colonna?

Grazie

[Alberto Salvati]

il salvataggio del numero non è un problema, per quello va bene una
semplice variabile ma la stringa SQL come dovrà diventare?

xche dovrebbe cambiare?

Cioè, come
posso dire tramite SQL, di partire con la lettura dei dati dal valore N
(che sarà il valore recuperato dalla variabile) della prima colonna?

mi sono perso. tu hai necessita' di ripartire dall'ultima COLONNA o
dall'ultima RIGA?
Inoltre, sicuro che non ti convenga usare OLE?

A.

[colde]

L'SQL dovrebbe cambiare per poter recuperare i dati successivi ai dati
già recuperati.
A me serve ripartire dall'ultima riga recuperata, non la colonna.
Cosa cambia tra OLE e ADO? Non li ho mai usati entrambi quindi (cioè
ADO è la prima volta che lo uso) non li conosco molto, non è da tanto
che uso delphi e fino ad ora non mi sono mai serviti.

Grazie ancora del supporto.

[Alberto Salvati]

Post by colde
A me serve ripartire dall'ultima riga recuperata, non la colonna.

Ah, ora la cosa è chiara.

Post by colde
Cosa cambia tra OLE e ADO?

Ado è per accedere ai dati su database, come bde (obsoleto),
dbexpress, ado.net etc.
OLE sta per Object Linking and Embedding.
In pratica, piloti excel (word, powerpoint, e non solo...) da delphi.
Se cerchi nei vecchi post trovi un bel po di info.
Fai dei cfr a livello di performance.
Cmq, secondo me, leggere 3000 righe o 1500 da un foglio excel via ado
non dovrebbe comportare grosse differenze di tempo.
Se prp lo vuioi fare ti suggerisco di cercare info relative all'sql
supportato da excel o dal relativo oledb provider.

A.

[Giuseppe Di Martino]

Post by colde
In questo modo ogni volta che accede al file xls per la lettura riparte
sempre dal primo campo. Ho pensato di leggere tutti i dati da xls per
memorizzarli in un array ma non posso farlo perchè i campi da
memorizzare sono sempre oltre i 3000.
Come posso fare? GRAZIE

Ciao,
non capisco perche' hai problemi a memorizzare oltre 3000 elementi in un
vettore.
Hai valutato l'idea di leggere, elaborare (associare il dato) e
scrivere sul file di testo "al volo", ossia in un unico ciclo ?

Giuseppe

[colde]

X Giuseppe:
si infatti ora è quello che faccio, apro xls e leggo il valore ogni
volta che mi serve. Il problema ora non si pone più.


Adesso ho un dubbio atroce:
dato che il software che sto sviluppando dovrà essere distribuito a
livello mondiale e ogni nazione ha la sua versione di Excell, come
faccio ad associargli il numero di foglio da dove deve recuperare i
dati? Mi spiego, all'interno della SQL io indico con [FOGLIO1$] il
foglio dove andare a reperire i dati ma questo con una versione
italiana. Se fosse in inglese ci sarebbe "Sheet1" e così via. Dato che
i dati devo prenderli in automatico, cosa posso scrivere nella SQL al
posto di [FOGLIO1$] in modo da renderlo standard a prescindere dalla
lingua con cui è tradotto excell? Esiste un modo che riconosca il
foglio1 in automatico senza dirglielo esplicitamente?
In alternativa, se proprio non dovesse esserci una soluzione, potrei
obbligare l'operatore che crea il file xls ad utilizzare un nome
standard in inglese.

Grazie

P.S.
il componente della TurboPower (OfficePartner) non centra niente con il
metodo OLE, vero?

[Alberto Salvati]

beato te che ne hai solo uno...

Post by colde
italiana. Se fosse in inglese ci sarebbe "Sheet1" e così via. Dato che
i dati devo prenderli in automatico, cosa posso scrivere nella SQL al
posto di [FOGLIO1$] in modo da renderlo standard a prescindere dalla
lingua con cui è tradotto excell? Esiste un modo che riconosca il
foglio1 in automatico senza dirglielo esplicitamente?

imho, non credo.
Con OLE dovresti essere indipendente dalla lingua.

Post by colde
In alternativa, se proprio non dovesse esserci una soluzione, potrei
obbligare l'operatore che crea il file xls ad utilizzare un nome
standard in inglese.

E come?
gli punti una pistola alla tempia?
Vai fino a Hong Kong a prendere a calci nel culo l'utOntO responsabile
di un misfatto del genere?

Post by colde
il componente della TurboPower (OfficePartner) non centra niente con il
metodo OLE, vero?

C'entra eccome. Di fatto è un wrapper per l' OLE automation di office.

SaluMi

A.

[colde]

Allora Alberto, se modifico il foglio di lavoro da "Foglio1" a "Prova1"
o "Sheet1", mi da errore dicendo che [FOGLIO1$] non è un nome valido.
Per intenderci, la SQL è questa:

select * from [FOGLIO1$] where Pectoral > 0


Quindi lui va a cercarmi esattamente il foglio di lavoro che ha quel
nome, se non c'è mi da errore. Vorrei evitare proprio questo, ovvero
vorrei far prelevare il primo foglio di lavoro disponibile in modo
automatico. E' possibile?
Non penso che dia errore perchè il foglio di lavoro è stato
modificato a mano, credo che se dovessi provare l'applicativo in
versione inglese, così com'è mi ritorna lo stesso errore. Spero di
sbagliarmi.


P.S.
L'idea di usare il package aggiuntivo della TurboPower mi ispirava
parecchio visto che mi sono già trovato bene con altri loro componenti
ma ho avuto dei problemi nell'installare il package e quando ho chiesto
aiuto qui sul NG ho avuto solo indicazioni parziali, ovvero nel momento
in cui ho postato gli errori dopo aver seguito indicazioni di un
utente, non mi è più stato detto niente e non trovando supporto al
mio problema sono dovuto passare ad altro. Ed eccomi qui.

[Alberto Salvati]

Post by colde
nome, se non c'è mi da errore. Vorrei evitare proprio questo, ovvero
vorrei far prelevare il primo foglio di lavoro disponibile in modo
automatico. E' possibile?

via ole si, xche scrivi qualcosa tipo
excelappliaction.workboooks.workbook[indice]
e quindi te ne fotti, del nome.

Post by colde
L'idea di usare il package aggiuntivo della TurboPower mi ispirava
parecchio visto che mi sono già trovato bene con altri loro componenti

Come ti ho detto OfficePartner è un wrapper.
Io non l'ho mai usato, andando direttamente via ole.
Se cerchi nei vecchi post trovi circa 60terabite di materiale legato a
come usare excel.

baiBai

A.

[Alberto Salvati]

Post by Giuseppe Di Martino
non capisco perche' hai problemi a memorizzare oltre 3000 elementi in un
vettore.

1) il concetto di vettore è + di programmazione STRUTTURATA che OO.
Al limite, una collection...

2) oggi sono 3000. E se domani diventano di piu'?

3) che senso ha metterli in memoria e poi salvare?
Se deve processare una riga per volta ogni 10 minuti, ad esempio, a che
serve caricare le altre righe su cui lui non fa un tubazzo?

A.

[Giuseppe Di Martino]

Post by Alberto Salvati

Post by Giuseppe Di Martino
non capisco perche' hai problemi a memorizzare oltre 3000 elementi in un
vettore.

1) il concetto di vettore è + di programmazione STRUTTURATA che OO.
Al limite, una collection...

Non capisco il senso di questa affermazione, è vietato usare la
programmazione strutturata ?
Io direi che se si tratta solo di tenere in memoria dei dati
"basta" un vettore; anzi, se la quantità di dati è notevole direi che è
"meglio" un vettore piuttosto che una classe/collection/etc.; se poi la
quantità diventa proibitiva per la memoria centrale è meglio
rivolgersi ai database o altro.

Post by Alberto Salvati
2) oggi sono 3000. E se domani diventano di piu'?

Io ho capito che erano 3000 o qualcosina di più, ma di certo non
1.000.000. Infatti la mia risposta era riferita al fatto che diceva di
avere problemi a memorizzare oltre 3000 elementi.

Post by Alberto Salvati
3) che senso ha metterli in memoria e poi salvare?
Se deve processare una riga per volta ogni 10 minuti, ad esempio, a che
serve caricare le altre righe su cui lui non fa un tubazzo?

Non so se hai letto tutto il messaggio, ma gli suggerivo anche l'idea di
non memorizzare nulla e con unico ciclo leggere il dato/elaborarlo/salvare
il risultato. Ma a volte possono esserci altre ragioni, ad esempio dover
sbloccare prima possibile il file .xls da cui leggere i dati, etc.

Giuseppe

[alberto salvati]

Post by Giuseppe Di Martino

Post by Alberto Salvati

Post by Giuseppe Di Martino
non capisco perche' hai problemi a memorizzare oltre 3000 elementi in un
vettore.

1) il concetto di vettore è + di programmazione STRUTTURATA che OO.
Al limite, una collection...

Non capisco il senso di questa affermazione, è vietato usare la
programmazione strutturata ?

imho, rigorosamente IHMO, i danni fatti da persone che hanno usato e
usano delphi in modo strutturato e non object oriented sono pesanti.
Una delle cose sulle quali impreco di + riguardo delphi e' prp il
supporto del doppio paradigma, che ha riempito il mondo di applicazioni
spesso (ma non sempre, ovvio) scritte MALE.
Se poi a te non è mai successo di mettere mano a cose sviluppate cosi,
ringrazia chi ti senti di dover ringraziare.
Detesto il fatto che nessuno dei libri su delphi che mi e' capitato tra
le mani metta al capitolo 1 la programmazione OO, che salvo dettagli di
implementazione specifici di alcuni linguaggi, la porti dove vuoi: java,
c++, c# delphi, etc.
Cmq, resta scontato il fatto che la differenza la fa la testa e non lo
strumento.

Post by Giuseppe Di Martino
Io direi che se si tratta solo di tenere in memoria dei dati
"basta" un vettore; anzi, se la quantità di dati è notevole direi che è
"meglio" un vettore piuttosto che una classe/collection/etc.;

perche'?

Post by Giuseppe Di Martino
se poi la
quantità diventa proibitiva per la memoria centrale è meglio
rivolgersi ai database o altro.

il db lo ha gia: i dati sono su excel.
non so se avrebbe senso introdurre un ulteriore storage per tale operazione.

Post by Giuseppe Di Martino

Post by Alberto Salvati
2) oggi sono 3000. E se domani diventano di piu'?

Io ho capito che erano 3000 o qualcosina di più, ma di certo non
1.000.000. Infatti la mia risposta era riferita al fatto che diceva di
avere problemi a memorizzare oltre 3000 elementi.

imho, meglio essere lungimiranti, cosa che molti non fanno, ovviamente
partendo sempre dal buon senso.
A me è successo di scrivere una cosa simile anni fa per 5000 elementi.
Il cliente ci avrebbe messo la mano sul fuoco che non sarebbero mai
diventati di piu'.
2 mesi dopo erano 250.000......

Post by Giuseppe Di Martino

Post by Alberto Salvati
3) che senso ha metterli in memoria e poi salvare?
Se deve processare una riga per volta ogni 10 minuti, ad esempio, a che
serve caricare le altre righe su cui lui non fa un tubazzo?

Non so se hai letto tutto il messaggio, ma gli suggerivo anche l'idea di
non memorizzare nulla e con unico ciclo leggere il dato/elaborarlo/salvare
il risultato. Ma a volte possono esserci altre ragioni, ad esempio dover
sbloccare prima possibile il file .xls da cui leggere i dati, etc.

io non ritengo una buona strategia impegnare tempo e risorse a caricare
una seuppur minima qnt di dati di cui all'utente non frega niente.
Mai visto che bei programmi che l'utente apre una form e senza poter
dire "no, grazie" gli si popola una dbgrid con 10000 righe?
E lui sta li ad aspettare.. e si inkazza, giustamente.


Senza polemica, eh?? :-))

A

[Giuseppe Di Martino]

Il Wed, 15 Nov 2006 07:59:58 +0100, alberto salvati ha scritto:

Premessa: tutto ciò che scrivo è assolutamente IHMO, dettato da circa 20
anni di sviluppo su vari tipi di sistemi e con svariati
strumenti di sviluppo ed, infine, non ha il benche' minimo tono polemico
verso il tuo modo di vedere le cose.

Post by alberto salvati
imho, rigorosamente IHMO, i danni fatti da persone che hanno usato e
usano delphi in modo strutturato e non object oriented sono pesanti.
Una delle cose sulle quali impreco di + riguardo delphi e' prp il
supporto del doppio paradigma, che ha riempito il mondo di applicazioni
spesso (ma non sempre, ovvio) scritte MALE.
Se poi a te non è mai successo di mettere mano a cose sviluppate cosi,
ringrazia chi ti senti di dover ringraziare.
Detesto il fatto che nessuno dei libri su delphi che mi e' capitato tra
le mani metta al capitolo 1 la programmazione OO, che salvo dettagli di
implementazione specifici di alcuni linguaggi, la porti dove vuoi: java,
c++, c# delphi, etc.
Cmq, resta scontato il fatto che la differenza la fa la testa e non lo
strumento.

Secondo me, quando un'applicazione è scritta male, lo è e basta.
Indipendentemente dal paradigma usato, dal linguaggio, etc.
Io credo che il vero problema sia dovuto al fatto che ci siano molte
persone "fai da te" che sono invece convinte di saper programmare.
Infatti, come tu stesso dici "resta scontato il fatto che la differenza la
fa la testa e non lo strumento" vuol dire appunto che non è lo
strumento/linguaggio/paradigma che risolve il problema ma le idee, il
modo di affrontare il problema e le conoscenze informatiche del
programmatore/analista.
Personalmente, conosco una dozzina di linguaggi/strumenti di sviluppo ed
utilizzo, di volta in volta, lo "strumento" adatto senza farmi troppi
problemi di "moda" e/o "sciccheria" (o forse di scrive chiccheria ?) ma
basando la mia scelta esclusivamente sui benefici prestazionali, di
sviluppo e qualità del prodotto finito.

Post by alberto salvati

Post by Giuseppe Di Martino
Io direi che se si tratta solo di tenere in memoria dei dati
"basta" un vettore; anzi, se la quantità di dati è notevole direi che è
"meglio" un vettore piuttosto che una classe/collection/etc.;

perche'?

Come minimo, impiego meno memoria per conservare gli stessi dati.

Post by alberto salvati

Post by Giuseppe Di Martino
se poi la
quantità diventa proibitiva per la memoria centrale è meglio
rivolgersi ai database o altro.

il db lo ha gia: i dati sono su excel.
non so se avrebbe senso introdurre un ulteriore storage per tale operazione.

L'aver senso dipende da ciò che devi fare e da eventuali vincoli esterni,
esempio: non occupare troppa memoria centrale e/o chiudere il file .xls il
più presto possibile.

Post by alberto salvati

Post by Giuseppe Di Martino

Post by Alberto Salvati
2) oggi sono 3000. E se domani diventano di piu'?

Io ho capito che erano 3000 o qualcosina di più, ma di certo non
1.000.000. Infatti la mia risposta era riferita al fatto che diceva di
avere problemi a memorizzare oltre 3000 elementi.

imho, meglio essere lungimiranti, cosa che molti non fanno, ovviamente
partendo sempre dal buon senso.
A me è successo di scrivere una cosa simile anni fa per 5000 elementi.
Il cliente ci avrebbe messo la mano sul fuoco che non sarebbero mai
diventati di piu'.
2 mesi dopo erano 250.000......

Lungimiranti si ma senza sovraingegnerizzare. Secondo me, il programma
deve risolvere bene il problema, ovviamente prevedendo anche i piccoli
scostamenti che potranno esserci (e ci saranno senza dubbio !), ma non
deve risolvere i problemi che il cliente ti dice che non si
verificheranno mai. Perchè in tal caso è stato lui a non analizzare bene
il problema ed è giusto che paghi per le modifiche che dovrai fare in
futuro al programma.

Post by alberto salvati

Post by Giuseppe Di Martino

Post by Alberto Salvati
3) che senso ha metterli in memoria e poi salvare?
Se deve processare una riga per volta ogni 10 minuti, ad esempio, a che
serve caricare le altre righe su cui lui non fa un tubazzo?

Non so se hai letto tutto il messaggio, ma gli suggerivo anche l'idea di
non memorizzare nulla e con unico ciclo leggere il dato/elaborarlo/salvare
il risultato. Ma a volte possono esserci altre ragioni, ad esempio dover
sbloccare prima possibile il file .xls da cui leggere i dati, etc.

io non ritengo una buona strategia impegnare tempo e risorse a caricare
una seuppur minima qnt di dati di cui all'utente non frega niente.
Mai visto che bei programmi che l'utente apre una form e senza poter
dire "no, grazie" gli si popola una dbgrid con 10000 righe?
E lui sta li ad aspettare.. e si inkazza, giustamente.

Sono dello stesso parere.

Post by alberto salvati
Senza polemica, eh?? :-))

Nessuna polemica (la polemica è una delle che mi danno maggiore fastidio).

Giuseppe

[Alberto Salvati]

Post by Giuseppe Di Martino
Come minimo, impiego meno memoria per conservare gli stessi dati.

personalmente, in OOP mi trovo troppo bene, al punto di vedere il
programmare strutturato come aprire una scatoletta di tonno con una
forchetta potendo utilizzare un apriscatole...
Da qui il mio preferire le collection agli array, che mi permetto di
INCAPSULARE il codice per gestire gli item evitando lo sparpagliamento
di codice che difficilmente in strutturato puoi evitare.

imho, un sistema OO progettato bene risulta a parita di condizioni +
semplice da modificare rispetto ad un sistema strutturato.
Il semplice fatto di poter isolare le parti che presumibilmente
potrebbero essere oggetto di refactoring limitando l'impatto su tutto
il sistema è, imho, una cosa utile, comoda e che abbatte i costi.

Post by Giuseppe Di Martino
Lungimiranti si ma senza sovraingegnerizzare.

Quello si.
Serve equilibrio, mettendo insieme cio che serve ORA in modo che sia
facilmente modificabile qualora al cliente venisse qlc idea.
Ovviamente se il cliente parte che vuole un magazzino per legnami e poi
lo vuole usare per prodotti di gioielleria o paga o si fotte...

Post by Giuseppe Di Martino
Perchè in tal caso è stato lui a non analizzare bene
il problema ed è giusto che paghi per le modifiche che dovrai fare in
futuro al programma.

NI.
Tanto x iniziare, il cliente DEVE sapere che le modifiche si pagano a
prescindere, fermo restando il solito buon senso.
Poi, dipende molto dal tipo di rapporto che c'e' con il cliente stesso.
Ma il presupoposto e' che i professionisti ICT siamo NOI, e dovremmo
essere in grado di spremergli tutte le info possibili, xche LUI non sa
cosa è importante x mettere su un sw fatto come si deve, ma noi
dovremmo saperlo....

A.

[Giuseppe Di Martino]

Post by Alberto Salvati

Post by Giuseppe Di Martino
Come minimo, impiego meno memoria per conservare gli stessi dati.

personalmente, in OOP mi trovo troppo bene, al punto di vedere il
programmare strutturato come aprire una scatoletta di tonno con una
forchetta potendo utilizzare un apriscatole...
Da qui il mio preferire le collection agli array, che mi permetto di
INCAPSULARE il codice per gestire gli item evitando lo sparpagliamento
di codice che difficilmente in strutturato puoi evitare.

Sono d'accordo con quello che dici però solo in generale, perché
bisogna valutare le situazioni; ad esempio, se ho una routine in cui devo
leggere N numeri da una sorgente (database, dispositivo, etc.) elaborarli
e salvarne il risultato userò delle semplici variabili o un vettore (se
devo elaborarli contemporaneamente) e non mi vado a creare delle classi,
metodi, proprietà, etc.
Naturalmente, ai giorni d'oggi è impensabile creare un intero progetto
senza far uso della OOP.
Riassumendo: io non ho preferenze per la programmazione strutturata, oop,
funzionale, etc. ma semplicemente le conosco (e mi diverto con) tutte ed
uso sempre quella più adatta alla situazione.

Post by Alberto Salvati
imho, un sistema OO progettato bene risulta a parita di condizioni +
semplice da modificare rispetto ad un sistema strutturato.
Il semplice fatto di poter isolare le parti che presumibilmente
potrebbero essere oggetto di refactoring limitando l'impatto su tutto
il sistema è, imho, una cosa utile, comoda e che abbatte i costi.

d'accordissimo.

Post by Alberto Salvati

Post by Giuseppe Di Martino
Lungimiranti si ma senza sovraingegnerizzare.

Quello si.
Serve equilibrio, mettendo insieme cio che serve ORA in modo che sia
facilmente modificabile qualora al cliente venisse qlc idea.
Ovviamente se il cliente parte che vuole un magazzino per legnami e poi
lo vuole usare per prodotti di gioielleria o paga o si fotte...

infatti.

Post by Alberto Salvati

Post by Giuseppe Di Martino
Perchè in tal caso è stato lui a non analizzare bene
il problema ed è giusto che paghi per le modifiche che dovrai fare in
futuro al programma.

NI.
Tanto x iniziare, il cliente DEVE sapere che le modifiche si pagano a
prescindere, fermo restando il solito buon senso.
Poi, dipende molto dal tipo di rapporto che c'e' con il cliente stesso.
Ma il presupoposto e' che i professionisti ICT siamo NOI, e dovremmo
essere in grado di spremergli tutte le info possibili, xche LUI non sa
cosa è importante x mettere su un sw fatto come si deve, ma noi
dovremmo saperlo....

Sono d'accordo, infatti io mi riferivo al caso che il cliente dicesse
espressamente che quella situazione non succederà mai.
Una situazione simile mi è capitata ai tempi del Clipper, nel 92, con un
cliente a cui dovevo realizzare delle stampe contenenti dati tabellari, su
cui erano presenti molte colonne, alcune delle quali contenevano degli
incassi; e dovendo stringere il più possibile la larghezza delle colonne
ho chiesto se gli importi inseriti ed i relativi totali potevano
raggiungere il miliardo di lire; lui si mise a ridere e (con aria quasi da
sfottò) mi rispose che in tal caso sarebbe stato ben felice di pagarmi le
modifiche. Bene, l'anno successivo me le feci pagare *per bene*.

Giuseppe

[Alberto Salvati]

Non so tu, ma la mia esperienza è costellata di cose da usare una
tantum scritte di getto che poi sono diventate vitali e sulle quali,
ovviamente, sono poi state chieste modifiche.
Ora, se la controparte è un cliente, paga e buonanotte.
Ma se 6 in un ufficio IT di una azienda e arriva una testa d'uovo e
VUOLE che una cosa che prima andava nel modo A ora deve andare nel modo
B e tu 6 costretto a fare le corse per rispettare i tempi che ti sono
imposti, un approccio OOP ti garantisce, imho, tempi di refactoring +
bassi.
A me fa seriamente riflettere il fatto che i lunguaggi di nuova
generazione come java e c# siano SOLO object oriented.
Ovviamente se uso delphi e devo fare una cosa che serve a ME, solo a
ME, al volo, e sono certo che dopo averla usata una volta la butto via,
valuto e FORSE non uso OO..

Post by Giuseppe Di Martino
Riassumendo: io non ho preferenze per la programmazione strutturata, oop,
funzionale, etc. ma semplicemente le conosco (e mi diverto con) tutte ed
uso sempre quella più adatta alla situazione.

io sono OO dipendente, invece... ;-))
Da che la uso mi riesce difficile mollarla.

Post by Giuseppe Di Martino
Sono d'accordo, infatti io mi riferivo al caso che il cliente dicesse
espressamente che quella situazione non succederà mai.

Ok. ma non è detto che il cliente debba sapere certi dettagli di
implementazione.
A quel punto, il costo smettete di essere "di tempo" ma diventa costo
di modifiche puro e semplice...
:-))

Post by Giuseppe Di Martino
ho chiesto se gli importi inseriti ed i relativi totali potevano
raggiungere il miliardo di lire; lui si mise a ridere e (con aria quasi da
sfottò) mi rispose che in tal caso sarebbe stato ben felice di pagarmi le
modifiche. Bene, l'anno successivo me le feci pagare *per bene*.

Cosi' si fa! spesso la gente non da valore a cio che non paga.
Clipper, eh?
Mai ridefinito il funzionamento di getsys?
Mai smanettato con i codeblock e bestemmiato davanti all'uso massiccio
di macro?
Blinker o Exospace?
SixDriver o Comix?

:-))

A.

[Giuseppe Di Martino]

Post by Alberto Salvati
Non so tu, ma la mia esperienza è costellata di cose da usare una
tantum scritte di getto che poi sono diventate vitali e sulle quali,
ovviamente, sono poi state chieste modifiche.
Ora, se la controparte è un cliente, paga e buonanotte.
Ma se 6 in un ufficio IT di una azienda e arriva una testa d'uovo e
VUOLE che una cosa che prima andava nel modo A ora deve andare nel modo
B e tu 6 costretto a fare le corse per rispettare i tempi che ti sono
imposti, un approccio OOP ti garantisce, imho, tempi di refactoring +
bassi.

Per fortuna nella mia azienda (credo) non ci siano teste d'uovo e le
controparti sono quasi sempre dei clienti.

Post by Alberto Salvati
A me fa seriamente riflettere il fatto che i lunguaggi di nuova
generazione come java e c# siano SOLO object oriented.
Ovviamente se uso delphi e devo fare una cosa che serve a ME, solo a
ME, al volo, e sono certo che dopo averla usata una volta la butto via,
valuto e FORSE non uso OO..

Da sempre ho evitato di usare java, c# et simila, perché sono
convinto che alla fine ti fanno perdere un sacco di tempo; invece è da un
annetto che studio il Python e tutto ciò che gli gravita intorno e posso
dirti che ogni giorno mi sorprende (in positivo) sempre di più.

Post by Alberto Salvati

Post by Giuseppe Di Martino
Sono d'accordo, infatti io mi riferivo al caso che il cliente dicesse
espressamente che quella situazione non succederà mai.

Ok. ma non è detto che il cliente debba sapere certi dettagli di
implementazione.
A quel punto, il costo smettete di essere "di tempo" ma diventa costo
di modifiche puro e semplice...
:-))

Infatti, i miei clienti non sanno nemmeno in che linguaggio o quali
strumenti uso per creare i programmi; loro devono sapere soltanto come
usarli e quali risultati aspettarsi. Poi sono io a dover prevedere le loro
necessità informatiche future e fare in modo da essere preparato
(leggasi: progettare i programmi in modo facilmente
espandibile/modificabile) per soddisfare al meglio le loro
necessità(funzionalità) e le mie (perdere meno tempo possibile e
produrre programmi (quasi)senza bachi)

Post by Alberto Salvati

Post by Giuseppe Di Martino
ho chiesto se gli importi inseriti ed i relativi totali potevano
raggiungere il miliardo di lire; lui si mise a ridere e (con aria quasi da
sfottò) mi rispose che in tal caso sarebbe stato ben felice di pagarmi le
modifiche. Bene, l'anno successivo me le feci pagare *per bene*.

Cosi' si fa! spesso la gente non da valore a cio che non paga.
Clipper, eh?
Mai ridefinito il funzionamento di getsys?
Mai smanettato con i codeblock e bestemmiato davanti all'uso massiccio
di macro?
Blinker o Exospace?
SixDriver o Comix?

L'ultima volta che ho linkato un exe con il blinker è stato nel
lontano.... stamattina !


Giuseppe

[Alberto Salvati]

Post by Giuseppe Di Martino
Per fortuna nella mia azienda (credo) non ci siano teste d'uovo e le
controparti sono quasi sempre dei clienti.

beato te.

Post by Giuseppe Di Martino
Da sempre ho evitato di usare java, c# et simila, perché sono
convinto che alla fine ti fanno perdere un sacco di tempo;

SOLO xche sono OO o x altri motivi?

Post by Giuseppe Di Martino
invece è da un
annetto che studio il Python e tutto ciò che gli gravita intorno e posso
dirti che ogni giorno mi sorprende (in positivo) sempre di più.

Python non lo conosco. :-((

Post by Giuseppe Di Martino
L'ultima volta che ho linkato un exe con il blinker è stato nel
lontano.... stamattina !

io a giugno...eheheheheh!

A.

[Giuseppe Di Martino]

Post by Alberto Salvati

Post by Giuseppe Di Martino
Da sempre ho evitato di usare java, c# et simila, perché sono
convinto che alla fine ti fanno perdere un sacco di tempo;

SOLO xche sono OO o x altri motivi?

no, l'oop non è un problema, solo che non producono exe puri,
necessitano di un runtime non indifferente, e tante altre cosette che
sinceramente mi danno fastidio.

Post by Alberto Salvati

Post by Giuseppe Di Martino
invece è da un
annetto che studio il Python e tutto ciò che gli gravita intorno e posso
dirti che ogni giorno mi sorprende (in positivo) sempre di più.

Python non lo conosco. :-((

Io Python l'ho conosciuto per caso, però posso solo dirti che contiene
tante idee 'sorprendenti' che ti semplificano la programmazione in modo
incredibile.
Ti consiglio vivamente di darci un occhiata, vedrai che se cominci ad
usarlo non riuscirai più a farne a meno. Questa cosa l'ho
sperimentata personalmente ed è una frase molto comune nella
comunità pythoniana.

Credo comunque che stiamo cominciando ad essere leggermente OT

Giuseppe