Greetings Erik

>Harry, I think you are approaching this wrong. The VFP environment wasn't designed to let you >"guide" the user through a form. VFP (and Windows, for that matter) are event driven environments. >>That means they are designed to sit and wait to see what the user does next. When you say the code >>then "moves the user on to another combo" it tells me that you are trying to approach your data entry >problem from a procedural straight-linr angle, and that's just not how VFP works. A lot of things you >>will try to get this to work will feel like kludges, because they are. It's just not natural.

guilt as charged and your message certainly nudged me back in the right direction. In the end I've solved the problem with a compromise about which more in a minute...

>Design your forms with a tab order. And that's all. Let the user go all about the form, doing whatever >>the feels like, and then validate input when she clicks the Ok button. You don't need a "controlling"
>>procedure that attemps to move the user through the form.

In this case I do. Ironically this is part of my larger project to upgrade my legacy fp2.6 dos application and it is the first time I've attempted to tackle the job by scrapping my fpdos code altogether and rewriting the relevant routine as an entirely object based form trying to use a politically correct object oriented approach.

The actual routine is a 'filter builder' which allows users to create their own freeform filters or queries with unlimited access to every field in the current table and any other related tables open at the time. Whichever way you play it, each condition must follow the proper form (FIELD, OPERAND, VALUE) so I must force the user to make selections in that order.

However, you made me realise I was handling it the wrong way...

>>The tab key moves the user through the form. I NEVER call a control's SetFocus method from
>>another control, unless I am just trying to save the user time by going there for him, but even this is >>rare. It's fine to enable or disable some control depending on the state that a user left another control >>in.

thats the key - enabling and disabling controls according to what they've just done. This has precisely the effect we want.

I do, however, still use the 'setfocus' approach because that makes it very clear to the user exactly what they need to be selecting next.

The long and short of it is that I've now got the form working with better functionality than I had in the dos version - an unequivocal vindication of the OOP model.

Thanks for the nudge

Harry