One thing I did notice was that my simple long string manipulation codes and the Word Wildcard Find Replace codes fall down in some Forums where “nested” code tags using code tag pairs of similar types are used. That is to say these sort of strings will not give the desired results:
Code: Select all
[color=Green]Gre[color=Blue]Blue[/color]en[/color]GreBlueen )
In some other Forums you get this: ( In other words you can do it )
GreBlueen
In fact , my simple long string manipulation codes will fall down for strings containing any nested BB Code code tags such as this:
Code: Select all
[CENTER][I]Wild Things. You make my heart sing. They make everything….. Groovy[/I][/CENTER]__ CENTER __ __ __ __ CENTER __
_.. and then
__ I __ __ __ __ I __
I doubt a wild code solution would solve the problem of where “nested” code tags using code tag pairs of similar types are used. ( Although, I did not think initially it was possible to it in the Wild Card string given here at all :) )
Anyway, I thought for completeness to wrap it up I would have a go.. and modify my simple long string manipulation way to also allow for that case of where “nested” code tags using code tag pairs of similar types are used… , .. It turned out to be a good practice in that tricky thing called “ recursion”.
So I did that like this:
The following modifications were necessary:
_1) I changed the main part of the code to a Function
_2) I need to modify the part of the code that caches a second occurrence of a [/ when stepping backwards through the characters in the total string.
( _...Just to recap: Previously such a case as this _..
Code: Select all
hadg[b]TextToBeBold[/b][/I]For the new code that second end tag is taken as possibly belonging to a nested BB Code code tag pair, that is to say the first tag would initially be considerd as possibly valid_......)
_...........
So, I have my original string in a variable, strBBCode , “held” in an initial Calling routine.
That variable itself is effectively “taken” into the Function. In other words that variable itself is, As it were, Referenced within the Function.
Additionally the Function “takes” As a Value the current character position, which initially ( as given in the first instance by the Calling routine ) , will be the end ( or length in characters ) position of strBBCode.
The general progression of the Function is similar to my last code: The Function steps backwards through the string, trying to find a complete end code tag. Once found a further tag is then looked for.
A small difference in the Function is that when a valid tag pair is found, instead of removing it, the text of that pair is replaced within the mains string, strBBCode , by some arbitrary character. ( Finally when back in the original Calling routine these are removed in one go ).
The major difference: “Recursion”…. Here goes with a pseudo like short explanation
My Function is a set of written Instructions that VBA can follow.
When my main routine Calls my Function, that has the effect of pseudo like making a copy of the instructions and passing that to VBA. VBA obediently then follows the instructions.
“Recursion” is when a routine, as is the case here, has a code line that within it that “Calls itself”. So pseudo like, in running / following the copy of the instructions, VBA is suddenly given a similar set of instructions again.
VBA is written to handle the situation of being given the same instructions again, in a similar way as what we might do. The following happens:
The initial copy of the instructions is “set aside” or frozen along with all values held in any variables assigned in the first copy run. VBA then starts following the second made copy of the instructions, which may include assigning variables again. These variables will share the same name as those in the first copy but are independent usually.
So coming back to my actual Function:
If a new Function copy begins, this is instructed to Refer to the unique main string strBBCode “held” in the original Calling routine. As Value for the current position in the backward stepping search is this time not the main string strBBCode length, but rather the position of the end ] in the currently found second sequential end code tag.
Here are some example situations that can occur:
_ With no more nested code tag pairs, the second Function will complete the entire string, other than the possible code tag pair search “frozen” in the first Function.
When the first function resumes, ( which occurs when the second function ends ) , the initial code tag pair search is completed.
_ If a further nested code tags section is found by the second function, this results in a third Function starting. That third Function would complete all but the two pairs searches “frozen” . At completion of the third Function, the second and then the first Functions with their respective code tag pair search would be completed.
Another scenario would be a double nesting such that there are three sequential end code tags. Once again a second followed by a third Function would be started. Once again, the third Function would complete all but the two pairs searches “frozen”. At completion of the third Function, the second and then the first Functions with their respective code tag pair search would be completed.
One can imaging many more scenarios.
I would not put money on my final code being full proof. I have a feeling that by chance it does catch all possible scenarios, but I am not totally sure. But one thing is for sure is that the Find Replace Wildcard approach is by far the simpler, and I expect I will probably use that for simplicity, and do any modification manually incase it does not catch anything.
Thanks again for the help on this one
Alan
Here is that code and a bit more colorful explanation to it in three posts staring here:
http://www.excelforum.com/development-t ... ost4591310" onclick="window.open(this.href);return false;
or here
http://www.excelfox.com/forum/showthrea ... #post10122" onclick="window.open(this.href);return false;