Question in re LIKE in VB 2005

[al jones]

I have the following line of code in a procedure (Function
SearchDesigner( ByVal stringreader As String) As String)

If LCase(stringrea der) Like "*" & LCase(arDesigne r(i, 0)) & "*" Then
return(designer (i,1))

I'm reading a line of text from a font file / extracting copyright
information from a font file (dependng on the type of font) then pass this
line of text to this function. I parse my way though an array which looke
like
designer(i,0) (designer(i,1)

(c) Character Character
by Character Character
© Characte Character

The first two seem to operate properly but the third seems to return true
in any case where the string 'character' is found as if the © symbol were
being ignored. The string 'Contains 5 character' matches '© Characte'
which is giving me many false positives, if this make sense to anyone,
could you offer a suggestion as to why it's occurring and how to make it
behave as I'd like.

//al

[Andrew Morton]

al jones wrote:

I have the following line of code in a procedure (Function
SearchDesigner( ByVal stringreader As String) As String)

If LCase(stringrea der) Like "*" & LCase(arDesigne r(i, 0)) & "*" Then
return(designer (i,1))

I'm reading a line of text from a font file / extracting copyright
information from a font file (dependng on the type of font) then pass
this line of text to this function. I parse my way though an array
which looke like
designer(i,0) (designer(i,1)

>(c) Character Character
by Character Character
© Characte Character

The first two seem to operate properly but the third seems to return
true in any case where the string 'character' is found as if the ©
symbol were being ignored. The string 'Contains 5 character' matches
'© Characte' which is giving me many false positives, if this make
sense to anyone, could you offer a suggestion as to why it's
occurring and how to make it behave as I'd like.

It isn't clear to me exactly what you're trying to do. Where you've written
"Character" , is that meant to represent a single character, or is it sample
text?

Is designer(0,0)=" (c)" and designer(0,1)=" Character Character" or is
designer(0,0)=" (c) Character" and designer(0,1)=" Character"?

What is the relation of the variable arDesigner to the variable designer?

What values are you passing in for the value of the variable "stringread er"?

Would String.IndexOf be a better comparer for your purpose?

Andrew

[al jones]

On Thu, 21 Sep 2006 10:40:51 +0100, Andrew Morton wrote:

al jones wrote:

>I have the following line of code in a procedure (Function
SearchDesigner (ByVal stringreader As String) As String)

If LCase(stringrea der) Like "*" & LCase(arDesigne r(i, 0)) & "*" Then
return(designe r(i,1))

I'm reading a line of text from a font file / extracting copyright
information from a font file (dependng on the type of font) then pass
this line of text to this function. I parse my way though an array
which looke like
designer(i,0) (designer(i,1)

>>(c) Character Character
by Character Character
© Characte Character

The first two seem to operate properly but the third seems to return
true in any case where the string 'character' is found as if the ©
symbol were being ignored. The string 'Contains 5 character' matches
'© Characte' which is giving me many false positives, if this make
sense to anyone, could you offer a suggestion as to why it's
occurring and how to make it behave as I'd like.

It isn't clear to me exactly what you're trying to do. Where you've written
"Character" , is that meant to represent a single character, or is it sample
text?

Is designer(0,0)=" (c)" and designer(0,1)=" Character Character" or is
designer(0,0)=" (c) Character" and designer(0,1)=" Character"?

What is the relation of the variable arDesigner to the variable designer?

What values are you passing in for the value of the variable "stringread er"?

Would String.IndexOf be a better comparer for your purpose?

Andrew

Anton, scratch this - it's not this part of the program that's the problem
- after a little further examination it's when I load the array from a file
that the copyright symbol (and others outside the ascii range, it appears)
are being dropped.

BTW, that was confusing - but Character is a font designer - so it's his
name, not a 'symbol'

I'll post a different question as soon as the coffee's ready. //al

[al jones]

On Thu, 21 Sep 2006 10:40:51 +0100, Andrew Morton wrote:

al jones wrote:

>I have the following line of code in a procedure (Function
SearchDesigner (ByVal stringreader As String) As String)

If LCase(stringrea der) Like "*" & LCase(arDesigne r(i, 0)) & "*" Then
return(designe r(i,1))

I'm reading a line of text from a font file / extracting copyright
information from a font file (dependng on the type of font) then pass
this line of text to this function. I parse my way though an array
which looke like
designer(i,0) (designer(i,1)

>>(c) Character Character
by Character Character
© Characte Character

The first two seem to operate properly but the third seems to return
true in any case where the string 'character' is found as if the ©
symbol were being ignored. The string 'Contains 5 character' matches
'© Characte' which is giving me many false positives, if this make
sense to anyone, could you offer a suggestion as to why it's
occurring and how to make it behave as I'd like.

It isn't clear to me exactly what you're trying to do. Where you've written
"Character" , is that meant to represent a single character, or is it sample
text?

Is designer(0,0)=" (c)" and designer(0,1)=" Character Character" or is
designer(0,0)=" (c) Character" and designer(0,1)=" Character"?

What is the relation of the variable arDesigner to the variable designer?

What values are you passing in for the value of the variable "stringread er"?

Would String.IndexOf be a better comparer for your purpose?

Andrew

If you'd consider looking for me, I've corrected the problem statement in
'TextFieldParse r - reading tab delimited file' TextFieldParser is dropping
some letters from the text it's reading. French diacriticals, German
umlauted and copyright symbols that I can identify at the moment.

Again, thanks for looking //al