user function di excel con argomenti facoltativi

[wallace&gromit]

Ciao,
vorrei creare una user function in cui inserire 3 o 4 argomenti in funzione dei casi. Il modello funzionante è quello in cui chiedo sempre 4 riferimenti a celle, e inserisco 0 per il 4° valore, se non esiste una cella da calcolare, vorrei invece potere, in questi casi, inserire solo 3 riferimenti e lasciare alla parte vba interpretare come 0 il valore non inserito.

[Anthony47]

Esempio:

Codice: Seleziona tutto

Function LaMiaUdf(byRef PARAM1 as Range, byVal PARAM2 as Long, byVal PARAM3 as string, Optional byVal PARAM4 as Double = 0) As QuelCheServe

[wallace&gromit]

Perfetto! grazie mille, anche oggi ho imparato qualcosina (come spesso accade, l'avrò visto fare chissà quante volte, ma fino a quando non ne ho avuto bisogno non avevo mai usato la definizione optional).

[klingklang]

Ciao Anthony, approfitto della tua risposta per chiederti un chiarimento: in "teoria" mi è chiara la differenza tra ByRef e ByVal, ma spesso fatico a trovare dei casi in cui è utile/necessario usare il ByVal.
Certo quello che tu scrivi qui è solo un esempio di dichiarazione, ma ti chiedo: in una UDF, in quali occasioni passeresti un parametro come ByVal? Grazie mille per il tempo che vorrai dedicarmi

[Anthony47]

Non sono un fine conoscitore della teoria, quindi prendi quel che dico con le pinzette...
Intanto secondo me la documentazione ufficiale e' approssimata (secondo me mischia informazioni relative a VB con quelle relative a VBA; certamente mischia Procedures e Functions); ad esempio viene spesso detto che i valori passati byRef possono essere modificati (vedi https://docs.microsoft.com/en-us/office ... -statement e il glossario da lì richiamabile https://docs.microsoft.com/it-it/office ... reference) ma e' chiaro che una Function puo' solo modificare l'area del risultato.
Poi ci sono "cose" che possono solo essere passati byRef: in genere si tratta di Objects quali (i primi che mi vengon in mente) Range, Control, Table, Intervalli, Sheet, e mille altri.
Teoricamente, inoltre, un parametro passato byRef potrebbe cambiare contenuto durante il calcolo della Function; ad esempio per una macro onTime o altro evento esterno, e in questo caso la Function rischia di ragionare con dati che cambiano sotto il suo naso (salvo che non siano stati congelati in una variabile locale).

La mia "rule of thumb" e' di usare byRef quando si tratta di Oggetti (es un Intervallo) e negli altri casi byVal; quando si tratta di Range appena complessi, in genere ne copio subito il contenuto in un array locale (sia per congelarli che per le velocizzazioni del caso).
So che e' un po' poco, ma questo passa questo convento.
Hai una tua rule of thumb?

Ciao

[klingklang]

Ti ringrazio molto per la risposta. Non ho una rule of thumb (che ora so cos'è, anche se lo avevo intuito ): sinora esplicitavo il ByVal solo nei casi di conflitto di tipo. Esempio: se io scelgo un file con GetOpenFileName, la variabile che assegno a questa istruzione deve essere Variant, per tenere in conto la possibilità che l'utente annulli la finestra di dialogo senza selezionare un file (output = False).
Se però voglio elaborare il percorso del file aperto con una funzione, dovrei dichiararla come

Codice: Seleziona tutto

Function ElaboraPercorso(percorso as Variant) as String

Altrimenti incorerrei in un errore di compilazione. Ma se a quel punto del codice sono già sicuro che in quella variabile ci sarà una stringa di testo, posso aggirare il problema con

Codice: Seleziona tutto

Function ElaboraPercorso(ByVal percorso as String) as String

Non che all'atto pratico cambi poi tanto, ma per chiarezza preferisco comunque identificare il tipo già nella dichiarazione del parametro...
Beh, comunque la tua prassi non mi dispiace e potrei rubartela d'ora in avanti