quando si entra in un blocco select case può accadere che siano le prime condizioni ad essere verificate
In altri linguaggi c'è la possibilità di uscire anticipatamente con una istruzione break
In Gambas non esiste e presumo che vengano comunque controllate tutte le altre condizioni .
esiste un modo per uscire quando la condizione si è verificata?
Non capisco la tua domanda. Se io scrivo una select, come la seguente:
Select Case $Cosa
Case "E"
bSw = True
Case Else
bSw = False
End Select
If bSW 'cioè = true
a=100
else
a=0
endif
essa verifica le condizioni di presenza o non presenza di "E" e svolge il compito previsto per le due condizioni al suo interno; mai fuori. Può tuttavia verificarsi il caso in cui alla fine della select, possono esistere possibilità diverse di esito. É il caso previsto nell'esempio che ho riportato sopra. In un caso simile bisogna interrogare, fuori dalla Select, lo status della variabile interessata e prendere pertanto una nuova decisione.
Se non ho chiarito il concetto o se ho capito male quello che volevi dire. sono pronto a ritornare sull'argomento, anche con altri esempi.
:ciao:
Interessante questa questione.
Ho sperimentato questo codice:
Public Sub Form_Open()
Dim a As Byte = 1
Select Case a
Case 0
Print "0"
Case 1
Print "1 primo"
Case 1
Print "1 secondo"
Case 2
Print "2"
End Select
End
ed ho ottenuto il risultato 1 primo . Non viene, cioè, anche verificato l'altro valore 1.
Pertanto, sembrerebbe :-\ che, una volta verificata la corrispondenza di un caso, si esce subito dal Select Case ritenendosi inutile la verifica degli altri eventuali casi previsti, qualunque valore essi assumano.
Pertanto, sembrerebbe :-\ che, una volta verificata la corrispondenza di un caso, si esce subito dal Select Case ritenendosi inutile la verifica degli altri eventuali casi previsti, qualunque valore essi assumano.
Infatti, è così. In un certo qual modo è simile ad un processo "if". Ecco perchè è necessario decidere dentro la "Select Case" il da farsi di fronte al verificarsi di una condizione. Inoltre le condizioni verificabili in una "Select Case" di Gambas accettano solamente il termine di confronto logico "=". Non è possibile scrivere "<, > <=, >=" si può perciò scrivere:
Select Case $Cosa
Case "E"
Print "Evviva"
Case "0", "1" Testa se contenuto di $Cosa="0" o $Cosa="1"
Print "Numero: " & $Cosa
Case Else
Print "Campo vuoto"
End Select
[ CASE LIKE Espressione [ , ... ]
con il quale si può usare una espressione regolare. Ho provato ma mi dà errore.
Forse... intende una cosa di questo genere: :-\
Public Sub Form_Open()
Dim s As String = "alibaba"
Select Case s
Case "simbad"
Print "Simbad"
Case Like "alib*"
Print "Alibaba"
Case "abukir"
Print "Abukir"
End Select
End
:-X
Avevo provato a fare questo:
Public Sub Form_Open()
Dim prova As Byte = 5
Select Case prova
Case Like > 4
Print "E' più di 4"
End Select
End
Mi da unexspected '>'.
Vorrei riportare, comunque, una discussione apparsa ieri nell M.L.I. proprio circa Like nel Select Case:
« I am trying to parse a text file that contains key,value pairs like:
Name=Malarky
Size=10
BackImage[N]=sometext
FrontImage[S]=sometext
etc
using a construct like
For idx = 0 to sourcearray.max
Select Upper(Split(SourceArray[idx],"+")[0])
Case "NAME"
blah blah
Case "SIZE"
blah blah
Case Like "BACKIMAGE[*]"
blah blah
Case Like "FRONTIMAGE[*]"
blah blah
End Select
Next
This fails because
is being interpreted as a regular expression where I need to escape the regexp "[]" meaning.
Trying to use escapes like
Case Like "BACKIMAGE\[*\]"
fails as \[ is an unknown escape sequence.
Any clues?
tia
Bruce »
« Sorry, I have over simplified that. I also need to discern lines like
from lines like
so
wont work.
Bruce »
« OK. If the lines above (from your most recent mail) are literal strings,
then you'll need something like:
Case Like "BACKIMAGE\\[*\\]"
' The compiler transforms "\\" to a literal "\"
' so that you end up with the right expression.
to match
but since you want to distinguish between, e.g.
and
- why would you use "Case Like", i.e. a
regular expression at all? These are distinct strings you want to keep
distinct, no need to group them by regular expressions then?
Regards,
Tobi »
« Oops, since you want
literal at the end of your strings which are
actually three characters with special LIKE meaning, you must use:
Case Like "BACKIMAGE\\[\\*\\]"
Just in case you still need regular expressions and I misunderstood
something.
Regards,
Tobi »
« Case "BACKIMAGE[[]*]"
Case "BACKIMAGE[[]*][[]*]"
Is that what you want?
Escaping '[' character in regular expression is done by using "[[]" or "\\[". (see the documentation of LIKE).
Regards,
--
Benoît Minisini »
« This expression (the first one of yours) would match
"BACKIMAGE[", "BACKIMAGE*" or "BACKIMAGE]"
but not
Using the []-LIKE notation, the correct expression would be
but I'd prefer the "\\" style for readability in this case. CMIIW.
Regards,
Tobi »
« Ahh! Ok, I mis-parsed your expressions. They _will_ match
but also something like
which may or maybe not what Bruce wants...
Tobi »
...continua......
« Thanks guys,
That was the escape sequence I needed. I just couldn't see it in the
LIKE help page. I guess I'll have to put that "Read EVERY word in the
help page!" sign back up above my desk.
By way of demystification, we have over 1500 text parameter files that
represent 50 or so objects. These have evolved over several generations
of the software which now has too much "back compatibility" code in it.
So we now need to standardise all these parameter files to the current
release "shape".
The "xxxIMAGE<subtype>" parameters now looks for example like
BACKIMAGE[N][1][0]=filename
BACKIMAGE[E][1][0]=filename
BACKIMAGE[E][2][0]=filename
but different parameter files might have
BACKIMAGE[N]=filename,1 (at ver 1.0)
BACKIMAGE[E]=filename,1,2 (at ver 3.0)
BACKIMAGE[N][3]=filename (at ver 3.x)
etc
(and xxxIMAGE is only one example of the problem!)
Given an arbitrary parameter file there is no way to detect which
software version it comes from. This is further exacerbated by the fact
that individual lines in a file may accord to different versions of the
parameter syntax. So each line in the file has to be parsed to detect
its' likely syntax version and reprocessed accordingly.
Hence,
Select Upper(Split(SourceArray[idx],"=")[0])
Case Like "BACKIMAGE[[]*]" 'looks like a ver 1.0 to 3.0 syntax, so
' parse the second half of the line and pick the correct process
Case Like "BACKIMAGE[[]*][[]*]" ' looks like a ver 3.x syntax, so
TargetArray[idx]=ReformatBackImage_3x(SourceArray[idx])
Case Like "BACKIMAGE[[*][[*][[*]" ' is current syntax, so
TargetArray[idx]=SourceArray[idx]
etc etc
Thanks again
Bruce »