Cycling through memory variables dynamically with Evaluate 2

[dantheinfoman]

Hello Again!

I've had some success with your help using the EVALUATE function to loop through the fields when populating a listbox. You helped me here:

http://www.tek-tips.com/viewthread.cfm?qid=1749486

Now my question is somewhat of the reverse. I'm trying to loop through all these memory variables that will then populate a new record. It says there's a syntax error.
I was trying to use the same method, but I guess Evaluate only works when populating another item, not populating to an evaluated phrase.

Example: One wants to populate memory variables m.Cri1 through m.Cri15. Here's my failed attempt:

x = 1
	FOR i = 1 TO ALEN(aFieldList,1)
		IF aFieldList[i,nOperatorE] <> 0 then
			**NOT BLANK, IT HAS BEEN USED, SO ADD TO GROUP FILTER RECORD!
			
			EVALUATE(FIELD("m.cri" + ALLTRIM(x))) = aFieldList[i,nFieldE] + ";" + aFieldList[i,nNotE] + ";" + aFieldList[i,nOperatorE] + ";" + aFieldList[i,nCriteriaE]
			WAIT WINDOW EVALUATE("m.cri" + ALLTRIM(x))
			x=x+1
			
		ENDIF
	ENDFOR

Thanks for any advise. You guys are all geniuses!!!

Dan

 

[bborissov]

You should use macro here, not evaluate:

x = 1
FOR i = 1 TO ALEN(aFieldList,1)
    IF aFieldList[i,nOperatorE] <> 0 then
       **NOT BLANK, IT HAS BEEN USED, SO ADD TO GROUP FILTER RECORD!
       lcVariable = "m.cri" + ALLTRIM(x)
       &lcVariable. =  aFieldList[i,nFieldE] + ";" + aFieldList[i,nNotE] + ";" + aFieldList[i,nOperatorE] + ";" + aFieldList[i,nCriteriaE]
       WAIT WINDOW EVALUATE(lcVariable)
       x = x + 1 *** I don't even know why you need this.
    ENDIF
ENDFOR

Borislav Borissov
VFP9 SP2, SQL Server

 

[TamarGranor]

I'd actually turn this around a little and make the key line something like:

STORE aFieldList[i,nFieldE] + ";" + aFieldList[i,nNotE] + ";" + aFieldList[i,nOperatorE] + ";" + aFieldList[i,nCriteriaE] TO (FIELD("m.cri" + ALLTRIM(x)))

This uses neither EVALUATE() nor a macro, just a name expression. Any place that VFP expects a name and only a name, you can wrap an expression that results in the name in parentheses. For more info, look up "Name Expressions" in VFP Help.

Tamar

 

[dantheinfoman]

TamarGranor and bborissov, you are both absolutely brilliant! The only reason I had trouble with Borislav's helpful advise was my own fault. I had used an ALLTRIM instead of TRANSFORM and it kept giving me errors.

Brilliant, you guys. Thanks all!!

Dan

 

[Olaf Doschke]

Th e problem is solved, but you haven't understood what evaluate and what FIELD does:

EVALUATE(....) = ...

This can't work,, in the same way as "My String" = "Hello" or STORE "Hello" To "World" can't work as an assignment. You can only assign and store something into a variable, object or proprty, not into a value. Evaluate always results in a value, not in a variable or object or property, that's what its name comes from. There's a big difference in the right and left side of an assignment like say a=b, a is the target of the assignemt, therefore it must be something, which can store some value assigned to it, it is written to. B can be a literal, constant, variable, expression. anything having a value, it's read.

If you have memory variables the FIELD also has no sense at all. FIELD is about table fields, not memory variables.

Bye, Olaf.

 

[Olaf Doschke]

Second topic: I stringly suggest not to create memory variables with the same name as fields. It was and for some still is a normal way to do a buffered editing of a dbf record. Variables are much simpler creatad, than in your loop via SCATTER MEMVAR. You can then bind controls to the variables and later decide to save back to a dbf record with GATHER or not. Today we have buffers, you can put a table or cursor in a buffer mode and change it directly without copying to variables, you can then cancel to the old values with TABLEREVERT or save the buffer with TABLEUPDATE. Besides we now have SCATTER NAME objectvariable, which creates one variable with properties named as the fields of the scattered record, eg objectvariable.cri1 to objectvariable.cri3. And gather can also gather from such an object variable. You can even INSERT INTO sometabe FROM NAME objectvariable.

Besides VFP has a design, that may have been fortunate way back then, but not anymore - at least to me. It prioritizes table/cursor/view fields over variables. If you address some name without explicitly prefixing it with m. the current work area is scanned for a field of that name, a memory variable of that name is only used, if no field is found. VFP unfortunately is a bit dumb about this in several aspects: a) the current workarea is searched for a field again and again, b) if you give the current workarea alias name "m" the strictness of accessing memory variables via the m. memory object is broken. That's obviously easy enough to avoid, but the way VFP allows to adress a table field in the same way as a variable for reading from it makes this a source of hard to find errors, if you don't know the behaviour. Besides the similarity is not fully done, eg you can't use a field to assign to it, you'd always assign to the memory variable.

It's a bad decision to name variables var1, var2, var3 in the same way as it's a bad decision to name fields fld1,fld2,fld3. For memory variables you at least have arrays, if you dimension var[3] you can address var[1], var[2], var[3] aso by a variable 1 with values between 1 and 3 var is a solution to your problem not needing any specialty like macro substitution or name expression.

Keep it simple.

Bye, Olaf.

 

[dantheinfoman]

Olaf,

As usual, you've provided tons of insight and simultaneously enlightened and confused me. Thank you sir! I will definitely re-read this after a good night's sleep.

Thank you and all the rest for your thoughtful consideration and wisdom.

Dan