Find String with Wildcard

[deeverd]

Good morning,

Even though I've been coding awhile, I'm assuming my question is rather basic, which is why I placed it here. Unfortunately, it's something I haven't yet figured out how to do but would be of tremendous help to know and understand.

Is it possible to perform a find function with a wildcard? In the past, I've only used wildcards with filters.

Specifically, I want to retrieve the text from between two html tags, such as getting the text between "<i>" and "</i>"
In other words, I would like to ask the program to find any specific start and ending html tag and then give me all the text that is in between them.
Is there a common or straightforward way to accomplish that task?

Thanks in advance for whatever info anyone can send my way.

Cheers,
deeverd

[dunbarx]

Hi.

You can use the "offset" function twice. First to find the char immediately following the starting tag, and second to find the char just preceding the second tag. Those two values will be the text between the tags.

You can then use that function, skipping the first tag pair, to find all subsequent pairs. In LC 7 and above, I believe, the itemdelimiter can consist of more than one char, and you could do it that way as well.

Craig Newman

[deeverd]

Hello Dunbarx,

Thanks so much for the reply. I am vaguely familiar with offset as well as matchText, and have seen the example of offset in the manual, which I looked at again just before making my initial posting, but having never used either of those functions, I'm still at a loss over how to put them to work. It's probably a lot to ask, but if you could supply a small example of that type of offset script, it would be extremely helpful. Again, sorry to have to ask.

Cheers,
deeverd

[dunbarx]

I do not mean to torture you, but, well, why not?

Make a field with some text in it. Somewhere in the middle of that text, place your two tags, so that there is text on either side of the tag pair, as well as text between. Make a button. Put this into its script:

Code: Select all

on mouseUp
   put offset(">",fld 1) into startChar
   put offset("<",fld 1,startChar) into endChar
 answer char startChar + 1 to (startChar + endchar) - 1 of fld 1
end mouseUp

Now then. What is going on? Step through the handler and watch. Note that the second offset uses the "chars to skip" (see the dictionary). Do you see why we had to add the two offsets, and why we had to add or subtract one char place in each case? Can you see a way so that you do not have to do all that math in line 3, but rather might do it in lines 1 and 2, to make line 3 simpler? I wrote it this way so that when you step through the handler it reads better.

How can you now go on to the next tag pair?

Get going.

Craig

[deeverd]

Thanks so much Dunbarx,

According to Homeland Security, a little torture is good for the soul.

That script looks like something I can definitely work with now, especially after my repeated failed tries. Although I have to admit, I'm amazed at how many things I've learned in the past even during those tortured times when I couldn't find the exact right way to get a particular unfamiliar function to work. Thank goodness for this forum and people like you!

Now it's time for me to roll up my sleeves and get it to work for me.

Really appreciate it.

Cheers,
deeverd

[dunbarx]

A followup to make sure you have no free time at all today. Can you use the "find" command instead? This will allow you to find the string "<|>" instead of just one or the other of "<" or ">". This may make management easier, since you do not have to bypass the trailing ">" in each tag pair, though you will have to keep track of your starts and ends manually, since there is no "chars to skip" in the "find" command.

And if LC 7 has the itemDelimiter able to be defined as a string, as I mentioned, that is another and simpler way.

Craig

[deeverd]

Yep, I always use "find" for similar situations. Just thought there might be something faster or more elegant. Basically to locate the start point of something, I'll find it and then grab the foundChunk, delete the info out of foundChunk that's not needed, then go for the end point of something and do the same thing. By adding a char to the start and subtracting a char from the end of those two points, I then have a list of starting and ending chars for the text in between.

With the use of find and foundChunk, I can also set it up in a repeat to grab multiple instances of the same type of start and end points. After playing with the offset for awhile now, I don't see any way of getting it to grab the text in between various start and end points if there is more than one similar set in the same field. In other words, it seems to only grab the first pairing it sees and I don't see a way of telling it to now go on to the second pair. I do, however, see some very important uses for offset in other things I'll be building, so it's a great new thing to learn.

As for your other advice about the itemDelimiter in LC7 being able to be defined as a string, I'll happily confess my ignorance and admit that I haven't quite wrapped my head around that idea yet. I know what a delimiter is (/,|;) etc., but are you saying that I can now use something like "<b>" as a delimiter? I'm not quite sure though how to use it as the start and end points for getting or affecting the text in between. But it sounds like an interesting concept.

Cheers,
Allen

[jacque]

Anything that accesses a field will be slower than almost any other method, so using "find" will be one of the slowest ways to gather information. Craig's offset suggestion is the best one, though once you get it working I'd tweak the example to get the text of the field and then gather all the data from the text variable. That would eliminate most of the overhead.

[dunbarx]

but are you saying that I can now use something like "<b>" as a delimiter

Yes indeed. And this is, unassumedly, a fabulous enhancement to the itemDelimiter. Fabulous.

Craig

Did I mention it was fabulous?

[deeverd]

Hi Jacque,

I totally agree about using find, and definitely keep it to a minimum. It was a while before I realized that it took literally thousands of times longer to perform certain finds than it does to use an array (timed it by milliseconds so I know I'm not exaggerating).

Anyway, just wanted to say that I remember attending one of your conference classes at the Las Vegas LiveCode (RunRev) conference. You did a great enough job that I still remember your class. Hope you're still speaking at the conferences.

Cheers,
deeverd

[jacque]

Thanks deeverd, that's very rewarding. So many people helped me along the way and I have always felt it only fair to pay the debt forward. There are a lot of us here who feel the same way, which is what makes this forum so valuable and responsive. So far I'm still giving conference sessions so with luck you'll see me again.