On your question on if you should also have a refresh in case 2 and 3, I would say this would not be needed. This is based purely on my experience from my 2.x days. Usually, my enabling or disabling of an object was not based on record pointer movement or a change in that specific object's value. This enabling/disabling was usually based on a change in the value of some other object.

I doubt that there will be a serious performance hit, so adding it can only cover all possibilities without a significant down-side. Depends on the particular screen and what was going on.

>I am writing a FPD to VFP migrator that replaces GETS with objects and have to replace SHOW GET statements with the best equivalent.
>
>I have used SHOW GET mostly for ENABLE/DISABLE, but also for refreshment and sometimes to make items invisible. I intend to use the following equivalences. Please comment and advise.
>
>As background, during the conversion the variable that used to be in the GET becomes the ControlSource. The object is given the name xxxMyVar where xxx is the standard prefix according to object type.
>
>1) SHOW GET MyVar becomes xxxMyVar.Refresh()
>
>2) SHOW GET MyVar ENABLE becomes xxxMyVar.Enable = .T.
>
>3) SHOW GET MyVar DISABLE becomes xxxMyVar.Enable = .F.
>
>4) SHOW GET MyVar COLOR c1,c2,c3 becomes xxxMyVar.Visible = .T. and gets flagged for hand tweaking except in the case of two color strings which are recognized as visible and invisible.
>
>I don't know whether to add xxMyVar.Refresh() in cases 2 and 3.
>
>Comments please. TIA.
>
>Alex