Newsgroup: it.comp.lang.vo-clipper
Titolo: vo) listview e db server

Ciao a tutti,
a periodi alterni riprendo in mano vo.... rileggo manuali e libri e faccio
alcune prove. Penso di cominciare a capire qualcosa di piu' anche se tutte
le righe di codice che vengono scritte in automatico dai vari editor mi
fanno perdere la testa...
Tanto per vedere se ho capito qualcosa o debbo ricominciare daccapo (o
riporre tutto nel cassetto) sto facendo alcuni esperimenti. Uno di questi
riguarda due browers (datalistview) su una stessa window. Ho creato le
classi, quindi le ho posizionate sulla window ed infine ho attribuito loro i
servers: ad una ho dato il server della finestra, e ad un'altra un altro
server aggiunto all'oggetto con il metodo datalistview:use(...). Volevo
vedere se potevo determinare l'elemento cliccato nelle due differenti
listview. Ho trovato il metodo ListViewMouseButtonDown(...) con tanto di
esempio.
Con questa istruzione symColumnName := oListViewClickEvent:NameSym riesco a
determinare il controllo attivo, con quest'altra oLVI :=
oListViewClickEvent:ListViewItem anche l'item selezionato, ma non posso
determinare il server attivo perche' non so come accedere all'oggetto della
classe datalistview. Tanto per intenderci, in clipper avrei tradotto il nome
simbolico in una stringa ed avrei fatto una macro sostituzione per accedere
all'oggetto, quindi avrei potuto accedere alle proprieta' di questo (tutto
in teoria, ovviamente). Immagino che si possa fare molto semplicemente, ma
la gestione degli oggetti in VO mi risulta ancora ostica. Preciso che si
tratta di una esercizio per migliorare la mia conoscenza di VO, sto testando
cio' che ho imparato (sto imparando), percio' non ha nulla a che vedere con
progetti concreti.
Ciao a tutti.
--
Marco Boeri
Consulenza Software

 ha scritto nel messaggio
news:5%gZc.76434$OH4.2...@twister1.libero.it...


 server č semplicemente Self:Server


No non ti scoraggiare, è una fase che abbiamo passato tutti ( a me è durata
circa sei mesi, ma io sono tignoso e non potevo permettere che un volgare
linguaggio di programmazione avesse ragione su di me, ne andava del mio
orgoglio di programmatore), ma se ti può consolare ora che padroneggio VO mi
chiedo come ho fatto a programmare in Clipper per tanti anni. Devi solo
cambiare filosofia, e poi neanche tanto.
Ricordati che da quando lavoro in VO ho aumentato la mia produttività del
100 per 100.
Non ti perdere nella selva di istanze e metodi, ma usa di volta in volta
quello che ti serve, partendo con un programmino semplice, (la datalistwiev
non è un approccio facile, usa la databrowser per cominciare)
Buon lavoro
Danilo

 > server è semplicemente Self:Server


 ha scritto nel messaggio
news:R1lZc.181766$OR2.8...@news3.tin.it...


Per ora fossi in te lascerei perdere l'SDK, perchè sino a che non si ha un
pò di podronanza genera soloc onfusione.
Faccio un esempio:
L'SDK dice che la classe DataWindow ha una istanza oGBrowse, alla quale tu
però non hai accesso
CLASS DataWinodow
PROTECT oGBrowse AS Control
Semplicemente perchè ci accedi col nome Browser.
Infatti esiste il metodo:
ACCESS Browser CLASS DataWindow
  RETURN oGBrowse
Per avere l'accesso all'istanza.
Anche le API all'inizio lasciale perdere, queste cose per programmi
"normali" non servono.
Solo quando sarai più esperto ti potrai devertire con API, OLE, ODBC, ADO e
altre amenità.
Lo studio inizia con le elementari dove impari a fare somme e sottrazioni.
Le derivate si fanno all'università.
La differenza è che con VO all'università ci arrivi in pochi mesi se fai
prima bene le elementari.
Danilo

 ha scritto nel messaggio
news:WWmZc.233634$5D1.10...@news4.tin.it...


 ha scritto nel messaggio
news:_HkZc.77038$OH4.2...@twister1.libero.it...

...........................................................
Non so se ho capito bene, ma non è detto che ad ogni variabile PROTECT sia
associato un ACCESS oppure un ASSIGN. Spesso queste variabili sono ad uso
interno della classe e non sono HIDDEN semplicemente perchè le variabili
PROTECT sono visibili anche nelle classi INHERITED che possono usarle a
ritroso, mentre le HIDDEN sono appunto nascoste anche alle classi derivate
da quella che si stà prendendo in considerazione.
Nel verificare le proprietà disponibili non guardare le variabili utilizzate
dalle classi, ma solo l'elenco degli ACCESS/ASSIGN e dei metodi messi a
disposizione dalle classi. Se una classe è INHERIT vai a vederti anche gli
ACCESS/ASSIGN ed i metodi messi a disposizione dalla classe, o dalle classi
madri (o padri?)...Proprio grazie all'uso delle variabili PROTECT essi sono
sempre disponibili anche nelle classi derivate. HTH
Antonio

 Antonio
Direi che hai capito benissimo.
Cio' che dici l'ho capito, infatti cercavo nell'albero delle classi un
metodo che restituisse la proprieta' server settata nella classe CONTROL ma
non l'ho trovata. Mi domando perche'. Non ho alcuna intenzione di usare
proprieta' che non sono documentate nell'help, ne tantomeno metodi. Sto
prendendo questo codice (che peraltro non ha alcuna utilita' pratica ma si
tratta solo di un esercizio, una prova scritta, per valutare cio' che ho
appreso) ad esempio di cio' che puo' accadere con qualsiasi classe, e
qualsiasi proprieta'. Ripeto, non voglio addentrarmi nei meandri di VO ma,
in questo caso, la proprieta' server era cio' che mi necessitava per
risolvere il problema e penso che sia importante sapere che quasi tutti i
controlli possiedono questa proprieta'. Nell'help non ne ho trovato menzione
e spero di sbagliarmi (ricontrollero' meglio).
Grazie della spiegazione, ho le idee un po' piu' chiare, ora. Ancora una
cosa: se rendi protect una proprieta' in una classe all'apice della
gerarchia, questa rimane visibile per tutte le classi derivate, vero ?
Cioe', non e' possibile che ad un certo punto nella gerarchia delle classi,
l'autore del codice, voglia "nasconderla" e quindi farla hidden ?
Ciao Marco

 Ciao Marco
Se mi parli della Datalistview, è la prima proprietà che c'è nell'help.
Comunque io faccio così, quando cerco una proprietà (access/assign) oppure
un metodo, guardo prima nell'help del controllo di cui sto cercando
qualcosa, poi se questo deriva da una classe base più generale, guardo gli
access ed i metodi di quest'ultima, che vanno ad aggiungersi a quelli
disponibili dal controllo esaminato, se anche questa deriva da una classe
base cerco a ritroso fino a trovare la prima classe da cui le successive
ereditano. Se l'access od il metodo cercato non è presente in nessuna,
allora non c'è. Altrimenti se c'è in una qualunque delle classi da cui il
controllo eredita il comportamento, è esattamente come se l'avesse il
controllo in esame. In definitiva, e scusami se mi ripeto, se un controllo
deriva da una classe che a sua volta deriva da un'altra e così via, gli
access ed i metodi disponibili sono la somma degli access e dei metodi messi
a disposizione da tutte le classi della catena ereditaria.
L'ultima domanda, invece, è più sottile e non so darti una risposta senza
fare delle prove. Ipotizzo che si possa fare, cioè interrompere
l'ereditarietà ad un certo punto della catena, ma potrebbe anche essere che
VO consideri le due variabili diverse e crei copia locale della variabile
non ereditabile, mentre consenta la visibilità di quella ereditabile. In
questo modo le classi ereditate andrebbero a modificare la variabile
ereditabile, mentre la classe in cui è ridefinita l'hidden potrebbero andare
a modificare una copia omonima.
Ciao, Antonio

Antonio e tutti quanti,
chiedo scusa per cio' che ho scritto ieri sera ma mi dovevo esser bevuto il
cervello....
Ho parlato della proprieta' SERVER ma non era cio' di cui volevo scrivere.
Nei precedenti messaggi sono stato piu' preciso, fortunamente (segno che non
sono completamente rinco...).
La proprieta' alla quale mi riferivo e' la seguente:
oDCCurrentControl
che e' elencate nella definizione della classe DATAWINDOW
l'istruzione
SELF:oDCCurrentControl:Server mi da' il server associato al controllo (non
e' necessario sapere quale e' il control che ha il focus, ne' il suo tipo).
Ho cercato questa proprieta' nell'help esattamente come dici tu, andando a
ritroso nell'albero delle classi, ma non ho trovato, ne' metodi ne
access/assign che indicassero come ottenere questa proprieta' PROTECT.
Aggiungo che e' definita nella DATAWINDOW percio' ipotizzo che sia usata per
la prima volta in questa classe. A questo punto mi giunge spontanea la
domanda: se e' una proprieta' alla quale non si puo' accedere direttamente
(non si dovrebbe) e non vi si puo' accedere ne tramite un metodo, ne'
tramite un access/assign, e questa proprieta' e' stata introdotta nella
classe DATAWINDOW che e' l'ultima dell'albero delle classi (per la classe
DATAWINDOW ovviamente), dopo di che vi sono solo le classi derivate
dall'utilizzatore della classe (noi programmatori), perche' non definirla
HIDDEN cioe' invisibile alle altre classi derivate invece di PROTECT ?
Quanto alla proprieta' server  della DATALISTVIEW.....
(pausa di 10 minuti nella quale ho fatto delle ricerche, che non avevo fatto
abbastanza in profondita'...)
OK: penso di averlo trovato. Mi farebbe piacere sapere cosa ne pensate voi:
il mio codice partiva da questo metodo:
Window:ListViewMouseButtonDown() Method
che riceve come parametro un oggetto della classe:
ListViewMouseEvent Class
cio' che non ho fatto e' verificare la classe in oggetto... e le sue
sottoclassi.... Ebbene nella classe ControlNotifyEvent Class ho trovato la
proprieta' ControlNotifyEvent:Control Access (The Control object that
generated this event.). Questo dovrebbe spiegare (forse) tutte le domande
che mi ero e vi avevo posto. Che ne pensate ?


 che mi ero e vi avevo posto. Che ne pensate ?
Cavoli l'ho trovato per davvero:
questa e' l'istruzione per accedere al campo RAGSOC1 della datalistview n. 1
Trim(oListViewClickEvent:control:Server:FIELDGET(#RAGSOC1 ))
Trovo interessante il fatto che nella digitazione del codice, in
corrispondenza della proprieta' :control, non abbia avuto nessun tooltip
d'aiuto, mentre sia per oListViewClickEvent che per SERVER ho avuto un
tooltip nero su sfondo rosso di aiuto. E' possibile che sia per il fatto che
control e' una proprieta' di una classe parente e non della classe chiamata
direttamente (appartiene alla classe CONTROLNOTIFYEVENT mentre l'oggetto in
questione apparteneva alla classe LISTVIEWMOUSEEVENT che discende dalla
CONTROLNOTIFYEVENT) ?
Sto Vo e' proprio forte. Comincio a sentirmi meglio....
Ciao a tutti,
Marco