What's wrong in Icase

[alisaif]

Hi,
In report I use a variable m_unit and in value to store I put the following:
(Icase('1000/Pcs','Pieces','100/Pcs','Pieces','1000/Set','Sets','100/Set','Sets')
But I am facing an error "Function .... is invalid"

Please let me know what is the correct syntax.

Thanks

Saif

 

[Olaf Doschke]

icase expects epxressions evaluating to .T. or .F. like a CASE statement and then values for each case.

Eg this works;:

? ICASE(1=0,'one is zero',1=2,'one is two','none of the above is true')

This will print 'none of the above is true' since neither 1=0 nor 1=2 is true.

So ICASE is not there to simply put in a list of strings. What are you trying to accomplish?

Bye, Olaf.

 

[Mike Lewis]

To elaborate on Olaf's answer, I'm guessing that what you need in this case is as follows:

lcValueToStore = ICASE( ;
  m_unit = '1000/Pcs','Pieces', ;
  m_unit = '100/Pcs','Pieces',  ;
  m_unit = '1000/Set','Sets',   ;
  m_unit = '100/Set','Sets')

Note that I've split this over several lines only to make the syntax more obvious. You can put it all on one line if you prefer.

Also, you will probably want to wrap m_unit in ALLTRIM(); also, make it UPPER() and compare it to upper-case values (such as '1000/PCS').

Also, in the code that you posted, the parentheses were unbalanced. I've fixed that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

That's an idea.

As m_unit is the report variable which should store the ICASE result, there needs to be some different field name involved where you get the original values of '1000/Pcs' '100/Pcs' etc. you want to translate. Makes me wonder why there isn't a separate unit field for the single units 'Pieces' and 'Sets' in the first place.

If that's what you want to achieve, it would be sufficient to decide two cases: 'Pcs' or 'Set' occurring in the field should get translated to either 'Pieces' or 'Sets', that could be done by [tt]ICASE( 'PCS' $ UPPER(field),'Pieces', 'SET' $ UPPER(field), 'Sets', 'Other Unit')[/tt].

'Other Unit' is optional, it corresponds to the OTHERWISE case of the CASE statement. It would be the unit for records with neither 'Pcs' nor 'Set' in the original field.

Bye, Olaf.

 

[Dan Freeman]

OTHERWISE is never optional.

I've debugged too many cases where code skips through DO CASE without assigning a value. Every CASE needs OTHERWISE.

 

[Olaf Doschke]

Absolutely, but technically it's optional, you can both do a CASE without otherwise and an ICASE without a last return value.

I have many CASE statements covering all cases there are and just a comment in the OTHERWISE clause stating why there is no otherwise code. If you do a case on a logical field for .NULL., .T., and .F. there is no otherwise, for example, and I don't put any of these as OTHERWISE just to have an otherwise, such a case statement would have the cases I) ISNULL(x), II) x, and II) NOT x and no real otherwise. If the type ever changes, the whole code needs to change anyway.

So finally let me be picky now and warn about misusing OTHERWISE for the last logical case there is left. If you do that your CASE statement is really expecting a specific case in otherwise and that is not the meaning of it. If you have cases like product types, countries, anything that can be extended the otherwise clause can be used to cover non covered cases at least with a default code and may also log that there is the need to extend the case statement, true, but it's not your ELSE branch, that only ever applies to opposite conditions and a case statement is not about something or NOT something, it's about N cases.

In Saifs case (or should I say ICASE?) I would expect records without any unit and then an empty string would be good, too. Or other units need no translation, then the field itself untranslated would be a good value to return, eg [tt]ICASE( 'PCS' $ UPPER(field),'Pieces', 'SET' $ UPPER(field), 'Sets', field)[/tt].

ICASE returns .NULL. in case the otherwise value would be needed, eg ICASE(.F.,1,2) returns 2 and ICASE(.F.,1) returns .NULL., and so you'd have a problem if .NULL. is not accepted. Besides that, this could also be done with IIF, of course.

Bye, Olaf.

 

[dbMark]

Slight diversion... this reminds me of code I used 15 years ago for a Visual Basic project. Its Select Case statement is a variant from VFP. You test each Case line to the value on the main Select Case line. If memory serves me, a friend had a VFP-style approach, his solution was to test each Case against TRUE, then he could place the VFP-style comparison on the various Case lines.

Select Case [b]True[/b]
   Case Var1 = "Match 1"
      ...
   Case Var2 = "Match 2"
      ...
   Case Var3 = "Match 3"
      ...
   Case Else
      ...
End Select

From Jurassic Park, "Life finds a way.