import Rhino
import System.Drawing
import scriptcontext as sc
class GetLines(Rhino.Input.Custom.GetPoint):
def OnDynamicDraw(self, args):
args.Display.DrawLine(Rhino.Geometry.Point3d(10,0,0), args.CurrentPoint, System.Drawing.Color.Green, 2)
gp = GetLines()
gp.Get()
dovrebbe essere possibile (ma non so come) far funzionare il codice senza la classe usando solo la def?
Premesso che non sono certo un esperto di OOP …
… In questo caso non credo sia possibile.
Derivare una nuova classe da GetPoint e ridefinire il metodo OnDynamicDraw e’ proprio
l’operazione prevista da RhinoCommon per personalizzare il display quando si seleziona il punto.
Emilio ma nemmeno con un altro metodo?
chiedo anche per altre funzioni usando sempre display si è obbligati a passare per le classi?
Mi e’ capitato di usare i DisplayConduit
DisplayConduit Class (rhino3d.com)
Ma funziona allo stesso modo: derivi una classe e ridefinisci dei metodi.
Il poco che so io finisce qui.
Serve qualcuno piu’ esperto.
mi fido della tua analisi, credo che al 99,99% è come dici tu 
avevo voglia a fare prove, a cambiare qualcosa o a fare ricerche
(facevo la fine del criceto in un labirinto senza uscita ahahahah)
la questione è che in questo caso ci capisco ancora meno degli altri codici in RCommon
ricordo una piccola infarinatura ma nulla più, quegli args adesso mi sfuggono i rifrimenti,
presumo (forse) che indicano il parametro all’interno nelle parentesi della classe ma non sono sicuro
come anche args.Display.DrawLine nella guida ho trovato: DisplayPipeline.DrawLine Method
come mai nel codice tra Display e DrawLine manca Pipeline?
la stessa cosa anche con args.CurrentPoint ho trovato GetPointDrawEventArgs.CurrentPoint
(non comprendo come potrei scrivere un codice senza dover cercare la soluzione negli esempi in rete)
I riferimenti li cerchi nella documentazione, come fanno tutti.
Vai alla classe GetPoint e cerchi il metodo OnDynamicDraw
GetPoint.OnDynamicDraw Method (rhino3d.com)
Leggi cosa dice riguardo al parametro:
e
Type: Rhino.Input.Custom.GetPointDrawEventArgs
Current argument for the event.
Clicchi sul link e vai a vedere cos’e’ quel GetPointDrawEventArgs
Trovi questo:
GetPointDrawEventArgs Class (rhino3d.com)
dove ovviamente ci sono gli elenchi con proprieta’ e metodi per gli oggetti di quella classe.
Ad esempio ci trovi la proprieta’ CurrentPoint che e’ utilizzata nell’esempio che hai postato.
Se ti interessa quella proprieta’, ci clicchi sopra … e cosi’ via.
Per ora mi limito alla prima domanda, per non fare confusione … 
Non c’è molto da dire emilio. È un sistema che consente di aggiungere ad un evento l’esecuzione di un codice personalizzato garantendo che il tutto venga eseguito in modo sincrono e sicuro.
@emilio lo so che tempo fa me lo spiegasti già:
la parola chiave self dovrebbe riferirsi alla def,
mentre la parola chiave args a cosa è riferita?
Ciao Salvio.
Eeeeh … non so come rispondere …
A prima vista sembrerebbe la domanda di qualcuno con le idee parecchio confuse … ma …
… E’ difficile capire cosa sai gia’ e cosa non sai, per il solito motivo.
Chiami le cose con nomi diversi da quelli che si usano di solito, e che ci permettono di capirci tra di noi quando parliamo di queste cose.
Per cui non so se tu alcune cose le conosci, ma le chiami con nomi diversi, oppure non le conosci ancora.
In ogni caso per cercare di rispondere alla tua domanda dovro’ a mia volta usare altri termini, per i quali vale lo stesso discorso …
Sai a cosa mi riferisco, oppure per un certo termine e’ necessaria una spiegazione ? 
Comunque, provo a rispondere, per quello che so certo, e anche a verificare se i termini che uso ti sono chiari o meno.
( Ovviamente uso i termini che conosco io, e che credo di aver imparato da libri, riviste e poi Web, newsgroup ecc. … Qualcosa a scuola … Non ne conosco altri … 
)
Prima cosa: self e args non sono parole chiave.
( Vedi che gia’ dall’inizio fatichiamo a capirci … 
)
Sono i nomi dei due parametri del metodo OnDynamicDraw, che suppongo appartenga alla classe GetPoint.
GetPoint.OnDynamicDraw Method (rhino3d.com)
Come vedi nelle documentazione linkata qui sopra, viene mostrato un solo parametro, che viene chiamato e
GetPointDrawEventArgs e
Questo dipende dal fatto che, dato che parliamo di un metodo, nel C# il primo parametro e’ implicito, cioe’ non si scrive quando definisci il metodo, e corrisponde a this, che in C# e’ una parola chiave, e si riferisce all’oggetto della classe GetPoint che associamo al metodo quando richiamiamo il metodo stesso, in pratica il valore che scrivi prima del nome del metodo, seguito dal punto, quando chiami il metodo.
In Python, diversamente da C#, questo parametro e’ esplicito, cioe’ viene effettivamente scritto insieme agli altri parametri quando definiamo il metodo, e convenzionalmente viene chiamato self.
Ricapitolando, nella definizione del metodo (OnDynamicDraw), quando vediamo scritto self, e’ un parametro che rappresenta l’oggetto collegato a quella chiamata di metodo.
Anche se nel metodo che tu riporti, il parametro self non e’ utilizzato.
Per args, per fortuna, la cosa e’ molto piu’ semplice.
E’ un semplicissimo parametro di una funzione/metodo.
E dalla documentazione vediamo che ha tipo GetPointDrawEventArgs
Cliccando sul nome del tipo, possiamo saltare alla sua documentazione:
GetPointDrawEventArgs Class (rhino3d.com)
Dove, tra le altre cose, possiamo trovare la proprieta’ Display, che vediamo usata nel metodo che hai riportato.
DrawEventArgs.Display Property (rhino3d.com)
Come anticipato, per cercare di rispondere alla domanda ho utilizzato diversi termini ‘tecnici’, diciamo cosi’ 
, che non so se siano chiari o meno, per cui provo a elencarli, senza nessun ordine particolare.
Alcuni sono specifici della OOP, altri no.
Nel caso ci sia qualcosa su cui hai dei dubbi, se vuoi, dillo e vediamo di fare un ripasso …
tipo di dati
classe
funzione / routine
oggetto
metodo
… e se vogliamo esagerare …
metodo di istanza e metodo di classe, detto anche metodo statico …
parametro di funzione
proprieta’
parola chiave
Se c’e’ qualcos’altro di poco chiaro, dillo.
si, mi manca solo il resto di tutta la spiegazione di RCommon 
eeee hai ragione, in VisualStudio con il C# alcune cose le ho capite più facilmente essendo che editor evidenzia meglio tutte le parole chiavi ecc poi sottolinea gli errori dandoti anche la soluzione, quindi paradossalmente mi sto trovando più agevolato a scrivre C# con VS che con l’editor di Python.
(vabbè comunque non’é una giustificazione anche perché senza VS nemmeno quel poco di C# potrei fare)
Bene !
Entro quest’anno probabilmente uscira’ Rhino 8, con i suoi script in C#.
… Ma non ho idea se e quanto sara’ semplice usare VS per scriverli, ne’ ovviamente se avrai occasione di aggiornare Rhino …
Comunque e’ sempre una possibilita’ in piu’.
eeee magari sarebbe una bella notizia, da quello che avevo letto ormai sembra quasi una chimera. . .
comunque per il fatto di trovarmi meglio col C# (usando VS) era per dire che ho problemi col RCommon
appunto, in pratica RCommon che è scritto in C# lo si può importare in Python ma con le regole di C#
vedi sono tutte queste cose che messe insieme rendono contorto tutto (ovviamente così è, ce lo teniamo)
infatti credevo che self e args fossero parole come this invece sono semplici parametri
(che però mi sfugge come utilizzarli) in C# this viene preceduto per indicare una variabile
della classe, seguendo un paio di tutorial, questo concetto mi è ben chiaro nella mente.
mentre per self e args anche vedendo dei tutorial su Py non riesco ad associarli al loro scopo
(la cosa bella e che lo stesso youtuber spiega C# e Py, per C# l’ho compreso, in Py sono più sconfuso)
mmmm e allora sono veramente molto confuso, essendo che da quello che ricordavo dal libro su Py consigliatomi, mi sembrava che self venisse usato nelle def senza dover usare le classi
(debbo trovare qualche esempio al riguardo che vada bene per me)
questo è proprio una cosa che mi sfugge:
args dovrebbe riferirsi a Rhino.Input.Custom.GetPoint?
ma cercando Display.DrawLine non lo trovo ma se filtro la guida trovo: DisplayPipeline.DrawLine
Perche’ ?
McNeel rilascia una nuova release ogni tre anni circa…
Rhino 7 e’ uscito a novembre 2020.
E sul forum USA hanno previsto l’uscita di Rhino 8 intorno all’autunno di quest’anno.
Dove vedi chimere ?
Cosa intendi ?
Di quali regole parli ?
Python non puo’ usare la sintassi di C#, deve per forza usare la sua.
A cosa ti riferisci esattamente ?
Come credevo di aver spiegato qui:
this in C# corrisponde a self in Python.
( E comunque sono entrambi dei parametri )
E’ semplicemente l’oggetto usato per richiamare quel metodo.
E cosa dovrebbe indicare self, se non lo usi per un metodo ?
Poi, scusa, l’esempio lo hai postato tu:
Dichiari una classe e dentro la classe definisci un metodo,
che come primo parametro ha self
Anche questo credevo di averlo detto:
Cosa intendi con “riferirsi a Rhino.Input.Custom.GetPoint” ?
Riferirsi in che senso ?
self, come abbiamo detto (N volte) e’ l’oggetto della classe GetLines che usi per richiamare il metodo.
( E, per le regole OOP, non possiamo farne a meno )
Lo scopo di args e’ mostarto sempre nell’esempio che riporti:
In questo caso lo usi per richiamare DrawLine
In generale, hai capito cosa fa l’esempio che hai postato ?
… A cosa serve OnDynamicDraw() ?
Hai provato lo script per vedere in pratica cosa succede ?
Inoltre, se non sbaglio non hai problemi a utilizzare le funzioni di rhinoscriptsyntax.
Cosa cambia con RhinoCommon ?
Cos’e’ che ti confonde ?
Per entrambi i casi si tratta di richiamare delle funzioni, passandogli i parametri richiesti.
E’ la stessa cosa.
Se ben ricordo, avevamo fatto anche dei semplici esercizi con RhinoCommon, forse con punti e linee.
E con quello non avevi nessun tipo di problema, andavi spedito.
Perche’ i metodi di Rhino.Geometry.Point3d li capisci al volo, mentre con quelli di Rhino.Input.Custom.GetPoint ti blocchi ?
Che differenza ci vedi ?
Sono semplicemente due classi di RhinoCommon, cosa cambia ?
… Comunque ormai sono convinto di non essere in grado di spiegarti queste cose.
Secondo me ci vorrebbe qualcuno che veda, e spieghi, le cose in maniera diversa.
Mi sa che io e te non riusciamo a capirci su RhinoCommon …
mi spiace, ho fatto perdere la pazienza anche a te. . . 
cerco io di spiegarmi in altro modo, forse agevolo la cosa. ad es:
mi sono fatto un piccola panoramica di alcune spiegazioni che mi avete dato in passato su tale argomento
class Classe1:
def metodo1(self):
return 2*2
def metodo2(self):
return 3*3
print Classe1().metodo1()
print Classe1().metodo2()
class Classe2:
a = "Stampa Classe2"
print Classe2().a
questi semplici esempi li ho scritti adesso, cosi come mi sono venuti in mente senza cercare nulla
quindi si può dire che il mio livello in Py per gli OOP è questo che si vede dal codice postato sopra.
ora tanto per far comprendere quale sia il problema con RCommon e che il codice postato ad inizio
3d non sarei riuscito a scriverlo nel modo corretto quindi significa che mi mancano dei riferimenti
uno dei problemi che riscontro sta nel fatto che mi manca il riferimento della sintassi
quando scrivo in rhinoscriptsyntax associandolo ad un as come di consueto rs
andando a scrivere rs. dopo il punto mi compare il menù a tendina di quello che posso fare
mentre in questo caso con gli OOP questo non accade quindi non ho il riscontro per cui riesco a trovare il riferimento di cosa fa cosa, a cosa serve e come lo fa. ricordando delle volte che mi è stato detto che non scrivo nel modo consueto la sintassi dei codici, essendo che vado a disassemblare il codice di un esempio riducendolo al minimo, togliendo tutte le verifiche, controlli ecc so che non’é il modo corretto ma questo mi serviva proprio a questo per capire ogni pezzo del codice che scopo avesse, il suo utilizzo e come disporlo nella sintassi, se poteva andare da solo oppure doveva essere abbinato ad altro codice, quindi facevo 1000 prove per prendermi i riferimenti dopo aver visto il suo funzionamento nella pratica.
tipo; nel codice appena postato sopra, se scrivo: print Classe1(). dopo il punto non mi compare nulla
in questo caso esempio da me postato è semplicissimo e quindi so a priori come deve essere scritto e fin qui non ci sono problemi, ma nel caso di un codice in rete per RCommon (dove già è contorto di per se) oltre al fatto di essere abbastanza complessi, in questo caso mi perdo non avendo nessun riferimento con cui posso trarre conclusioni. ad es; se scrivo: args.Display.DrawLine dopo args. non mi compare nessun menù, quindi non ho nessun riscontro dove verificare se ciò che scrivo sia nel modo corretto, come altra cosa che proprio non capisco Display.DrawLine dove lo trovo nella guida? ho cercato più volte, ma come già detto trovo solo DisplayPipeline.DrawLine
(come faccio a sapere cosa posso fare con Display.DrawLine se non trovo quali metodi/proprietà ha?)
No, no, non c’entra la pazienza.
E’ la difficolta’ a capirsi, e non c’e’ niente di strano.
Non sono ne’ un programmatore ne’ un docente.
Sono uno tra tanti che si diverte con gli script …e’ logico che non sia in grado di spiegare le cose come farebbe un professionista.
Gia’ ho il mio bel da fare a cercare di capirci qualcosa io …
Giusto
… Sbagliato.
Scrivendo rs scrivi il nome del modulo/namespace e quindi l’editor sa a cosa ti riferisci e ti mostra l’elenco delle funzioni.
Stessa cosa se scrivi Rhino.Geometry.Point3d.
E’ il nome della classe quindi l’editor ti mostra i vari metodi ecc.
Stessa cosa ancora se inizi a scrivere un costruttore:
L’editor ti mostra i parametri richiesti.
Ma se invece del nome di un modulo o di una classe, tu scrivi il nome di una variabile,
Non succede niente.
L’editor non e’ cosi’ intelligente da sapere il tipo del valore salvato nella variabile …
Non pretendiamo troppo !
Ma tu lo sai cosa c’e’ nella variabile, e allora, se vuoi vedere l’elenco di metodi e soci,
ti sposti un una nuova linea e scrivi (temporaneamente) il nome della classe, cosi’ vedi il tuo bell’elenco.
Dopo ovviamente cancelli quel nome, che non c’entra niente col tuo script, e vai avanti.
E’ una cosa che mi e’ capitato di fare diverse volte …
Certo, l’editor non ha in memoria l’elenco dei metodi di Classe1, non fa parte delle librerie standard di Rhino.
Di nuovo, non e’ in grado di fare quello che chiedi.
Quando scrivi una classe, sei tu che devi sapere come utilizzarla.
Come ho detto prima, basta che tu scriva (temporaneamente) il nome della classe e vedrai che l’editor ti mostra l’elenco che cerchi.
Scusa, avevo scritto:
Cosa c’e’ di poco (o niente ) chiaro in quanto avevo scritto ?
Avevo inserito il link diretto, nessun bisogno di cercare e trovare niente …
Comincio a pensare che parliamo lingue diverse … appunto …
E comunque come regola generale, ripeto …
Tu hai una variabile per cui cerchi metodi e proprieta’
OK, questa variabile avra’ un tipo/classe.
( Nel caso sopra la classe e’ Rhino.Input.Custom.GetPointDrawEventArgs )
Vai nella documentazione e vai a vedere quella classe e ci trovi gli elenchi che cerchi.
Anche qui, cosa c’e’ che non va bene in questa procedura ?
analizziamo una cosa per volta:
come precisato precedentemente, ho riscontrato una maggiore facilità usando VS proprio perché anche nel codice semplice che ho postato, scrivendo la Classe mi ritorna i metodi oppure le proprietà da me scritte.
mentre usando il codice ad inizio 3d usando Python in Rhino questo non accade:
quindi in pratica a questo punto non posso aver nessun riscontro usando editor Py in Rh come facevo con rhinoscriptsyntax mentre scrivevo il codice. a questo punto dovrei sapere già tutta la sintassi e quali metodi e come usarli per poter scrivere un codice.
(oppure come fanno in tanti, copiarli da qualche parte in rete, senza sapere nulla a riguardo)
Emilio se posso chiederti (se hai voglia) di commentare l’analisi della sintassi dello script a inizio 3d?
ti dico la mia interpretazione, poi nel caso mi correggi sui punti sui quali ho i dubbi:
class GetLines(Rhino.Input.Custom.GetPoint):
GetLines è il nome della classe mentre Rhino.Input.Custom.GetPoint è un suo parametro giusto?
def OnDynamicDraw(self, args):
mentre qui abbiamo OnDynamicDraw come nome della def
il parametro self che corrisponde alla classe stessa quindi a GetLines
mentre args corrisponde al parametro della classe quindi (Rhino.Input.Custom.GetPoint)
ora non so se quanto detto sopra sia corretto, essendo che quando vedo scritto:
args.Display.DrawLine
args.CurrentPoint
per me è come se vedessi scritto questo:
Rhino.Input.Custom.GetPoint.Display.DrawLine
Rhino.Input.Custom.GetPoint.CurrentPoint
dimmi pure. . .
Ho spiegato nel messaggio precedente come fare, con tanto di immagini.
Certo, se confronti l’editor di RunPythonScript con VS, Rhino uscira’ sempre battuto.
Uno fa parte di un singolo comando tra i tanti di Rhino (software sviluppato da McNeel con qualche decina di programmatori. )
L’altro e’ un prodotto, indipendente, di Microsoft … non so se mi spiego.
Contento te …
No, almeno di solito non si usano queste parole …
GetLines e’ una nuova classe, derivata dalla classe GetPoint.
Qui GetPoint e’ la cosiddetta classe base.
Sempre questione di OOP, la famosa ereditarieta’ per cui una classe derivata eredita dalla classe base tutti i suoi metodi, proprieta’ ecc.
Detta anche metodo… OK, nota che qui stai ridefinendo il metodo OnDynamicDraw ereditato dalla classe madre GetPoint,
quindi, dopo questa definizione, la classe GetLines avra’ un metodo OnDynamicDraw diverso da quello di GetPoint.
Questo e’ il meccanismo che ti permette di personalizzare la grafica durante l’input del punto.
Quando il tuo script esegue l’input usando un oggetto della classe GetLines, Rhino a un certo punto richiama il metodo OnDynamicDraw e quindi tu vedrai a schermo cio’ che hai programmato in quel metodo.
( Meccanismo di solito chiamato ‘callback’ )
Per la precisione, corrisponde a un oggetto appartenente alla classe GetLines.
Quello che tu ottieni scrivendo ad esempio
gp = new Rhino.Input.Custom.GetLines();
Quello che qui e’ salvato nella variabile gp.
Ma dato che questo metodo non lo richiami tu, ma lo richiama Rhino, non preoccuparti troppo di quell’oggetto.
No, non so dove tu abbia preso questa idea, ma non corrisponde a come funziona C#.
Come ho gia’ detto tre volte, da qui …
GetPoint.OnDynamicDraw Method (rhino3d.com)
… vediamo che il parametro args, che qui e’ chiamato e, appartiene alla classe
Rhino.Input.Custom.GetPointDrawEventArgs
E’ scritto chiaro nella documentazione, non c’e’ bisogno di inventarsi cose diverse …
Tra l’altro, le classi non hanno parametri.
I metodi hanno dei parametri. e i tipi di dati generici hanno dei parametri, ma e’ un altro discorso.
Le classi non hanno nessun parametro.
No, quelle proprieta’ appartengono alla classe Rhino.Input.Custom.GetPointDrawEventArgs
GetPointDrawEventArgs Class (rhino3d.com)
OK Emilio credo che qualcosina sul funzionamento adesso (forse) l’ho capita
ps per quel poco che sono riuscito a cogliere, posso dire che è ancora più contorta di quanto pensassi. . .
pps cerco di organizzare meglio le idee cosi espono le nuone congetture, sperando in qualche miglioria. . .
Eh … se parli di classi derivate e metodi ridefiniti … non posso darti torto.
Sono le complicazioni della OOP, che purtroppo e’ stata adottata su larga scala dalla maggior parte dei linguaggi, ormai da lungo tempo.
Comunque sono cose che non capita spesso di dover fare con RhinoCommon.
Diciamo che hai preso in esame un esempio tra i piu’ tosti …
Anzi direi che sono cose che spesso non si affrontano subito quando inizi ad usare RhinoCommon,
prima si fa esperienza con cose piu’ semplici.
In generale di solito basta utilizzare direttamente i vari metodi ecc. delle classi, cosi’ come utilizzi le funzioni di rhinoscriptsyntax.