Newsgroup: it.comp.lang.visual-basic
Titolo: Piccolo esercizio

Osservate il codice seguente (VB6). Sapete dire a prima vista (senza prima
eseguirlo) come si comporta?
Public Sub Main()
Dim TheArray() As Variant
    Test TheArray
End Sub
Private Sub Test(Optional ByVal vArgs As Variant)
    If IsMissing(vArgs) Then
        MsgBox "No arguments"
    Else
        MsgBox "Passed some args..."
    End If
End Sub
Ora eseguitelo: cosa succede?
Avevate indovinato? No, vero?
Qualcuno è in grado di darmi una spiegazione?
O per lo meno di suggerire un workaround...
Bye
Raf

 
non ha molto senso passare un array per valore,
bisogna passarlo per riferimento (cioe' senza ByVal)

 bisogna passarlo per riferimento (cioe' senza ByVal)
Stavo per dare la stessa risposta.
Perň sottolineerei che piů che non aver senso il fatto č che VB non lo 
sOpporta, anche se essendo il Variant ad essere passato a VB che gli frega?
Ciao 

 ha scritto nel messaggio
news:43ff1a25$1...@news.unimib.it...

In generale è vero, ma in questo caso la sub Test è fatta per aspettarsi
qualunque cosa, non necessariamente un Array.
Raf

 essendo il Variant ad essere passato a VB che gli frega?
infatti non c'entra un tubo.
E' l'IsMissing che toppa e non la gestione dei parametri.
Provate passo-passo questo
Public Sub Main()
    Dim TheArray() As Variant
    Dim V As Variant
    V = TheArray
    Debug.Print IsMissing(TheArray)
    Debug.Print IsMissing(V)
End Sub
Ciao 


d'accordo, pero' se poi passi un array (anche se di variant)
VB si incacchia e ha ragione, e se passi un semplice variant
quindi senza le (), va tutto liscio......


anzi, penso di poter dire che non c'era niente di
trascendentale come l'OP voleva far credere!
Ciao

 End Sub
Comunque, non ho ben capito che razza di redirezioni faccia vb con array e 
variant in questo modo (secondo me dovrebbe comunque funzionare), ma il 
codice postato non ha molto senso: passare byval un array non inizializzato 
a che serve?
Scrivendo del codice sensato (cioč inizializzando l'array o passandolo 
byref) il problema si risolve.
Ciao 

 
altro spunto di riflessione: con il codice scritto cosi'
IsMissing non genera un crash, ma un semplice errore di run-time
Public Sub Main()
Dim TheArray() As Variant
    Test TheArray
End Sub
Private Sub Test(Optional ByVal vArgs As Variant)
    If IsMissing(vArgs(0)) Then


 ha scritto nel messaggio news:43ff1dc8$0$12595$4faf...@reader3.news.tin.it...

esatto! sono pienamente d'accordo,
ciao

 ha scritto nel messaggio
news:43ff1d95$1...@news.unimib.it...

Di "trascendentale" come lo chiami tu c'è il fatto che un programma costituito
da 2 semplicissime linee di codice "innocuo" causi una exception nel runtime di
VB... :-(
Bye
Raf

 ciao
Certo certo... ma questo lo so benissimo.
Ma d'altra parte chi di noi produce codice completamente bug-free ;-) ?
Nel programma originario che mi ha dato quel problema avevo creato una funzione
che accetta un parametro opzionale byval, il quale può essere indistintamente un
array oppure uno scalare.
In certe situazioni succedeva che l'array non venisse inizializzato prima di
venire passato, ma anziché incappare in un runtime error (che avrebbe avuto
molto più senso), il programma andava in crash "brutale", anche entro l'IDE,
rendendo più difficile il debug. Ma alla fine ci sono pur sempre arrivato.
Ho iniziato questo thread perché stupito dal fatto che con pochissime linee di
codice VB6 apparentemente innocue (niente API o ActiveX strani), fosse possibile
mandare in crisi il runtime di VB6 con un application error, non tanto perché
non sapessi già dove andare a mettere le mani.
Ciao
Raf

 molto più senso), il programma andava in crash "brutale"
Purtroppo secondo me il problema non poteva finire in un runtime error 
perchè la sintassi è perfettamente lecita.
C'è qualche buco nella IsMissing() che personalmente ho sempre evitato con i 
parametri opzionali e evitando i variant.
Ciao 


Scusate cerco di puntualizzare la mia opinione:
penso che il problema di fondo sia, non tanto un
baco nella IsMissing, ma piuttosto la sua implementazione
per cosi dire "blindata";
quando ismissing si aspetta un parametro array
(perche' cosi era stato dichiarato inizialmente) non
puo' effettuare l'allocazione della memoria richiesta
del *puntatore a un array* 1) perche' non inizializzato
e 2) perche' invece dell'array trova uno scalare:
in questi casi, qualunque routine scritta in C++ produrrebbe
un crash, ma non si tratta di un baco, ma soltanto di
una specifica implementazione che *volutamwente* non
prevede tutti i casi possibili.......
bye
Salclem

 ha scritto nel messaggio
news:4402acc3$1...@news.unimib.it...

No, scusami Sal per la pignoleria, ma le cose non stanno così.
Il tipo di dato accettato dalla IsMissing è VARIANT (OLE) e basta, non sta
scritto da nessuna parte che si aspetta un array.
Aprendo con OLEView la MSVBVM60.DLL si trova il prototipo: VARIANT_BOOL _stdcall
IsMissing([in] VARIANT* ArgName)
Significa che (teoricamente) potrei passarle qualunque cosa, specialmente se
questa cosa è (come nel mio primo esempio) il parametro di una sub.
Dovrebbe essere l'implementazione della stessa IsMissing a testare il contenuto
del variant e comportarsi diversamente in caso si passi un array, altrimenti *È*
un bug. Anzi, è un ORRIDO bug, perché potrei capire se venisse restituito un
valore errato, ma che vada in crash proprio non lo concepisco (in nessun
linguaggio di programmazione).
Comunque alla fin fine non ha una grossa importanza perché
a) si parla di un prodotto in via di obsolescenza, che tra breve non sarà più
supportato da mamma MS
b) è comunque semplice fornire un workaround:
Public Function IsMissingFix(v As Variant) As Boolean
    If IsArray(v) Then
        IsMissingFix = False
    Else
        IsMissingFix = IsMissing(v)
    End If
End Function
Ciao
Raf

 IsMissing([in] VARIANT* ArgName)
Dato che IsMissing e' previsto per ricevere un variant, ma poi tu questo variant lo
dichiari come array di variant in origine, e invece poi al momento della chiamata gli passi un variant scalare... scusami ma c'e'
una incongruenza...
Secondo me chi ha scritto il codice di IsMissing *non ha voluto prevedere*
questo particolare *errore di programmazione*, sarebbe stata un'eccessiva
pedanteria (vabbe' che e' visual BASIC... ma troppo BASIC diventerebbe...
"Visual Terric Terric" !! :))
Quindi, ribadisco, ma accettala come una mia personale opinione e non
come un assioma da confutare a tutti i costi, secondo me non si tratta
di bug dell'IsMissing ma di un tuo errore di scrittura del codice.
Ciao
Salclem

 prevede tutti i casi possibili.......
Capisco il tuo punto di vista ma non lo condivido.
Non stiamo parlando di c++, ma di VB, dove il compito del runtime è proprio 
quello di mettere il programmatore al sicura da codice pericoloso.
La sintassi della IsMissing vuole un variant, e se io gli passo un variant 
*PRETENDO* un risultato coerente con la documentazione, e comunque di sicuro 
non può sfociare in un GPF.
Comunque se vuoi farti due risate leggi questo articolo
http://support.microsoft.com/kb/891406/en-us
In particolare il titolo, le note in fondo e lo status.
Ciao
-- 
Free .Net Reporting Tool - 
http://www.neodatatype.net
 

 di bug dell'IsMissing ma di un tuo errore di scrittura del codice.
Che il mio codice contenesse un errore *logico* č fuor di dubbio e l'ho detto
sin dall'inizio!
Ciao
Raf


e va bene!
stavolta mi hai convinto, il sottoscritto aveva torto!
Ciao
Salclem

 ha scritto nel messaggio news:4402f244$1...@news.unimib.it...

...anzi mi avete convinto (lotta impari, due contro uno!)