Instr problem in VB5
in [Visual Basic]
|
Prev: Combinations
Next: 7-bit and News Servers
From: dpb on 3 Jun 2010 15:51 Dennis Rose wrote: .... >> Look at the results of sotoo >> >> For i = 1 to Len(StringToSearch) >> Debug.Print Ascw(Mid$(StringToSearch,i,1)) >> Next i .... > > You hit the nail on the head!! Yes, what I (and several others kept trying to tell you) it's the only reason the comparison would fail was that one or the other had a problem and since you built the search string it was therefore almost certainly that there was something in the source string you didn't expect... > > My "StringToMatch" showed as: <name part="first"> > The "StringToSearch" showed as: <name part=3D"first"> > > even though it displays the same as StringToMatch > > What does the "3D" after the equal sign mean or do? &H3D is an "=" sign in normal ASCII. It appears there's an embedded double-byte or other malformed character. What does the ASCW() code values show instead of the characters? You'll need to determine whether this is a constant coding problem in the source you're receiving or an aberration and deal with it appropriately. Easiest, of course, would be for the creator of the malformed string to fix it on their end (unless, of course, their engine is parsing it somehow). I "know nuthink" to quote Sgt Schultz re: XML/HTML/whatever so whether there is some meaning inside there somebody else will have to answer. Either way, you now know why the INSTR() fails; now you have to figure out what is the proper workaround for your situation. --
From: Dennis Rose on 3 Jun 2010 17:23 "dpb" wrote: > Dennis Rose wrote: > .... > > >> Look at the results of sotoo > >> > >> For i = 1 to Len(StringToSearch) > >> Debug.Print Ascw(Mid$(StringToSearch,i,1)) > >> Next i > .... > > > > You hit the nail on the head!! > > Yes, what I (and several others kept trying to tell you) it's the only > reason the comparison would fail was that one or the other had a problem > and since you built the search string it was therefore almost certainly > that there was something in the source string you didn't expect... > > > > > My "StringToMatch" showed as: <name part="first"> > > The "StringToSearch" showed as: <name part=3D"first"> > > > > even though it displays the same as StringToMatch > > > > What does the "3D" after the equal sign mean or do? > > &H3D is an "=" sign in normal ASCII. It appears there's an embedded > double-byte or other malformed character. > > What does the ASCW() code values show instead of the characters? > > You'll need to determine whether this is a constant coding problem in > the source you're receiving or an aberration and deal with it > appropriately. Easiest, of course, would be for the creator of the > malformed string to fix it on their end (unless, of course, their engine > is parsing it somehow). I "know nuthink" to quote Sgt Schultz re: > XML/HTML/whatever so whether there is some meaning inside there somebody > else will have to answer. > > Either way, you now know why the INSTR() fails; now you have to figure > out what is the proper workaround for your situation. > > -- > . > The "extra" ASCW() code values shown are: 51 and 68
From: Henning on 3 Jun 2010 17:43 "Dennis Rose" <DennisRose(a)discussions.microsoft.com> skrev i meddelandet news:A9E56BD6-4D3A-4DA2-B8EC-15DA172F4658(a)microsoft.com... > > > "dpb" wrote: > >> Dennis Rose wrote: >> .... >> >> > OK, I give up trying to do it the INSTR way, since I never could get it >> > to >> > work using all of your good suggestions. >> >> .... >> >> Makes no sense unless the string isn't what you think it is but you've >> never provided any information to determine what it really is or isn't >> to debug from... >> >> Look at the results of sotoo >> >> For i = 1 to Len(StringToSearch) >> Debug.Print Ascw(Mid$(StringToSearch,i,1)) >> Next i >> >> For i = 1 to Len(StringToMatch) >> Debug.Print Ascw(Mid$(StringToMatch,i,1)) >> Next i >> >> And I'm pretty sure you'll find the issue... >> >> -- >> . >> > > You hit the nail on the head!! > > My "StringToMatch" showed as: <name part="first"> > The "StringToSearch" showed as: <name part=3D"first"> > > even though it displays the same as StringToMatch > > What does the "3D" after the equal sign mean or do? On google it seems that =3D is something very common in XML. XML source: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D <table-wrap id=3D"tab01" position=3D"float"> /Henning
From: Helmut Meukel on 3 Jun 2010 17:56 "Dennis Rose" <DennisRose(a)discussions.microsoft.com> schrieb im Newsbeitrag news:D7D4E362-D73B-4333-A64A-B307777D216A(a)microsoft.com... > > > "dpb" wrote: > >> Dennis Rose wrote: >> .... >> >> >> Look at the results of sotoo >> >> >> >> For i = 1 to Len(StringToSearch) >> >> Debug.Print Ascw(Mid$(StringToSearch,i,1)) >> >> Next i >> .... >> > >> > You hit the nail on the head!! >> >> Yes, what I (and several others kept trying to tell you) it's the only >> reason the comparison would fail was that one or the other had a problem >> and since you built the search string it was therefore almost certainly >> that there was something in the source string you didn't expect... >> >> > >> > My "StringToMatch" showed as: <name part="first"> >> > The "StringToSearch" showed as: <name part=3D"first"> >> > >> > even though it displays the same as StringToMatch >> > >> > What does the "3D" after the equal sign mean or do? >> >> &H3D is an "=" sign in normal ASCII. It appears there's an embedded >> double-byte or other malformed character. >> No, some characters gets masked (encoded) using their hex values instead of the character. To distinguish those hex values from normal numbers and characters they are preceded by a =. But if the original text contains a =, then that must be masked too. =3D denotes a = in the original text. It's the same principle as using "" or chr(34) to get a " into a vb string. Helmut.
From: dpb on 3 Jun 2010 18:15
Helmut Meukel wrote: ..... > =3D denotes a = in the original text. > It's the same principle as using "" or chr(34) to get a " into a vb string. .... Ah, of course...see, I said I didn't know XML encoding conventions... :) -- |