POSITION> Function Needs to be Documented Better

[Waldo]

I've used several other program languages but have NEVER seen the behavior shown by the POSITION> command while searching for substrings when the search is initiated from other than the first character.

EXAMPLE:
let>string=ABCDxxxEFG
Pos>xxx,string,4,ptr

Most other programs would return 5 as the resultant pointer (ptr).
Macro Scheduler returns a 2

Every other programming language I've used returns the pointer in absolute terms related to the original string. Macro Scheduler apparently returns the pointer relative to a substring beginning at the start-search index.

This is crazy behavior, if not an outright bug.
At the very least, the documentation should reflect the behavior & an example given.

[support]

For some reason I wasn't aware of this. Now that I am I will ensure it is put on the to do list.

With 7.3 you can of course do this instead:

Let>x={Pos("xxx", "ABCDxxxEFG")}

[Waldo]

Thanks.....

And by the way... my hat is off to you all for a superb product.
Your recent addition of complex expressions is a GREAT improvement.

What impresses me most is that you put such great emphasis on product
improvement by following customer suggestions--a guaranteed path
to success!

Waldo

[support]

Just to let you know this is fixed in the next release.

[Waldo]

Thanks....
I didn't know quite how you would handle the fix to this bug, since many macros have probably already been written that adapt to the faulty behavior. A version fix that corrects the pointer beheavior would render those programs faulty. On the other hand, that's a good reason for programers to READ the documented changes accompanying a new software release.

Again, thank you for responding to my concerns. I am impressed.

Waldo

[Bob Hansen]

It is important the the fix in the next release is backwards compatible and will not require earlier scripts to be redone.

This could be a big problem.

Maybe in your wisdom the solution will provide both, that would be good. Example add another parameter=relative/full position with relative as the default for backwards compatiblily

Another variation might be a variation of Position to indicate the nth instance of a character(string) inside a string, vs. indicating a start position to start the search.

Position>substring,string,start,result,relative/full,ncount, where ncount represents the number of instances to search for.

Examples:
Position>d,abcdabcdabcdabcd,1,result,full,3 would return a result=12 for the third instance of the letter d.
Position>c,abcdabcdabcdabcd,4,result,full,3 would return a result=15 for the third instance of the letter c, starting from the 4th character.
Position>c,abcdabcdabcdabcd,4,result,relative,3 would return a result=12 for the third instance of the letter c, starting from the 4th character..

[support]

Hmmm. Frankly I'd consider this a bug. The original poster was right - the current behaviour is very unusual for this type of command. I'd therefore prefer to fix it as to how it should work and should always have worked than to leave an option for it to work the old wrong way.

To make it backward compatible would mean to make it's default behaviour work the wrong way. While it would be possible to make it work the right way it would seem bizarre to new users to have to add an optional parameter to make it work the right way.

To default it to the new way but set a value to make it work the old way would mean old scripts would need a minor change anyway. So there would be nothing to gain in an option.

I need convincing ...

[Bob Hansen]

If the only choice is to make existing scripts start to fail, or to leave it as is, then there is no choice.....LEAVE IT ALONE, AS IT IS NOW.

I am sure that I have HUNDREDS, mabe over a Thousand scripts that I have created at mutliple sites in multiple countries. There is NO WAY that you can now make them inoperable. And I am only one user.

After all of these years of use, you cannot justify a decision to make existing scripts no longer work. Will you pay for my time to go to my customers sites, and review all the scripts that were done, looking for that command, and modifying it? When I get calls that scripts are producing wrong results that mean bad decisions have been made, will you be willing to pay for the cost of those bad decisions?

I suspect you may have some legal obligations, in addition to the obvious ethical obligations, to not cripple scripts that have already been created and implemented.

================
As I noted above:

Maybe in your wisdom the solution will provide both, that would be good. Example add another parameter=relative/full position with relative as the default for backwards compatiblily

Position>substring,string,start,result,relative/full

Make the last parameter optional with the default set to Relative. That would make it compatible with all existing scripts.

If command has 4 paramaters, then result = relative as it is now.
If command has 5 paramaters, then use Relative or Full to determine selection.
=============================

Whatever change is made must be backwards compatible. I don't care if you call it a bug, an enhancement, a new feature, an anomoly, etc. Those are just words.

MJT has always done an excellent job with updating the program, and I am sure you can come up with a method to insure no changes must be made to existing scripts that use POSITION command.

While it would be possible to make it work the right way it would seem bizarre to new users to have to add an optional parameter to make it work the right way.

I would suggest leaving it alone. Forget the additional parameter. No additional parameter means no possible confusion. Don't try to change it even by making it backwards compatible.

The existing documentation and the syntax is correct and has worked for all these years for all existing users. The "right way" is the way it has been used for all these years.
This is not a bug. This is your language. You define the syntax. You provide the documentation and examples. I am sure if we took a closer look at some of the other commands, we would find some other syntax differences that are slightly different from some other scripting languages. Can we look forward to changing those also? This is your language.

In any case, this does not need to be done in the next release. Take the time to do this correctly. Do not rush something into place that will kill existing scripts. There is nothing wrong with the existing syntax. This works very similar to a normal MidString fucntion. Is that so bad? So, it is slightly different from some other scripts. So what? MJT should continue to be a Leader not a Follower.

NO CHANGE IS THE CORRECT RESPONSE

[support]

Ok, point taken. I must admit I had wronly assumed that since the result was wrong for the index offset more than one noone would be using it with an index that isn't 1. But, you've convinced me otherwise.

I just want to ensure bugs are fixed. However, we've always tried to ensure backwards compatibility and have only not done so where there was no alternative. If I remember rightly this has only happened once.

[Bob Hansen]

Thank you......

Once again you demonstrate why MJT is such a superior group! It is great to be working with an organization that does listen to their user base, and responds in a timely and correct manner.

Now I can continue to recommend Macro Scheduler to other users when I see a need for this product on other technical forms and user groups.

Thanks again......

PS:

1. I do agree that the existing documentation could be changed, per the original posting, to provide an example with an offset greater than 1. That will make the understanding easier as was requested.

2.The availability of an offset different from one makes this an especially useful tool. Allows one to ignore many instances in front part of string and eliminates the need to count those earlier instances.