Sergey,

Thank you for that suggestion. I agree with that and it does make the code much easier to read and more manageable. I changed all those IF..ENDIF statemens to DO CASE.. ENDCASE, but I was still experiencing the same issue.

I have been watching the variable "lcStr" in the Watch window and it does indicate the correct value in that window. However, as I said in my first note, I can hover my mouse over several instances of the "lcStr" and see it's value in a tooltip. But when I hover over the lines that are important to the example I am testing:

>CASE !LIKE("*DEHYDRATE*", lcStr) ;
OR LIKE("*TC*",lcStr)

or this line

>CASE LIKE("RT/DEHYDRATE", lcStr) OR LIKE("DEHYDRATE", lcStr)

no value shows. I can step through it in Debug and see in the Watch window that lcStr = RT/DEHYDRATE but it simply ignores the CASE that it's suppose to step into. I don't understand it.

I have changed my "CASE" logic to avoid those situations and now I have all the expected possibilites covered. If something "un-interpretable" is found, the user will be prompted with a question as to whether or not they want to continue and will be shown the "un-interpretable" data.

You also mentioned:
>>LIKE("RT/DEHYDRATE", lcStr) is the same as "RT/DEHYDRATE" == lcStr.

Is one method better than the other? Is there a reason I should use one method in some instances and another method in others?


>Hi Elgin,
>
>If you want to monitor some variable, put it into watch window. If debugger doesn't show value of variable under mouse, it doesn't mean that this value changed. My guess is that problem is in the program logic which is hard to follow because of nested IF's. DO CASE ENDCASE would be more appropriate in this case.

DO CASE
>CASE LIKE("RETEST 1 YEAR", lcStr)
>	REPLACE ss WITH "A"
>CASE !LIKE("*DEHYDRATE*", lcStr) ;
>	OR LIKE("*TC*",lcStr)
>	DO CASE
>	CASE LIKE("RETEST", lcStr) ;
>			OR LIKE("*TC*", lcStr) ;
>			OR LIKE("*RETEST IFT*", lcStr) ;
>			OR LIKE("*RETEST DIELECT*", lcStr) ;
>			OR LIKE("*RETEST NN*", lcStr) ;
>			OR LIKE("*THERMAL CLEAN*", lcStr)
>		REPLACE ss WITH "U"
>	CASE ThisForm.RecError("Standard Screen", lcStr, upsino)
>		REPLACE ss WITH "??"
>	OTHERWISE
>		RETURN .F.
>	ENDCASE
>CASE LIKE("RT/DEHYDRATE", lcStr) OR LIKE("DEHYDRATE", lcStr)
>	REPLACE ss WITH "A"
>CASE ThisForm.RecError("Standard Screen",lcStr,upsino)
>	REPLACE ss WITH "??"
>OTHERWISE
>	RETURN .F.
>ENDCASE
>

BTW, LIKE("RT/DEHYDRATE", lcStr) is the same as "RT/DEHYDRATE" == lcStr. Is this what you intended?
>
>>Below is a section of code I am using to create a cursor for a report. My question is this: Why on the lines I have marked with Asterisks does the variable "lcStr" not contain the same reference value that all the other references to it do. I am checking this by hovering my mouse over it in Debug. In some places it shows a value and in others it doesn't. That's messing up my results. Why wouldn't it contain the same value? Does it have something to do with all the IF.. ELSE.. ENDIF nesting I'm doing here?
>>
>>Thank you for your help.
>>