Switch, Case and wild-cards?

[Peter Haworth]

Wow!  That's boatload of case statements, must be a nightmare to maintain!
 Interesting to think of how it might be simplified, at least in terms
of organizing the code a little differently.

Things like that are often a matter of personal style but a couple of ideas
come to mind.

It looks like the case statements fall into "families" based on the first
character being tested.  I might be tempted to change the case statements
to only check the first character then call a different function to check
the second character and return the results., e.g:

case numtochar(2328)
   put check2328(numtochar(char 2 of fld "fBUILT")) into fld "fPROC"
case <etc>

(Disclaimer: my knowledge of unicode is next to zero so the "char 2 of fld
fBUILT" might need to to be tweaked.)

You could probably eliminate the first level case statements entirely with:

get check" & numtochar(char 1 of field fBUILT) & "(" & numtochar(char 2 of
field "fBUILT") & ")"

put value(it,<long id of the object containing the "check" functions>) into
field "fPROC"

(Same disclaimer applies)

I also tend to favor table driven code so another alternative might be to
create a custom property as a table of lines with each line having the two
unicode characters as the first item and the character you want back as the
second item.  Then all you need is

put the cUnicodeTable of me into tTable
put item 2 of line lineOffset(fld "fBUILT",tTable) of tTable into fld
"fPROC"

You'd have to write some code to build the custom property (and maintain
it) but it would reduce your code down to a couple of lines at run time.
 Could also be done with a flat file or even a simple database.

Pete
lcSQL Software <http://www.lcsql.com>


On Fri, Dec 28, 2012 at 2:35 AM, Richmond <richmondmathewson at gmail.com>wrote:

> Frankly, I've never bothered to count how many case statements there are
> there; but, certainly > 500.