Inaccurate results with Position>

[jculp]

I am having a problem with the Position> command. I ran my code to a breakpoint just below where this command is used, and could plainly see the text variable containing the substring, but the result variable was 0. This command has worked previously.

NOTE: I have also had problems today with Screen Capture commands not working properly, when they had worked previously. I have already tried rebooting, and also shutting down MSched and re-starting. That helped with the text captures, but not with this problem -- which is intermittent, by the way. Can't see any pattern to its variability, though.

Code: Select all

      VBEval>SetCell("%xlActive%",%r%,%msgAdd%,"%strText%"),nul
	  Position>complete,strText,1,result

	  If>result=0
	  	  Sub>LineCount,1
	  	  Press Down * 5
		  Let>Failed=1

The variable strText shows up in the debugger window as "Add complete", but the variable result=0. Have also tried it with %strText%, no difference. The VBEval> line does put the strText variable into Excel with the expected text in it.
[/code]

[JRL]

The Position> function is case sensitive. you have correct case in the posted example, do you have correct case in your script?

You might consider adding a line just ahead of the position line:

Let>strText={lower(%strText%)}

[jculp]

Thanks for the tip; I may make that a habit. For the current situation, the case is correct. The variable case is just as I typed it in my post, and you can see that the command is searching for the word with the same case.

The thing that is puzzling to me is the fact that it works some, but not all the time. And today is the first time I have had any problem at all with it, in over 3 weeks of testing, using it a lot.

I am compiling scripts for users who are not particularly computer-savvy, and this has me concerned, because unreliable results are worse than no macro at all. I can't afford to roll out something that is subject to unexplained glitches.

[Marcus Tettmar]

We need to see the full code really. Could be caused by something earlier in the script. E.g. you may have VAREXPLICIT set to 1. "1", or "complete" may inadvertently have been set to some other value (in which case VAREXPLICIT would help you). Supposing you'd accidentally used 1 in place of a result variable in some other command, 1, would now be a variable containing that result. So Position wouldn't start at position 1, it would start at whatever is now the value of 1. Perhaps complete is also a variable - containing some other value. Using the debugger, when you get to the Position command, look at the watch list and see if you can see a variable called "1" or "complete". Or dump all vars to the log file with _DUMP_VARS

Also use the variable explorer in the editor. To see all variables that get created by your script.

I am 100% confident in the reliability of the Position command. And I'll put my life on it. The issue is earlier in your script.

You could also try:

Position>{"complete"},strText,{1},result

Or:

Let>VAREXPLICIT=1
Position>complete,%strText%,1,result
Let>VAREXPLICIT=0

Either of those forces it to use the literal values. So if complete or 1 have become variables somewhere by accident, it won't matter.

But I'd still look closely at the watch list and work out where things are going wrong, because if "1" has become a variable you'll no doubt get problems elsewhere.

[bnc1]

I do not automatically assume that the poster's problem is a coding issue on his part. I can only say that I distinctly remember spending hours on what I thought was something wrong with my Position> code back in July of this year. Unfortunately I no longer have the code, or the proof that it was not my code which was at fault. This was the exact same time that I figured out that Macro Scheduler has a capture text bug.

http://www.mjtnet.com/forum/viewtopic.php?t=4934

[Marcus Tettmar]

Would still need to see the code in order to prove either way. If there is indeed a reproducable bug it will get fixed. Without code we cannot investigate and can only speculate. My hunch is an issue earlier in the script of the like described above and this needs to be checked.

The window text issue is another matter entirely. The issue described appears to be fixed in the latest development code which I hope will be ready for v11.

[bnc1]

The original poster made this comment :

NOTE: I have also had problems today with Screen Capture commands not working properly, when they had worked previously. I have already tried rebooting, and also shutting down MSched and re-starting. That helped with the text captures, but not with this problem -- which is intermittent, by the way. Can't see any pattern to its variability, though.

My point is that his problem with the Position> command may not be "another matter entirely" because I experienced something very similar... unexplained problem with Position> command and text capture issues.

I am looking forward to v11

[Bob Hansen]

I have never experienced any problems with Position in all the years I have used Macro Scheduler

Would like to see the code that causes this problem. Intermittent problems are always the toughest to troubleshoot. If code was available, then there could be scores of us testing for the cause.

Without the code, we have no way to confirm a problem exists with this function.

[jculp]

Thanks for the suggestions; I will go over my code looking for a use of "complete" as a variable. I'm thinking that Marcus is probably on the right track, and I slipped up and used a result test as a variable name in my latest round of edits to account for conditions which my users "forgot" to tell me about at first.

This has been a 3-day weekend for me, and I can't get to the total script right now. I'll try to post back with what I find sometime Tuesday, US Central time zone -- either problems with my code, or the code itself.

[jculp]

I searched my code for occurrences of "complete", and found that indeed I had inadvertently used it as a numeric variable. After changing that, the script is processing as expected.

The variable %complete% was later in my code than the Position test, but within the same Repeat loop, so I would always get expected results the first time through the loop -- even if processing a row that errored on another attempt -- but once %complete% was assigned a value, I would get unexpected results. Made it difficult to see what was happening.

I appreciate the prompt responses to this question. Without your assistance, I probably would have been stuck on this question for a couple more days, and had to spend a lot more time trouble-shooting.