This content has been marked as final. Show 6 replies
I think the main issue here is that RoboHelp is intended for development of help systems and not forms processing. Yes, it can be made to work, but it's not out of the question that you will need additional software. Well, to do anything beyhond a simple mailto it will be.
I've used the mailto method and it's a bit kludgy. I've also used Microsoft FrontPage. It's a bit better, but you do have to have FrontPage as well as the FrontPage extensions installed on the server you publish your content to. Additionally, this also means you need to be using WebHelp or a web based output. Not a .CHM. If you are creating .CHM content, I think you are pretty much stuck with the mailto method.
The best solution I've discovered overall (again, talking WebHelp here) was a small PERL script I purchased called FormProcessor Pro from a company called MitriDat. Click here to visit MitriDat
Hopefully some of this helps... Rick
Colum and Rick:
Thanks for the feedback. My reasoning for avoiding cgi scripts was two-fold. First, I don't know a damn thing about 'em (other than a general concept of what they do)! And second, since I am talking about a .chm that is deployed with our application and runs on many, many different computers and networks - and not a webhelp app that runs on a web server - I wasn't sure if I could even use cgi scripts and what would need to be distributed to get them to work on all those machines....
I also spoke with our in-house web developer (although I had been trying to avoid having to make more work for her), and she offered to post a form on our website that will email me the requested details. So, I guess I get both worlds - I create a simple feedback link in my .chm that directs users to a form on our website, and that form page will email me my required results.
Thanks for your thoughts!
LOL, Colum is spot on!
WRT any kind of feedback, I'm guessing that there are a couple of issues at play here.
1. Probably the only kind of feedback you will get will be negative. But then, perhaps that's exactly what you are seeking. I always get a kick out of those Microsoft feedback pages asking if this was helpful. I'm guessing nobody completes these if the page totally answered the question, while maybe a few exasperated users will answer if the page wasn't helpful.
2. I also see many folks wanting to track page hits against searches and whatnot. The humorous part with that (again from my twisted mind's eye perspective) is that many false correlations are probably made. Perhaps they see 1,000 users that always ask the XYZ question and always stop at the 123.htm page. So the conclusion is made that the 123.htm page simply MUST be the proper page for any question involving XYZ. But what happens when the 123.htm page is simply where each user gave up?
Random thoughts... Rick
Don't beat yourself up - you're not the first person with this issue. Hence, I'll cut-n-paste from a post I made previously:
There are two families of mailto: methods. First, and most reliable, is the server-side application. You need some sort of server-based script to grab your user info, and ship it off. Nothing is saved on the user machine.
Or, you can use a client-side script. But, it has severe limits. Some browsers don't recognize the Mailto links, and IE forces a 256-byte limit. Half of this paragraph is used up by the mailto header. So, you'll be lucky to get two sentences in the BODY= part of the message, if it goes at all.
Using the FORM method allows a client-side workaround; the message content is indeed embedded in the .att file, but you need to set the parameters as enctype="text/plain" for the content to be legible.
Here is a decent explanation of the client-side/server difference for forms:
...here is a previous thread wherein I provided a client-side mailto that uses a proxy form to get the info into the .att file. It may be the same technique as the knowledgebase article, but your .att file can be read without a decoder ring...
Further down the thread, you'll see where MergeThis has a client-side mailto: that is subject to the half-256 byte limit.
Hope that helps.