This sounds very powerful. I haven't used a treeview control - I need to look into it. But in my case, I don't just have yes/no questions, I have multiple choice, and each choice can generate a different branch. One requirement that (I think) I want to stick with, is that the system will be a tree, not a 'network', in other words, each answer creates a unique branch, you can't "go to" a 'node/question' that is part of another branch. This may create redundant questions, but, I think, will be easier to code.

Thanks for your help. I will experiment with it as per your described design.


>David, I did a similar type thing a while ago (table-wise) to what Sam wrote. I'd have to revisit the code to bring it all back, but there was only one major form. The information was presented in 2 treeviews. The left treeview contained the names of projects (projects/locations etc). The right side treeview contained the questions. All the information is entered by an administrator. He/she adds a 'project', then adds questions for that project (actual question wording that will show in a pane below the left projects treeview, short wording that shows as a node name in the questions treeview, and question type (narrative/numeric/date/yes-no/option group). The 'Yes-No' question type creates a specific answer path (answer 'yes', next question one branch, answer no, next question is the other branch). The option group is also a 'yes-no', but unlike the "yes-no" question type, it does not create a specific answer path. Finally, the administrator had the option of entering some help text
>for the question that the surveyor could bring up by clicking a question mark button.
>
>The projects could have sub-projects, and sub-sub-projects etc. which is why the treeview in the projects pane. Choosing a particular project in the left pane brought up the applicable questions in the right pane.
>
>The idea the client had was that the surveyor could not answer questions willy-nilly, but must answer each in turn as entered by the administrator, [and] according the the yes-no branch chosen if applicable.
>
>Therefor, the surveyor could not click on just any question in the right pane, but had to use navigation buttons below the questions pane. The answer to the question was also in the same 'box' below that pane, and depended on the type of question asked.
>
>Question branches could be copied from one project to another by dragging, and question had to be able to be moved around and rearranged by the administrator. The administrator's 'screen' had an extra button that allowed him/her to 'become' a surveyor to check the look and feel, and then change back.
>
>It was certainly one of the more complicated things I've done, but it seems to work (at least we haven't heard of any problems from the client (I'm assuming they're using it, but I'm not the guy who markets, so I haven't really been in touch with them since the installation).
>
>If you want to talk, let me know. For the record though, I'm a salaried stiff, so the code is not really mine regardless of the fact that I wrote it.
>
>Alan
>
>>I am designing/coding a VFP based survey/questionnaire program for a client. It is turning out to be very complicated. I'm wondering if anyone has tackled such a project. I'm hoping to share ideas on design, database design. There are commercial programs out there - but none that meet my needs. One - http://www.raosoft.comn uses dbfs - but doesn't quite fit.
>>
>>Trying to make a truly data driven program that handles lots of different branching logic is daunting. If anyone is interested, or has done similar work I will share more details on the particulars of the design issues I am facing, have resolved etc.