From: Terence on 16 Nov 2009 17:20 Dr J.R. Stockton wrote: > > AIUI, if you make an HTA page, using MSIE, you can combine Web-style > appearance with WSH-style access to the machine. And you can distribute > it by the Web mechanism, with instructions to save to local disc. I > have not tried it. > > -- I agree John, I should have said that the form name used becomes .HTA for this purpose. This achieved some small succes but not the Modzilla coding and not as a general for all elements output. But what else is needed to store data locally (see repeatsd code extraction earlier)? I don't want to distribute forms with instructions to fill and store on the local disc (although we Do distribute to individual, whose browser automatically MAIL the data by the POST method to US, where it is processed. And on-web-site forms for non-pre-selected users, do the same action). All the forms filled in are on ONE machine and the data to be stored on ONE machine (conceptually - really there are 15 or so). I want to avoid mailing to ourselves, which seems ridiculous waste of energy and web traffic. WSH access is a term I have not met.
From: Terence on 16 Nov 2009 17:46 Corrections after more web-searching: 1) "Modzilla" should be Mozilla. I accepted some elses typo as the correct spelling and reference. 2)" Mozilla coding" IS URL-coding as noted by "CaptainKirk1966". So I'm after URL code, stored locally, as the output of the form. This may be terribly obvious to some, bu all my HTMx reference books I have assume only method=POST e-mailing in URL or other-site cgi- checked will be used.
From: Terence on 16 Nov 2009 21:37 On Nov 17, 9:46 am, Terence <tbwri...(a)cantv.net> wrote: > Corrections after more web-searching: > 1) "Modzilla" should be Mozilla. I accepted some elses typo as the > correct spelling and reference. > > 2)" Mozilla coding" IS URL-coding as noted by "CaptainKirk1966". > > So I'm after URL code, stored locally, as the output of the form. > This may be terribly obvious to some, bu all my HTMx reference books I > have assume only method=POST e-mailing in URL or other-site cgi- > checked will be used. OOPs (again)! URI coding! In essance I'm try to find a way to define a local file name as an agent for processing. Suggestion: Is there a way to SAVE the filled-in FORM as a file on disc?. This would probaly be a list of field names, indexes, and contents.
From: Evertjan. on 17 Nov 2009 04:51 Terence wrote on 16 nov 2009 in comp.lang.javascript: > Oh dear! [..] > I'm not all that interested in correcting the code of others, I'm just > interested in find out what java code is necessary to take the pure > HTM form data ( the entity "this.form" for example) and store the > user-input data on the local disc in Modzilla format. Java code being OT on this NG, and moreover this NG being not interested in what you find not interesting, and you not quoting your responses, please dear Terence, concider no more using this NG. Modzilla? Not a format, perhaps a kind of cheese prefered in the new world? -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
From: Stefan Weiss on 17 Nov 2009 05:38
On 16/11/09 22:42, Terence wrote: > I'm not all that interested in correcting the code of others, I'm just > interested in find out what java code is necessary to take the pure > HTM form data ( the entity "this.form" for example) and store the > user-input data on the local disc in Modzilla format. Your requirements are hard to understand, because you insist on using non-existent or misleading terms: "HTM", "java code" (JavaScript and Java are two very different languages), an "entity" called "this.form", and - again - something called a "Modzilla format". Your examples are incomplete and buggy, but when corrected, you say you're not interested in improving them. In short, you sound more like a customer than a fellow developer. > A REAL HTM form generated by our system is totally correct and woks > fine to send data needlessly back-and-forth over the internet to get > the form Modzill data back. > And, I point out, if your browser is working offline and you fill in > an htm form, that captured form data isn't going anywhere if the > action method is POST. > But it COULD be stored if there is a method of doing so. Which is what > I'm looking for. There's no magic method like that. As I said before, you need to a) serialize the form state, and b) save the serialized string to a local text file In an earlier post, I have provided (b). What you're still missing is step (a), which if done correctly will produce your "Modzilla format". The form does not need to be submitted at all, so it doesn't matter if the method is set to POST or GET, or what its action is. > Here is the smallest example of an expected RESULT file I could lay my > lands on. > It shows the capture of binary radio and multiple button choices, > decimal values and text responses. When you're talking about form element types, it helps to use their correct names, instead of inventing new ones. > This one happens to contain spanish > responses. Greek wouldn't show up very well here. > But the concept is to be able to use one solution to work on ANY htm > form, almost whatever the language set used, although we limit to left- > to-right single byte symbols. Single byte characters? Brrr. A tool which supports multiple languages should really be Unicode capable, and use UTF-8 in HTML documents, or you're going to have a lot of fun with all the different character sets. Since your HTML file is loaded from the local file system, there won't be any HTTP headers; you probably want to add a Content-Type <meta> element to your <head>. > id=CUEST2++&01%2F03-00=+1&01%2F04-01=+1&01%2F04-02=+2&01%2F04-03= > +3&01%2F04-04=+4&01%2F04-05=+5&01%2F05-00=+1&01%2F06-01=+1&01%2F06-02= > +2&01%2F06-03=+3&01%2F06-05=+5&01%2F07-01=+1&01%2F07-03=+3&01%2F08-00= > +1&01%2F09-01=+1&01%2F09-02=+2&01%2F10-00=+2&01%2F11-RR= > +1.+Cumplimiento+de+acuerdos+ANS+%28actualizaci%F3n%2C+calidad+de+la > +data%2C+tiempo+de+respuesta%29%0D%0A+2.+Gesti%F3n+y+atenci%F3n+de+los > +Ejecutivos+de+Cuenta%0D%0A+3.+Proactividad+en+Proyectos+ > %A0&01%2F16-00=+2&01%2F17-00=+2&01%2F18-00=+3&01%2F19-00=+5&01%2F20-00= > +5&01%2F21-00=+3&01%2F22-00=+3&01%2F23-00=+4&01%2F24-00=+3&01%2F25-00= > +3&01%2F27-00=+4&01%2F28-00=+4&01%2F29-00=+5&01%2F30-00=+3&01%2F31-00= > +4&01%2F32-00=+5&01%2F33-00=+5&01%2F34-00=+4&01%2F35-00=+5&01%2F36-00= > +4&01%2F37-00=+5&01%2F38-00=+4&01%2F39-02=+2&01%2F40-09=+9&01%2F41-03= > +3&01%2F42-02=+2&01%2F43-00=+1&01%2F44-00=+6&01%2F45-05=+5&01%2F46-02= > +2&01%2F47-RR=+%A0Banco+de+Venezuela&01%2F49-RR=+%A0VPA+Riesgos+de > +Particulares&01%2F51-RR=+%A0VPE+Riesgos&01%2F53-00=+4&01%2F54-00=+1. I'm assuming Latin-1 for that one, because I'm human and happen to know Spanish and Latin-1, but how can the next tool in your chain of over 100 programs know that? And what's with all the '+' characters? Don't you trim whitespace from your element values? > The question, again, is, "how do I change the following htm code by > the use of java script, to replace the line > <form method="post" name="STUDY999" > action="mailto:tbwri...(a)cantv.net"> > with something that changes the action from e-mailing to one of > storing?" That's not the right question. No other form method or action will result in storing your file instead of sending it. You need to call a custom function on submit (or when the STORE button is clicked), which will then create the serialized and encoded string (a), and store it (b) locally. Form serialization is not hard, but there are a few gotchas. I don't have a stand-alone solution for you right now, but you should be able to find one on the web easily enough. cheers, stefan |