>>>I have a form on which I want certain controls to be visible when the value of a checkbox is false.
>>>
>>>In the refresh method, I have the following code:
>>>
>>>*refresh
>>>
>>>if thisform.chkactive.value = .f.
>>> thisform.txtin_date.visible = .t.
>>> thisform.txtin_date.enabled = .f.
>>> thisform.lblin_date.visible = .t.
>>>else
>>> thisform.txtin_date.visible = .f.
>>> thisform.lblin_date.visible = .f.
>>>endif
>>>
>>>In the CmdNext button, I have the following code:
>>>
>>>IF NOT EOF()
>>> Skip
>>> thisform.refresh()
>>>ENDIF
>>>
>>>IF EOF()
>>> =MESSAGEBOX("This is the last " + THISFORM.recordtype, MSGOKONLY + MSGEXCLAMATION, C_APPNAME)
>>> GOTO BOTTOM
>>> thisform.Refresh()
>>>ENDIF
>>>
>>>When I move throught the records, the controls become visible one record late. For example, when I get to a record that has a .F. value in the checkbox control, the controls referred to in the refresh method are still not visible. They become visible when I move to the next record. I'm not sure what I'm doing wrong here.
>>>
>>>AL
>>
>>Instead of checking the value of the checkbox, try checking the value of its controlsource in your 'if' statement. Checkboxes are really quirky like this, their values often don't get updated automatically. I am confident that not relying on the value of the checkbox will solve your problem.
>
>Erik, you're right, but it's not just checkboxes. The same thing will happen with textboxes, etc. The reason is in the order of the procedures when you refresh. VFP seems to process the form.refresh code and then each of the controls. I've tried putting dodefault() code in various places, but nothing seems to help.
>
>(Also, Allen got his answer a second BEFORE you posted it. Clairvoyance?) :-)
>
>Barbara

It seems to me that checkboxes are even worse than other controls, because in the interactive change event, this.value (even from WITHIN the checkbox!) always returns the value of the checkbox _before_ the change, whereas other controls give the value after the change. I have also tried issuing a dodefalut in this event, but it doesn't seem to help. Since a checkbox is either on or off, and there is no in between, and you can be sure that if somebody has changed the value, then the value that returned by this.value is exactly opposite of the real value. Using this to my advantage, I have come into the habit of using the opposite value for my calculations. A pretty kludgy workaround, but it works.
While we are on the subject though, another complaint about checkboxes is their noticeable lag in response time. Clicking a checkbox twice within about one second only changes the value once. It seems that it takes this long for the control to internally 'reset' itself before it is ready for more interaction.