Find all occurences of a string in a text?

Ok, I can find the number of times a string occurs inside a text using the "RegexMatchCount" expression. But I can't find how to get every occurence's index inside the text.

Anyone knows how to do this?

Normally you would be able to get all match indexes, but Regex implemention in Construct is a bit lacking. You have to get creative. You will need to use RegexSearch recursively until no match is found, each time passing a substring of the original string that goes from the index of the last match + length of match, to the end of the string.

Maybe you could execute some JavaScript that does it.

Yeah, that's what I thought, but I hoped somebody would come with a simpler method. Oh well, it was worth the try.

Thanks for replying.

EDIT : Javascript, maybe. I'll check into that (or do you have a link to point me in the right direction? )

you can try with

find(str(NumberORTEXT), "WhatYouSearchFor Must Match ")

One of the solutÑ–ons in this thread should work.

http://stackoverflow.com/questions/4009 ... -in-string

then execute it

https://www.scirra.com/manual/110/browser

See if this can help you :

— : The "find" expression would only return the index of the first occurence of the string inside the text, wouldn't it?

codah : Thanks... I just looked over those solutions but I don't understand javascript enough to know what I'd be doing. Beside, I think that they only show methods to retrieve the number of times a string occurs in a text, and not the index of every occurence of that string. I might be wrong though, since as I said I don't understand enough of it to know what's really going on in the code.

Magistross : Thanks, your example works fine. I get that I need to insert the string I'm looking for between the two \w* brackets. But I start being lost the moment I look at the javascript. I'd like to implement in a way so it uses or stores the occurences' indexes it finds instead of showing them to me in an alert message, but I don't know how.

Try this, no javascript. Stores the indices in a csv text variable.

codah This is a great way of doing it, thanks. And it seems pretty fast even when going through longer texts.

I've simplified it a bit and I think that's what I'm gonna be using then. Thank you.

codah This is a great way of doing it, thanks. And it seems pretty fast even when going through longer texts.

I've simplified it a bit and I think that's what I'm gonna be using then. Thank you.

A?esome. I'm always interested in how things can be simplified..

Well, let me remember... I basically removed a few "every ticks" conditions here and there (and left the events with no condition instead since they'll be processed one after the other in the function call anyway) and removed local variables (see file).

Also I finally meet someone else who uses the latest stable release, instead of the latest beta.

Well, let me remember... I basically removed a few "every ticks" conditions here and there (and left the events with no condition instead since they'll be processed one after the other in the function call anyway) and removed local variables (see file).

Also I finally meet someone else who uses the latest stable release, instead of the latest beta.

heh.. I just downloaded the beta! Because the stable freezes on me anyway..

About the 'everty tick', it's a choice thing for me. I prefer not to have any 'empty' lines because then I know C2 hasn't deleted any code due to me incorrectly removing an object that was in actually use.. So if I see emptiness, I know something is astray. I realise it's not necessary for functioning

As for local variables... it is better for debugging and easier to read IMO, especially a few weeks/months later when you revisit the code... As they say, "eschew obfuscation!" (and early optimisation).

That's cool.

Personally, since I've learned that sub-events are executed one after the other, I like to separate events - especially functions - into several "steps" to make it more clear. As or variables, I like to give them the shorter yet clearer name possible, and have as little as possible to make it less confusing.

In the end we both want our code to be simpler for when we (or somebody else) will have to look at it later, we just have different ways of doing it.