>>Naomi,
>>
>>I think you're too close to the problem. You're making things more complicated than they need to be. Let's simplify...
>>
>>The problem isn't with entering the data, it's with interpreting it. Simply set up your option group with Monday, Tuesday, etc. as 1, 2, 3 and so on.
>>
>>When it comes time to interpret it, simply something like

IF MyTable.DayOfWeek = DOW(DATE(), 2) THEN
>>  * Do your processing.
>>ENDIF

>
>The process to deal with the nDow is not even going to be mine and I do not want to do extra conversion that time. nDow = 2 should mean Monday, and not nDow=1. I believe that using unvisible option 1 is the simplest solution to this problem.

Naomi,

No offense, but it's a kludge. Further, if it's just invisible, it's possible to get bad data. Why? Just because it's invisible doesn't mean that it can't get the focus. You need to disable it as well.

As for my routine, yeah we can improve it. I mean if Dudley Dunderhead comes along and doesn't understand what the second parameter means, he might delete it, rather the doing an RTFM. So let's at least give him a reason to pause before he deletes it.

Steve McConnell refers to many hard coded numbers as "magic numbers". The reason that he calls them that is that they're not self-documenting. So let's fix that part of it. We'll add a header (include) file, with the following:

#DEFINE DOW_MONDAY 2

now rather than the above, we have

IF MyField = DOW(DATE(), DOW_MONDAY) THEN
  * Do the processing
ENDIF

Now if this doesn't float your boat. Try the following.

In your base option button group class (you did sub-class the VFP group didn't you?) add access and assign events. In assign

This.Value = m.vnewval - 1

In access

RETURN This.Value + 1

and if you add a header file you can define 1 as

#DEFINE ONE_DAY 1