Newsgroup: it.comp.lang.vo-clipper
Titolo: Consiglio

Ho ottima esperienza di Clipper52 e buona esperienza di VBA, se decido ti
passare a V.O. faticherei molto ad abituarmi al nuovo linguaggio ?
Grazye
Ps. : Attendo Consigli e considerazioni !

 wrote in message
9nlpm0$uf2$1...@lacerta.tiscalinet.it...


 ha scritto nel messaggio
news:9nlpm0$uf2$1...@lacerta.tiscalinet.it...

Per la mia esperienza personale da Clipper 5.2  a VO 2.5 lo scoglio più
grande è la gestione degli eventi ( totalmente incapsulata nelle classi GUI
del VO ), in quanto inizialmente non si sa mai dove inserire il proprio
codice. Comunque dopo un iniziale imbarazzo le cose vengono naturali.
 L'altro scoglio è la gestione degli oggetti; comunque se hai utilizzato le
classi del Clipper 5.2 non dovresti avere troppe difficoltà.
Non conosco troppo bene VBA comunque dovrebbe essere meno grande il salto in
quanto con VBA  ( o meglio VB) dovresti già aver conosciuto la gestione
degli eventi di WINDOWS.
Ciao,
      Fabrizio Malaguti

Benvenuto tra noi !!!
Vai tranquillo che ti "prenderemo per mano"
Vo è un' avventura che all'inizio sembra difficile, ma dopo un pò sarà ricca
di soddisfazioni e molto esaltante.
Ciao
Enio

 codice.
Secondo me una delle cose da evitare da subito quando si inizia a
programmare event-driven sotto una qualunque GUI come Windows è quella
di andare alla ricerca di dove inserire il proprio codice. Il codice non
va "inserito" da nessuna parte. Questo dell'inserimento è proprio il
pessimo approccio seguito dal Visual Basic che comporta una serie di
svantaggi e difficoltà di gestione di progetti di dimensioni anche
appena discrete.
Invece trovo l'approccio del Clipper molto più versatile e pulito. Il
codice Clipper non è sparpagliato nei vari controlli ma, al contrario,
sono i controlli che chiamano il codice attraverso il meccanismo dei
code-blocks, e questi si trovano, in modo molto lineare, all'interno del
nostro codice, non di slots che qualcuno, che non aveva ben chiaro il
concetto di event-driven, ha preparato per noi.
EMG

Invece trovo l'approccio del Clipper molto più versatile e pulito.
Guarda che anche in VO puoi mettere il soft dove ti pare, ma e' molto
piu' comodo usare le facilitazioni previste dal linguaggio.
Ignazio GSS©
More than 90 HiRes images in my home page  
http://www.geocities.com/~puddu/
Oltre 200 Immagini di endoscopia digestiva
http://www.areamedica.com

 piu' comodo usare le facilitazioni previste dal linguaggio.
Io non conosco VO. Rispondevo all'amico che diceva di "inserire" codice
non si sa bene dove. E commentavo il fatto che quello è proprio
l'approccio utilizzato dal Visual Basic, strumento di cui invece conosco
molto bene gli "orrori". :-)
Comunque nutro forti (e fondati!) dubbi che possa essere più "comoda"
una "facilitazione" come quella. Dipende certamente da cosa si intende
per comoda. Qui forse si sta facendo confusione tra i giocattoli e
l'informatica. La seconda cerca di affrontare e risolvere i problemi in
modo scientifico, organico ed efficace. I primi, invece, servono
fondamentalmente a due sole cose: far fare soldi a chi li produce e, in
seconda istanza, a permettere anche ai ragazzini di fare programmi
(ovviamente programmi da ragazzini).
EMG


A questo proposito però aggiungo che dipende molto anche dallo stile di
programmazione che uno ha. Ho visto certi programmi ( compreso i miei nei
primi anni ) che di pulizia stilistica non avevano nulla. Inoltre,  le
classi e i code-blocks sono stati introdotti con il Clipper 5.0 circa 10
anni fa; i vecchi programmi scritti ancora col 'summer 87 ' erano molto meno
versatili e puliti.
Ciao ,
        Fabrizio Malaguti

(ovviamente programmi da ragazzini).
O a facilitare il compito di chi utilizza i linguaggi favorendo una
maggiore produttivita' in tempi minori. Non mi pare cosa disdicevole
E' ovvio che lo diventa se la scelta e' obbligata, ma in VO di
obbligato non c'e' quasi nulla.


 wrote in message
9nlpm0$uf2$1...@lacerta.tiscalinet.it...


 versatili e puliti.
Perfettamente d'accordo. Con la versione 5 la CA fece veramente un
ottimo lavoro creando un "signor" linguaggio che è attualissimo anche
oggi in quanto dotato del supporto nativo ai più moderni paradigmi di
programmazione (c'era anche la possibilità di creare classi nuove,
perfettamente funzionante anche se non documentata).
EMG

 maggiore produttivita' in tempi minori.
Certo. Ma l'approccio event-driven di Visual Basic č ben lungi
dall'ottenere questo.
EMG

dall'ottenere questo.
Infatti io ho mollato VB quasi subito per passare a VO che e' molto
meglio IMHO.
E comunque l'uso di windows E' EVENT DRIVEN.


 E comunque l'uso di windows E' EVENT DRIVEN.
Continuiamo a fare confusione tra concetto di event-driven e sua
implementazione. Quella di VB è pessima. Quella di Clipper/Fivewin
ottima. Se programmi direttamente in C devi farti tutto a mano ed è
molto ma molto simile (praticamente identico) all'approccio della
vecchia "funzione utente" del Clipper (cfr. Win32 SDK). Le gerarchie di
classi GUI come quelle fornite dalle Fivewin come prima cosa nascondono
questo meccanismo interno e te lo fanno vedere come delle semplici
chiamate a metodi delle varie classi. Normalmente c'è una classe base
che riceve tutte le chiamate e le classi derivate ridefiniscono i metodi
che vogliono gestire.
EMG

strumento utilizzato.
Ma scusa se tu metti un bottone in una finestra, non ti pare semplice
avere un metodo ButtonClick che viene evocato quando ci clicchi sopra?
O come vorresti fare, scusa?


 O come vorresti fare, scusa?
Evidentemente non hai ben chiara la terminologia. Quello che ti si apre
quando clicki su un bottone non è un metodo. L'approccio (come volevasi
dimostrare) è identico a quello (pessimo) del VB. Solo che almeno
quest'ultimo ha avuto il buon gusto di utilizzare un nome diverso.
Infatti quelli li chiama "eventi" (intendendo con questo il codice di
risposta ad un particolare evento generato dall'azione dell'utente, dal
sistema, etc.) che corrispondono esattamente ai code-blocks tipo
GoTopBlock, GoBottomBlock, etc. della vecchia classe TBrowse del Clipper
(e questi non sono metodi ma dati membri della classe -- è una cosa ben
diversa). I metodi li tiene ben separati e, ovviamente, non ridefinibili
semplicemente "scrivendoci dentro del codice". Spero che sia solo un
problema di termini e non di concetti...
EMG

pesce.
Mah, secondo me sei prevenuto, dato che dichiari di non conoscerlo :-)


 Mah, secondo me sei prevenuto, dato che dichiari di non conoscerlo :-)
No, non sono affatto prevenuto. La mia "conoscenza" di VO è fondata su
quello che leggo qui sopra e in base a quella scrivo i miei commenti.
Tutto qui.
Io cerco di differenziare nettamente ciò che è informatica da ciò che è
mercato. Il mercato offre dei prodotti che possono essere più o meno
rispondenti alle esigenze informatiche (mentre tendono ad essere più
rispondenti a quelle economiche di chi li produce). Questo tipo di
atteggiamento porta molti vantaggi. Crea uno strato di astrazione che
rimane solido e costante qualunque problema si affronti e con qualunque
strumento. D'altronde è lo stesso criterio che si adotta (o si dovrebbe
adottare) quando si scrive software: isolare la parte generica e
facilmente portabile da quella specifica che va rivista e riorganizzata
nel caso di cambiamento di versione/strumento/piattaforma.
Detto questo, risulta chiaro che le mie critiche sono a questo livello
astratto, l'unico del quale, essendo portabile, si può discutere senza
conoscere lo strumento che si sta utilizzando. D'altronde l'alternativa
sarebbe che me ne stessi zitto e rispondessi solo alle domande sul
Clipper. Ma non credo che sarebbe un'alternativa valida dato che c'è
sempre da imparare per voi che leggete i miei interventi ma anche per me
che ne ricevo delle reazioni. Che ne pensate?
EMG

 problema di termini e non di concetti...
Ciao Enrico Maria, scusami se mi intrometto, ma non mi sembra cosi' pessimo
l'approccio, non so se ho capito correttamente come funziona, ma se 
funziona come Delphi non e' male. 
In Delphi ogni componente e non solo quelli GUI possono generare eventi e 
questo non e' male, poi ad ogni evento puoi collegare un puntatore a funzione 
(che e' semanticamente riportabile ai codeblock), in questo modo l'ide 
automaticamente connette l'evento ad un metodo. 
Se anche VO avesse un approccio OOP piu' spinto che costringe a fare una 
classe inherited per ridefinire im metodo che intercetta un evento non 
ci vedrei niente di male.
Ciao...
Claudio Driussi
http://www.swit.net/csoft
mailto:
cldr...@swit.net

 che ne ricevo delle reazioni. Che ne pensate?
Concordo perfettamente...
Io sono uno scarso utilizzatore di Vo, e stavo per mollarlo per VB.....
Dopo aver scoperto questo NG ci ho ripensato, avendo trovato finalmente
informazioni utili e qualcuno che mi aiuta quando sono in difficoltà.
Purtroppo il mio contributo attivo è limitato, però spero col tempo di poter
aiutare anch'io qualcuno!!
Nel frattempo ritengo VO uno dei pochi prodotti che ti lascia la massima
libertà di creare il programma come vuoi, in modo semplice se vuoi
utilizzare le classi standard previste, od in modo analitico se il programma
te lo scrivi da zero. E questo dipende solo da te.
Poi che rispecchi perfettamente i canoni della programmazione ad oggetti o
meno vi lascio discutere visto che mi sembra un dialogo costruttivo e senza
pregiudizi.
Ciao.

 ci vedrei niente di male.
Neanch'io. Ma a me pareva di aver capito che bisognasse derivare una
classe per ogni istanza. Sicuramente ho capito male.
EMG


Devo ammettere che anch'io all'inizio, quando ho analizzato come VO gestisce
le classi, mi sono trovato un po' spaesato in quanto assai diverso al C++.
Ora però ho capito una cosa; ovvero che VO lascia ampie possibilità di
creare un proprio standard stilistico che pochi altri linguaggi danno. Per
esempio non tutti sanno che è possibile utilizzare classi con metodi
tipizzati (con VO 2.5), metodi nascosti e così via ( vedi REPORT PRO 3.x e
CLASSMATE 2xx. Con VO è possibile creare le proprie classi GUI  ( in effetti
qualcuno si è lamentato della lentezza delle classi DataBrowse ecc - bene
basta riscriverle, cosa che sto tentando di fare; trovo comunque molto
interessanti  le classi GUI scritti dalla CA in quanto indicano la strada
per gestire molte finestre figlie linkate ad uno stesso server di dati - se
sono lente basta semplificarle e ottimizzarle  ) o addirittura utilizzare
quelli del C++ !!!. Poi se uno preferisce utilizzare direttamente le API di
windows può sempre farlo.
Quindi con VO è l'utente che gestisce il linguaggio e non viceversa. Sono
io che decido come scrivere il programma e con quale stile di
programmazione.
Per es. io creo dei DBSERVER ma poi uso la seguente sintassi CLIPPER
workarea := oDBSERVER:WORKAREA // è un metodo ACCESS che mi sono creato io
per ottenere la workarea
(workarea)->dbgoto(3)
anzichè la seguente:
oDBSERVER:GOTO(3)
in quanto quest'ultimo particolarmente lento. Ovvio che occorre una certa
attenzione se ho il DBSERVER linkato a una DATAWINDOWS.
Forse è proprio questo il vero punto di forza di VO che io sono padrone del
linguaggio e non il contrario.
Ciao,
       Fabrizio Malaguti

classe per ogni istanza. Sicuramente ho capito male.
Piu' che altro mi sono spiegato male io: non sono all'altezza della
discussione, se messa sul piano puramente teorico  :-)


 linguaggio e non il contrario.
Esattamente una delle cose che amo di più del Clipper e delle Fivewin.
EMG

 discussione, se messa sul piano puramente teorico  :-)
Ok, non c'è problema, figurati. Neanch'io sono un ingegnere informatico.
EMG


Completamente d'accordo, in fondo sia CLIPPER  che VO sono stati sviluppati
dalla CA con la stessa filosofia aperta ( sono circa 11 anni che uso CLIPPER
e sono molto contento; VO mi sembra anche piů valido ).
Qui  volevo solo esaltare le caratteristiche di VO. Sono consapevole che ci
sono altri
linguaggi e strumenti validi ( C, C++, DELPHI sono un esempio).
Ciao ,
       Fabrizio Malaguti

 VO ); volevo solo dire che è possibile farlo ( vedi le CLASSMATE ).
Non parlavo di controlli GUI. Utilizzare quelli standard o quelli
offerti dal proprio strumento o addirittura scriversene di propri è
un'attività sacrosanta. Io parlavo di paradigmi di programmazione.
Ridefinire un metodo di un'istanza è un'interpretazione personalissima e
dal valore molto dubbio del paradigma object-oriented. Si ridefiniscono,
attraverso la derivazione, i metodi di una classe. Spero che abbiamo
tutti ben chiara la differenza fra classe e istanza...
EMG

 classe per ogni istanza. Sicuramente ho capito male.
questo sarebbe scomodo, quello che odio dei linguaggi OOP e' che a volte
costringono a scrivere decine di righe per ogni banalita', una delle cose
che piu' apprezzo di Clipper e soci e' la grande espressivita'.


 che piu' apprezzo di Clipper e soci e' la grande espressivita'.
Completamente d'accordo.
EMG


Scusami, cosa intendi per "Ridefinire un metodo di un'istanza" ?
Forse ho capito male ma da quello che avevo capito io dell'OOP è che la
CLASSE permette di descrivere un problema elencando le variabili d'istanza e
dichiarando i metodi legati alla classe; tramite l'istanziazione della
classe ( constructor della classe - metodo init ) si crea l'oggetto. Quello
però che non capisco è come sia possibile ridefinire un metodo di
un'istanza.
L'unico modo che io conosco è quello di derivare la classe riscrivere il
metodo ed insanziare quest'ultima classe ( come appunto dicevi tu ).
Da quello che posso aver capito è che in effetti con VO è possibile
aggiungere metodi alla classe originaria anzichè derivarla e scrivere detti
metodi nella classe derivata (non mi risulta però che sia possibile
riscrivere un metodo se questo è già presente nella classe).
Questa filosofia di gestione delle classi ( per quel che mi risulta
possibile solo con VO) in effetti può lasciare allibiti i puristi dell'OOP
però, a ben vedere e sempre che, questa tecnica, sia utilizzata con il
contagocce,  può essere molto interessante in quanto può evitare la
proliferazione del numero delle classi. In ogni caso è il programmatore che
decide se utilizzare detta tecnica o meno ( non si è obbligati a farlo da
VO).
Ciao ,
         Fabrizio Malaguti.

 VO).
In effetti questo però è equivalente a modificare la classe originaria.
A meno che i metodi aggiunti non abbiamo project scope cioè valgano solo
per un dato progetto e non per un altro. E' così? Se si, hai ragione:
potrebbe essere una cosa comoda (in Clipper/Fivewin e C++ non si può
fare).
EMG


Per essere sincero non ho verificato se i metodi abbiano project scope , ma
penso di si.
Ciao ,
       Fabrizio Malaguti

 penso di si.
Però vedo un problema grave: che succede se, durante la vita di
un'applicazione, decido, ad un certo momento, di modificare un metodo di
una classe base importante (leggi: molto utilizzata)? Che succede a
tutto il codice cliente (per codice cliente intendo chi usa quella
classe, chi ne chiama i metodi) che funzionava con la vecchia versione
del metodo che ora ho modificato? In effetti la OOP dice che una classe
base dovrebbe essere una classe di pura interfaccia, non istanziabile,
proprio per evitare questo tipo di problemi.
EMG

 ha scritto nel messaggio
news:3BA87DF4...@flashnet.it...

Se modifico un metodo della classe base ( è possibile solo per i metodi che
ho aggiunto ) è assolutamente necessario che comunque il funzionamento non
cambi (posso eventualmente aggiungere funzionalità ), altrimenti occorre
modificare tutte le classi derivate ( più i programmi che richiamano dette
classi). Come dicevo in precedenza bisogna utilizzare questa tecnologia col
contagocce in maniera molto occulata.
Per esempio io ho creato delle classi per gestire oggetti grafici statici
 non dimensionabili anche se modifico le dimensioni della finestra che li
contiene [per motivi di velocità pura]); per legare questi oggetti a tutte
le finestre ho creato un metodo DrawGraphic(oGraph) e l'ho linkato alla
classe Window così da poter utilizzare questa nuova funzionalità con tutte
le classi derivate. In caso contrario avrei dovuto derivare tutte le classi
derivate da Window e associare a ciascuna di esse il nuovo metodo.
Come dicevo questo modo di lavorare ( credo unico di VO [ il fatto di poter
aggiungere metodi a una classe senza ereditarla]) può essere non del tutto
condivisibile ma in certi casi è molto utile.
Ciao ,
         Fabrizio Malaguti.