import Rhino
import scriptcontext
def CircleCenter():
go = Rhino.Input.Custom.GetObject()
go.SetCommandPrompt("Select objects")
go.GeometryFilter = Rhino.DocObjects.ObjectType.Curve
go.GeometryAttributeFilter = Rhino.Input.Custom.GeometryAttributeFilter.ClosedCurve
go.GetMultiple(1, 0)
if go.CommandResult()!=Rhino.Commands.Result.Success:
return go.CommandResult()
objrefs = go.Objects()
if not objrefs: return Rhino.Commands.Result.Nothing
c’é qualche motivo particolare, che nei vari esempi, per lavorare con RCommon
viene fatto un primo controllo con Commands.Result e poi un secondo con if not objrefs:
ma se col primo if il risultato è Success conseguenzialmente objrefs deve essere per forza True
(considerando anche, che prima del Get in genere vengono impostati sia tipo di oggetto che gli attributi)
questo è un’altro esempio:
import Rhino
import scriptcontext
def IntersectLines():
go = Rhino.Input.Custom.GetObject()
go.SetCommandPrompt( "Select lines" )
go.GeometryFilter = Rhino.DocObjects.ObjectType.Curve
go.GetMultiple( 2, 2)
if go.CommandResult()!=Rhino.Commands.Result.Success:
return go.CommandResult()
if go.ObjectCount!=2: return Rhino.Commands.Result.Failure
crv0 = go.Object(0).Geometry()
crv1 = go.Object(1).Geometry()
if not crv0 or not crv1: return Rhino.Commands.Result.Failure
Si’, nei casi semplici lo trovo piu’ comprensibile,
la funzione risulta piu’ corta/compatta.
Aiuta ad avere sott’occhio un maggior numero di istruzioni.
Tra parentesi, objrefs non e’ un booleano, e’ una array di ObjRef, quindi il controllo dovrebbe essere sul fatto che contenga degli elementi o meno.
( O che eventualmente non sia None … Su queste cose la documentazione di RhinoCommon non sempre e’ completa )
Ma a parte questo …
Volevo fare una considerazione in generale, non specifica per questo caso.
Nessuno ci vieta di aggiungere un controllo in piu’.
( Meglio uno in piu’ che uno in meno )
Un controllo puo’ anche essere inserito solo per precauzione.
Un po’ di ridondanza di solito non guasta.
Inoltre alcune istruzioni, eventualmente comprendenti un controllo, possono essere state copiate da un altro programma.
Riguardo a questi esempi comunque puo’ benissimo esserci un motivo per inserire controlli ulteriori … come gia’ detto, non ho idea …
eeee potrebbe essere un motivo, in effetti io ho sempre il brutto vizio di pensare la programmazione, che serve ad una singola persona sul suo pc in locale, mentre sopratutto oggi è vero l’incontrario;
programmi che si condividono, file in remoto, dati presi chissà dove o da altri programmi,
ovviamente possono essere tanti motivi validi. a maggior ragione dopo questo ragionamento,
sarebbe utile conoscerlo, metterlo così a caso senza cognizione di causa non ha senso. . .
ps comunque pensandoci, e vero che in questo caso ho visto sempre (quasi) questo doppio controllo,
ma alcune volte già mi è capitato di vedere, parti di codici che non centrano proprio nulla in quel contesto.
edit:
chissà forse per chi vuole approfondire il discorso organizzeranno dei corsi specifici. . .
non proprio. . . essendo che come si è detto essere una guida carente
tranne alcune cose che si possono capire/imparare come autodidatti
avendo ovviamente già esperienze di altri linguaggi, non sono proprio
convinto che da soli si possa fare cose complesse (magari mi sbaglio)
mi sa un pò di quelle cose che solo poche persone hanno modo di poter accedere
quindi avevo immaginato una cosa come, corsi che fanno per diventare formatori ART
tipo un corso per developers C# per chi intendesse anche voler fare plug-in da rivendere
quello sopra era il mio pensiero, poi nel caso ho detto una corbelleria, allora si: era una battuta
Ah, OK. Parlavi delle informazioni su RhinoCommon in generale. Giusto.
Io mi concentravo solo sul valore restituito, in questo caso dal metodo Objects(), quando non viene selezionato nessun oggetto.
Si’, certo. Un tutorial sull’utilizzo di RhinoCommon sarebbe utile.
Soprattutto perche’ la libreria puo’ essere utilizzata anche per gli script, quindi in genere non da professionisti.
Ma al giorno d’oggi queste cose sono sempre meno comuni.
Ormai viviamo nell’era dell’approssimazione.
Non solo per scelta secondo me. Credo c’entri anche il gran numero di strumenti disponibili e la loro sempre maggiore complicazione. ( Nonche’ i prezzi ridotti rispetto al passato )
Sarebbe impossibile (almeno per quasi tutti) imparare bene come funziona lo strumento che devi usare.
Allo stesso modo sarebbe un lavoraccio star dietro con la documentazione a tutte le novita’.
Almeno al nostro livello …
eeee una bella differenza:
se acceptnothing=false e non seleziono nulla il result ritorna cancel
se acceptnothing=true e non seleziono nulla il result ritorna success
e quindi in questo caso il secondo controllo non’é necessario ma obbligatorio
Sergio non voglio fare il libro del perché, ma a questo punto la domanda si trasforma in:
a che scopo avere acceptnothing=true/false che ritorna come risultato success/cancel?
ps una riga di codice in più non cambia la vita, ma credo siano cose comunque importante da conoscere.
edit:
magari mi sbaglio, ma potrebbe essere acceptnothing=true/false collegato alla preselezione degli oggetti?
acceptnothing serve per confermare valori predefiniti e probabilmente anche gli elementi
preselezionati. Con questa opzione penso che result non restituisce success o cancel ma
success, nothing o cancel.
Se per ipotesi hai opzione acceptstring attiva ma il risultato che vuoi è la selezione di oggetti,
se immetti un testo il comando restituisce success ma il buffer della selezione è vuoto.
La possibilità di personalizzare l’input offerta da rhino consente di creare comandi iterativi
molto accattivanti ma richiede un controllo efficiente di result.
ottima oddervazione, quindi come quando si va a selezionare un oggetto punto,
e contemporaneamente nel caso, puoi anche digitare le sue coordinate,
il comando va a buon fine ma non è stato preso nussun oggetto.
edit:
stavo provando come far ritornare in result nothing
ho visto degli esempi che lavoravano con scritte/testi
e guardando la guida sembra che ci siano anche altri risultati:
