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

Ciao a tutti,
sto cominciando a comprendere VO. Molto interessante e promettente. Ho
ancora qualche (numerosi) problema con l'IDE ma mi sto sforzando di
utilizzarla al meglio.
Ho fatto un tentativo senza usare il wizard, creando cioe' un'applicazione
nuova. Ovviamente lacrime e sangue, ma alla fine, con qualche copia ed
incolla sono riuscito a fare un'applicazione (una schifezza) di prova. In
questo test ho aperto una shell window con un menu' che ho creato io e che
apre una data window e che la chiude. Lo stesso menu' e' usato dalla shell
window e dalla datawindow: ci pensa il sistema ad inviare i messaggi giusti
ai metodi appropriati. Ho infatti creato due metodi FILECLOSE uno nella
classe datawindow ed uno nella classe shell window (ovviamente differenti)
ed i messaggi che compaiono a video corrispondono a cio' che ho codificato.
Tutto questo funziona.
Sono andato un poco piu' avanti ed ho provato ad ereditare la datawindow
(MYDATAWINDOW), nella quale c'e' un testo fisso e due bottoni, da un'altra
datawindow (myMYDATAWINDOW). Tutto funziona ok ed i metodi aggiunti alla
nuova classe vanno che e' un piacere. Il problema sorge se inserisco nuovi
oggetti nella form. Infatti aggiungendo un bottone o un testo fisso esce
fuori un errore a runtime (compilazione perfetta).
Ecco l'errore:
KID STACK SIZE LIMIT EXCEEDED
ed ecco la riga sulla quale esce l'errore
oDCmymytext:HyperLabel := HyperLabel{#mymytext,"Fixed
Text",NULL_STRING,NULL_STRING}
Qualche idea ?
Ciao,
Marco Boeri

 Hai provato con touch
oppure con reindex ?
potrebbe essere essere un problema relativo ai troppi copia ed incolla
a volte mi è successo
Vincenzo

Grazie, ma non e' funziona.
saluti,
Marco

 Paolo
Non so cosa dire. Cio' che ho scritto e' molto poco: 3 window di cui 2
ereditate in cascata e 3 controlli. Non c'e' molto nello stack, pero' ne so
ancora troppo, troppo poco per poter escludere questa eventualita'. Il punto
e' che non saprei come correggere l'errore, o meglio, so come correggerlo,
ma non come andare avanti. Semplicemente tolgo il controlla dalla window che
eredita da mydatawindow e sono a posto. Solo che cosi' non posso provare una
cosa estremamente interessante, e cioe' creare delle window (data o altro)
con una serie di pulsanti ed oggetti predefiniti e poter subclassare delle
finestre differenti a seconda delle necessita'.
Se siete interessati posso postare il sorgente di tutte e 3 le classi per
chiarire meglio il problema.
Ciao
Marco Boeri

 > Paolo
Esatto !! Prova ad andare di DEBUG per capire dove il tuo programma entra in
un loop infinito per cui esaurisci lo stack, come se un metodo o una classe
fossero richiamati all'infinito.
Danilo Giuliani
www.softdevo.com
in...@softdevo.com
sup...@softdevo.com


 ha scritto nel messaggio
news:oCPdb.136096$hE5.4...@news1.tin.it...


 ha scritto nel messaggio
news:IzQdb.355731$Ny5.11...@twister2.libero.it...


 ha scritto nel messaggio
news:PvTdb.187473$R32.6...@news2.tin.it...


Ciao a tutti,
sul ng internazionale mi e' stato risposto che non posso ereditare una
window da un'altra window.
In pratica io facevo:
DataWindow->mydatawindow->mymydatawindow
Dicono che non e' possibile, ma mi pare che nella documentazione cio' non
sia menzionato
E' un grosso peccato e penso che sicuramente c'e' un altro sistema per
ovviare a questa mancanza. Io non lo conosco (ovviamente) e passo la palla a
voi vo-guru.
Solo per vs. conoscenza: non so in Delphi o C# ma sono sicuro che in DBPlus
(concorrente di Vo) questa possibilita' c'e' ed e' anche normalmente usata
per costruire tutte le interfacce: si creano delle finestre di base, se ne
ereditano le caratteristiche e si aggiungono funzionalita' man mano che si
scende nell'albero della classe (come qualsiasi oggetto!).
Non mi pare sia una cosa trascendentale, ma normale programmazione ad
oggetti (finora ho fatto molta teoria studiando molto).
Parecchi di voi obietteranno: puoi farlo ! Modifichi il file ini che
costruisce le finestre aggiungendo la tua finestra generale e cosi' via con
le classi ereditate. Ok, posso farlo, ma debbo uscire dall'ide ed editare un
file ini, cosa non molto user friendly. Ed in ogni caso non cambierebbe il
limite relativo all'ereditarieta' che si ferma al primo livello: non una
grande soluzione (benche' funzionante).
Stessa domanda dell'ng internazionale: secondo voi non potrebbe una
caratteristica interessante da aggiungere alla 2.7 o successiva versione ?
Ciao
Marco

 oggetti (finora ho fatto molta teoria studiando molto).
Infatti lo è, a patto che "aggiungere funzionalità" non significhi
aggiungere nuovi metodi nelle classi derivate. Questo sarebbe infatti un
errore in quanto distruggerebbe la sostituibilità della classe derivata
con la sua classe base. In altre parole, se un B è un A allora un A deve
poter essere utilizzato dovunque venga utilizzato un B. E se B ha dei
metodi in più rispetto ad A, questo non è possibile. Al più B può
specializzare metodi già esistenti in A.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

 scende nell'albero della classe (come qualsiasi oggetto!).
Mi pare ovvio, altrimenti che programmazione ad oggetti č.
Non so chi ti abbia dato la risposta, ma penso che non abbia capito molto di
VO.


 Dicono che non e' possibile, ma mi pare che nella documentazione cio' non
E' possibilissimo, anzi, è la base della programmazione ad oggetti.
Se vuoi creare una nuova classe che erediti i metodi di una qualsiasi 
altra classe devi utilizzare una dichiarazione del tipo:
ClasseDerivata INHERIT ClasseBase
Poi, nel metodo INIT della ClasseDerivata puoi instanziare ulteriori 
variabili o dichiarare metodi aggiuntivi rispetto alla classe base.
Spero di essere stato comprensibile (anche se per brevità un poco 
impreciso), ciao Antonio

Ciao a tutti,
sono sempre io.
Non voglio strarompere le cosiddette ma e' doverosa una precisazione:
Per brevita' vi copio la risposta di Jan Timmer avuta nell'ng
internazionale:
As I understand it you have two VO generated windows (mydatatawin and
mymydatawin) inheriting from each other. You cannot do this.
In a chain of inheritance you should obly have 1 window generated in the
Window Editor.
Piccola traduzione (immagino non necessaria): non posso ereditare da una
datawindow che a sua volta e' gia' stata ereditata da una datawindow. Questo
in quanto nella catena di ereditarieta' devo avere obbligatoriamente 1
window generata nel WED.
In precedenza mi sono espresso male, me ne scuso.
Saluti
Marco Boeri

 specializzare metodi già esistenti in A.
Scusa ma non mi e chiaro. Correggimi dove sbaglio:
A = superclasse
B= derivata da A
B ha le stesse proprieta' di A ad eccezione di quelle visibili solo in A.
B Puo' accedere ai metodi di A perche' il dispatch viene fatto in
automatico.
Posso modificare metodi esistenti in A dichiarandoli in B e cambiare le loro
funzioanlita' (mi sembri si chiami override dei metodi).
Posso aggiungere nuovi metodi in B non presenti in A.
Ciao
marco

 variabili o dichiarare metodi aggiuntivi rispetto alla classe base.
Come ho detto, questo è, teoricamente parlando, un errore. La classe
derivata non dovrebbe mai avere metodi che la classe base non offre.


 Posso aggiungere nuovi metodi in B non presenti in A.
Ecco, qui sta il problema. Puoi farlo in quanto quasi tutti i linguaggi,
pragmaticamente, offrono questa possibilità. Ma gli stessi linguaggi
offrono anche le variabili pubbliche e, magari, i salti (GOTO). A volte
li usi ma sai che stai cacciandoti nei pasticci (e alla fine te ne penti
sempre). :-)


Adesso ho capito.
Stai parlando della teoria alla base della programmazione ad oggetti e non
dello specifico.
Ad ogni buon conto, nel mio caso, il problema non sta nei metodi aggiunti,
ma nelle risorse (cioe' i controlli) che ho aggiunto alla finestra.
Ho provato a creare una finestra senza l'editor visuale ma il problema c'e'
sempre.
Continuo a pensare che e' una stupidaggine e mi piacerebbe tanto capire
perche' non viene concessa una tale possibilita'.
Ciao, Marco
ps. ma nessuno di voi va mai sul ng internazionale ?


 dello specifico.
Sì, scusa, mi sono dimenticato di specificarlo.


 derivata non dovrebbe mai avere metodi che la classe base non offre.
E' esattamente il contrario, altrimenti che programmazione ad oggetti č.
CLASS CAR
Instance QuattroRuote
Method AvviaMotore
CLASS Berlina INHERIT CAR
Method Carica5Persone
Instance Colore
In piů eredita l'istanza QuattroRuote e Puň avviare il motore
CLASS StationWagon INHERIT Berlina
Method CaricaAncheCane
Instance Portellone
In piů eredita l'istanza QuattroRuote e Puň avviare il motore da CAR e puň
caricare 4 perosne ed avere un colore da Berlina.
Ma la programmazione ad oggetti č utile perchč definate le infinite
caratteristiche generali di un'auto sfrutto il codice per crearne una
variante:
CLASS Spyder INHERIT CAR
Method Carica2Persone
Instance Colore
e cosě via

 Window Editor.
In una catena di ereditarietà dovresti obbligatoriamente avere 1 window
generata nell'editor
...
Non capisco questa ultima affermazione.
Inoltre credo che il tuo interlocutore non abbia capito la domanda, o tu non
ti sei espresso bene.
Per quel che ne so io, il concetto di ereditarietà è ben espresso
dall'esempio di Danilo.
Non capisco nemmeno le note teoriche di EMG: perchè il figlio che eredita
dal padre non dovrebbe avere ANCHE dei metodi propri specializzati?
... O forse sono io che non capisco abbastanza l'inglese e nemmeno la
programmazione OOP.
Ciao
Massimo

Mah. Per la verita' diciamo la stessa cosa. Ho semplicemente tradotto
interpretando il senso e non parola per parola.
Penso che abbia capito perfettamente cio' che ho fatto perche' e' proprio
cosi.
ho creato una nuova finestra MYWINDOW da datawindow e quindi ho creato una
nuova finestra ereditandola da MYWINDOW chiamandola MYMYWINDOW (fantasia al
potere)
Il punto e' che mi e' consentito e potrei anche creare un'applicazione
immagino (non so quanto funzionante) ma non posso aggiungere controlli. Solo
i metodi funzionano, cioe' posso modificare i metodi esistenti o crearne di
nuovi.
Ho provato anche senza WED (mi sono detto "se non uso il wed magari
funziona") ma nulla di nuovo: anche in questo caso stesso errore. Ci deve
essere qualche cosa che in una catena di questo tipo scatena un loop
infinito e da' errore nello stack.
Ciao,
Marco


 E' esattamente il contrario, altrimenti che programmazione ad oggetti è.
La relazione che c'è tra classe base e classe derivata è di tipo is-a,
il che significa che un'istanza di una classe derivata è anche
un'istanza della classe base. Questo fa sì (principio di sostituibilità
di Liskov) che l'istanza della classe derivata possa essere utilizzata
ovunque venga richiesta un'istanza della classe base (polimorfismo). Se
la classe derivata ha metodi non presenti nella classe base questo
principio è violato. In realtà ce n'è uno ancora più forte che vieta che
la classe base sia istanziabile (classe virtuale pura o interfaccia).


 programmazione OOP.
Purtroppo la OOP non è un argomento semplice come si crede (e io sono
ben lontano dall'esserne un esperto). Se affrontata in modo "ingenuo"
non risolve i problemi per cui è nata.


 ha scritto nel
messaggio news:3F7B46E1...@emagsoftware.it...


 in molti) e forse non hai voglia di fare il docente.
Non ne sarei in grado. :-(


 ovunque venga richiesta un'istanza della classe base (polimorfismo).
Questo e' assurdo; e' esattamente il contrario.
Paolo Cherubini


Come può essere il contrario? Il contrario sarebbe che un'istanza della
classe base deve poter essere utilizzata ovunque venga richiesta
un'istanza della classe derivata. Ti sembra che abbia senso? Ma anche
ammesso che lo abbia, il principio di sostituibilità è quello che ho
detto sopra (non l'ho inventato io ma la Liskov!).
Comunque no, non ha senso. Intanto il rapporto in questo caso si
limiterebbe a due sole classi (derivata e base) e quindi il polimorfismo
non ci sarebbe più (considerando anche la raccomandazione di non
istanziare oggetti di classe base). Invece si ottiene polimorfismo
quando una funzione chiede come parametro un'oggetto di classe base e tu
gli passi oggetti di tante classi derivate dalla stessa base ma con
comportamenti diversi.
Se l'oggetto di classe derivata viene esteso (aggiungi alla classe
derivata dei membri non presenti nella base), nel momento in cui viene
passato alla funzione di cui sopra si ha il fenomeno chiamato "slicing",
in pratica una parte dell'oggetto viene "affettata via".


 ha scritto nel
messaggio news:3F7C0E63...@emagsoftware.it...
