Subject: RE: What exactly are you trying to accomplish?
I agree with Charles in the sense that I think you’re underestimating what you can do with the Notes client.
First, I think you want to stay away from dialogboxes. You’re right that they would be too limiting; don’t use them. Display your forms as full windows. My asumption here is that each question is described as a discrete form.
Next, I’m not aware of a way to capture individual keystrokes, but you can put a hidden combobox on your form, give it the default focus, and in its OnChange event you could put Lotusscript to respond to each keystroke. Suppose that the user opens a ‘question’ (actually a form) with a yes/no radio button on it. When the user opens your form and types ‘y’, your code runs:
with uidoc
call .fieldsettext(“yesnoradio”,.fieldgettext(“hiddencomboxbox”))
call .fieldsettext(“hiddencombobox”,“”)
end with
This technique will also work in R5, but you have to use JavaScript in the onChange to call click() on a hidden button. The button holds the Lotusscript, or formula or whatever. In R6 you must also check off “Run Exiting/onChange events when value changes” to trigger the onChange.
Assuming your radio button field has a value list of
yes|y
no|n
then when the user opens the form and types ‘y’, the radio button switches to “yes”. If the user types ‘q’ or ‘5’, the radio button goes to “”.
That’s a little crude, but it costs you nothing to find out if it works well enough for production. The problem is, if the focus moves away from the hidden combobox, the magic stops. Could you put all the multiple choice fields etc in a controlled-access section and deny the current user access? Or use the DOM events to blur back to the hidden combobox any time the user places the focus someplace else, or use the field’s onBlur event to put the focus right back on the field. There are probably several ways to deal with this problem.
Suppose that each question is decribed as a discrete form. So to answer one question the user is composing a document, and then that answer gets saved someplace (to a profile document perhaps, or to a hidden document) and then another document is composed in its place. The problem is, how do you know when it is time to close the current document (and save the user’s answer of course) and compose the next one. My first thought here is to refresh the document as part of that Lotusscript snippet above, and then in the PostRecalc event, determine whether the user has answered the question, and if so close the current document, figure out and form goes next and compose it.
An alternative might be to make every field on the form refresh-document-on-change, so as to trigger the PostRecalc whenever the user does anything. That might be a performance killer.
In all, a browser would probably be a better client choice. But the Notes client is vastly more capable than most people suppose, and it costs nothing to find out if it can do this job.
Another idea is, is there a word processor out there - MS Word for example - that can capture user’s keystrokes and do the other things. If so, you could use it as the front end - possibly embedding a document in each form - and use field exchange or VBA to get the user’s responses back into Notes.