>Thank you Al,
>When using the .lockscreen command, the bleed through still occurred. However when I used the _VFP.AUTOYIELD statement, it corrected the bleed through problem.
>
>I then tried to put these commands at the beginning and end of the function itself (rather than wrapping it around the SpellCheck command). I had to put the last part and doevents command just before the return statement. The return statement passes back the corrected text. It didn't work. The bleed through still occurred.
>
>I guess I can conclude that is where the problem lies. The "phantom vertical" scroll bars are those of the edit boxes being spellchecked.
>
>It occurred to me, rather than checking the spelling of the edit boxes, why not check the spelling of the control source for the edit boxes themselves and then refresh the edit boxes when finished? I believe this may violate the integrity of the levels of control you have built into the form itself. What do you think?
>
>At least I have now a better understanding on 2 new (to me) commands and I also have 2 ways to work around the bleed through issue.
>
>Thank you for that!

I agree that the 2 techniques still have the feel of workarounds and I get the feeling they don't really address the base problem.

I can think of a couple of very general things that could be looked at:

- It may turn out that you're currently calling your spell check function in the middle of an explicit or implicit refresh of the form, pageframe, page, or the problem controls themselves. It might be possible to tweak the exact point where you call the function, and get better results. To get better insight into exactly what's going on when you call the spell check I'd normally recommend tracing in the debugger, but since you're effectively "shelling out" to Word I think that analysis might be corrupted by extra focus, activate and related events. Instead, maybe you could generate and analyze a Coverage Log ( see SET COVERAGE ).

- If you're writing custom code for events, sometimes you have to be careful with DODEFAULT/NODEFAULT. I've had some weird UI issues when leaving out DODEFAULT by mistake in custom event code; often the exact placement of the call is important. You also have to be careful with NODEFAULT to avoid UI issues.

Finally, another potential workaround I didn't think of before: set the editboxes' .Visible = .F. just before the spell check, and set them back to .Visible = .T. after you update their values. If this works it would be preferable to the .AutoYield workaround, because .AutoYield has effects that reach beyond the editboxes in question.