Livecycle forms irratic when trying to email

Question

All I need to do is the following.
Create a form in Livecycle. Link to it via a weblink and the user opens it fills it out, saves it on their machine and then return it as an attachment.
I do not want a Submit button, as we use Lotus Notes 6.5 (due to upgrade to 8 soon!) and it is irratic with Notes 6.5, as it either crashes out saying it cannot find an email client when the submit buttin is pressed, or nothing happens at all.
If I just save the Form as a PDF, and I send it to a user to test ( I cannot test it as I have Acrobat 9 Pro and it works differently) when they fill out the form they get a message that they do not have permissions to save the file....not good.
If I distribute the Form via Livecycle without a submit button using the "Manually collect responses in my email inbox" I click on next and choose "Save a local copy and manually send later"
This works when a user opens it from a web link. However there is now a mysterious Submit Form button in the top right which I either need to be lowered to the bottom right or made invisible somehow. Users are using Acrobat reader 8.
Adobe seem to expect that the creator of the form is going to be the administrator of the form which is not the case mostly. I am creating the forms for other departments who do not have Acrobat Pro so distibuting the form to Connect etc is no good as I do not want to manage these files...just create them.
Can I either remove this button, make it invisibile or move it down at least?
Cheers

Answer 1

Designer Forms and Acrobat Forms are 2 different beasts. Designer is accessed from Acrobat, but is not Acrobat. It is covered in the LiveCycle forum as I mentioned. You may get an answer here, but the answers should be better in the LiveCycle forum.
For some reason Adobe chose to put email submission as a major form of submission within Designer forms (it is available in Acrobat forms also, but with some extra work). It has long been a problem just as it has always been a problem in HTML. In browsers, mailto submissions have always been a problem because there was no standard. That may have changed for browsers over the years since I quite using mailto with forms.
In Acrobat and Reader, up to vers 9, mailto submission required active MAPI on the user machine. That is typically the problem at hand. A lot of folks have never activated MAPI or have purposely shut it off because of typical security concerns with MS products. As a form developer, you have no way to change the performance of a client machine -- thus making mailto useless in some cases (and you to blame in the eyes of the client). AA9 has added another option as I understand it for this interaction, but a lot of folks do not use AA9 or AR9. Thus you still have to deal with the problem. Even with AA9, I am not sure the solution is full proof.
What does work and is more reliable is submission to a web script with either FDF or XML data files. The scripting method is preferred in all cases, though you then get into having script development. This can be easied by using the FDF toolkit, but you still will need some expertise at programming and scripting I think.
An alternative is to submit data as HTML data to a CGI-mail or formmail script as provided by many ISPs.
If you are distributing the form on the web, then your use base is probably greater than 500 and you do not want to activate Reader Rights (a license issue). Thus you do want to submit data and not the entire form. Actually, submission of the entire form is never needed since you can import the data into the form on your end and get the same results.
Lastly, you probably want to maintain compatibility with prior versions of Acrobat and Reader (I typically go back to AA5). This means being careful about using new features that the older versions crash on. Why is this important? Many folks are still running older versions, some even bring up AA4 periodically. I have installations of 5, 6, 7, and 8 versions of Acrobat, all on different machines. I can't afford and have not found the need to upgrade all the versions. If I specifically need AA8 I will go to that machine and cuss out the developer. One place I have needed AA8 is with portfolios that are distributed for some proposal packages from the feds. A few forms and some PDFs require a newer version also, and in many cases I never bother going to the AA8 machine to open the form (probably not what the developer would have wanted).
As to your required fields, this is typically the case with forms. You can highlight the field with an asterix as is done on many web sites or you can write a short JavaScript to check the field after the mouse-over. For the JavaScript you should visit the scripting forum for assistance. As for the e-mail, I have already answered that (by the way, it is a problem on MACs also, but not sure of the mechanism there. I have no clue about the issues in UNIX). For reliability, forms should be submitted to a web script. A lot of the features you mention are particular to the automatic setup of Desginer and are not as prevalent in Acrobat forms due to the lack of this automation taking you down somebodies idea of a rosy path. Some one at Adobe has been pushing the e-mail of forms in AA8 and AA9, and I have no idea of why. True, writing scripts for a web submission is a bit beyond many folks, but if you can create a form, a script is not that far beyond.