I was serious, more or less. :) First, I don't believe that the fact that somebody has worked with a tool tells much about his/her way of thinking (which, imho, is much more important than the actual experience with a tool/language). Though, it's true that the possible improvements someone can propose may tell a lot about...

As for my complaints... almost none. Mainly because I've worked with many tools in the last years and I've read all kind of documentation for all kind of products. So, for those unhappy with VFP's doc: it's one of the best currently available. I've seen only one documentation better than VFP's doc.

As for bugs, tool reliability, ease of use, speed of development, etc, VFP is also very high on my top.

Of course, there are always things that can be better and everything can be improved. But if I compare VFP to other tools on the market...

Vlad

>We all know you're easy, Paul... < g,d & r >
>
>Seriously, there's no right answer to the question - but it gives you a good idea of whether someone has worked with VFP for any period of time.
>
>Let's assume for the moment VFP were 100% free of 'undocumented features". Everyone who's used VFP to do much of anything has things that they'd like to see changed. Just ask Jim Nelson...
>
>When I ask a candidate that question, I'm not looking for a features list, or familiarity with the latest crop of bugs and workarounds; in order to have things you'd like to see changed, you must've tried to use it the way it is now. It's not a question that can be studied for in advance, or that a headhunter can prep a candidate with pat answers based on another candidate's interview summary.
>
>It's a great springboard for discussing the guts of VFP from your own POV. And sometimes you even learn a thing or two that you didn't know about before!
>
>A note to JimN - this'd be your chance to bitch about the state of the documentation at an interview! :-)