IIF(...) and IF..ENDIF issue

[torturedmind]

good day to all.

i have the following codes:

m.qtyused = m.qtyused - ;
	IIF((m.qtyused > 1) ;
	AND (ALLTRIM(m.payclass) = 'C') ;
	AND (INLIST(ALLTRIM(m.ecode), "O2", "O4", "O6", "O8", "10")), 1, 0)

IF m.qtyused > 1 ;
		AND (ALLTRIM(m.payclass) = 'C') ;
		AND (INLIST(ALLTRIM(m.ecode), 'O2', 'O4', 'O6', 'O8', '10'))
	m.qtyused = m.qtyused - 1
ENDIF

my question is, why is it that the first code doesn't deduct 1 from variable m.qtyused while the second one does? simple as it may seem but it left me scratching my head.


kilroy
philippines

"Once a king, always a king. But being a knight is more than enough."

 

[alvechurchdata]

qtyused = 10
payclass="C"
ecode="O2"

m.qtyused = m.qtyused - ;
    IIF((m.qtyused > 1) ;
    AND (ALLTRIM(m.payclass) = 'C') ;
    AND (INLIST(ALLTRIM(m.ecode), "O2", "O4", "O6", "O8", "10")), 1, 0)
?qtyused

IF m.qtyused > 1 ;
        AND (ALLTRIM(m.payclass) = 'C') ;
        AND (INLIST(ALLTRIM(m.ecode), 'O2', 'O4', 'O6', 'O8', '10'))
    m.qtyused = m.qtyused - 1
ENDIF

?qtyused

This works for me in VFP9 and prints out 9 then 8.

My first test failed because I typed "02" with a zero not "O2" with a capital "o".

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Mike Lewis]

Kilroy,

Works as expected for me as well. Are you sure the code you posted is exactly what you executed?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[jimstarr]

A scenario that could explain this behavior is that you are using different beginning values for m.qtyused in your two tests.

Jim

 

[torturedmind]

thanks for the response guys.

i found out that the first code (using the IIF() function) sometimes do as it is supposed to do and most of the times not. it is inside a SCAN...ENDSCAN loop reading employee records and SCATTERing MEMVAR before proceeding to that piece of code. and surprisingly as mentioned, it exhibited the said behavior. i already run it from the debugger and watched the variables which returned values as expected. but it still did the same thing. the program was one of those old vfp6 apps i inherited from the previous programmer of the company and was unable to touch until now.

anyway, i replaced IIF() with the block IF...ENDIF which worked 100%. just wondering why IIF() didn't worked well for me... (still scratching my head...)

kilroy
philippines

"Once a king, always a king. But being a knight is more than enough."

 

[Mike Lewis]

Kilroy,

I can only say that there must some other issue involved here. IIF() has been in the language for years, and has always worked as expected.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[torturedmind]

i think so too mike. am not gonna let this slip thru me so i'll still look for answers. will post back if anything come up.

thanks y'all.


kilroy
philippines

"Once a king, always a king. But being a knight is more than enough."

 

[alvechurchdata]

IIF() has been in the language for years, and has always worked as expected.

Mmmm. Depends what you mean by "expected". It can be a real pain to debug when some bright spark has nested eight levels of IIF instead of putting the logic out in a nice function.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Mike Lewis]

It can be a real pain to debug when some bright spark has nested eight levels of IIF instead of putting the logic out in a nice function.

You're so right, Geoff. Although that's not the case with Kilroy's code.

And I'm sure you agree that ICASE() is a welcome addition.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[DSummZZZ]

Just let me point out here that a lot can depend on the evaluation order. Simply stated, going back to 'C' code - which VFP is basically developed in - rvalues can be evaluated prior to lvalues.
Internally, depending on how the function is called, the IIF() could deduct the number, then evaluate the condition, prior to what we would perceive as properly evaluating the condition. Make sense?

Anyway, I would avoid using anything that could be the least bit ambiguous, such as using a variable to evaluate or compare itself in a function like that. The IF...ENDIF structure is much safer, and I believe, easier to follow or debug.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[alvechurchdata]

You're so right, Geoff. Although that's not the case with Kilroy's code.

Sorry Mike (and Kilroy). Just feeling a bit bilious after counting on my fingers and finding that the eight-deep nesting was crashing because there was one closing bracket too many.

Of course Fox just says "Syntax Error" which isn't a fat lot of help when you've got INLISTS inside the eight IIFs and lots and lots of commas and brackets to count.

Geoff Franklin

http://www.alvechurchdata.co.uk