>Firstly - Rick - I will no doubt end up buying your wares, but first I have to get my head around web programming in it's entirety, including stuff 'out there', and not just on localhost.
>
>I am messing with Eeva web server (it's free. It doesn't require IIS, (which is a pain all unto itself!)), and it doesn't have localhost limitations. I can get data out there on a web page from local dbfs - first time I ever did this, so it is quite fun to see it happen!
>
>This, I don't think, is an Eeva question, but HTML in general. I am still trying to get my head around the whole web page flow of data, with posts and responses, etc, and I am sure this will take time for a dummy like me, but my question is - if, in the web page I run on the Eeva web server, I can use memory variables from dbfs to 'say' stuff in the browser. In other words - I can represent memory variables on the screen in the browser, but how could I get data entered into a textbox (etc) into a memory variable? From what I have read, things don't work this way, but it seems so weird that I can put a memvar onto the screen, but I can't take the value of a control into a memvar.

What Craig said... but there's a lot more to it.

The most frequently used mechanism of sending data from browser to the server is the mechanism of form-in-page. That means using controls that the browser can create - textboxes, combos, radio buttons, textareas (that's how they call editboxes), commandbuttons etc. There should be a send button somewhere on that form, and its action should be POST - which means it would send values of all the controls on that form with the request. Install Firebug in your browser (I think it exists in FF and Chrome; the in-built object inspector in FF is also very good nowadays) to see what gets transferred each time.

Then on your, server, side you get those post data with the request, and any framework you use would have a mechanism to retrieve these data in name-value pairs, either as a collection, or as a series of requests, like oRequest.GetFormData("myField1"), which would return whatever the value of the control with the ID (or name, sometimes) had in the browser.

Several things to keep in mind:
- stateless means that whatever you know about what the visitor of your site has in the browser you can safely forget (and should forget!), because the next request will most probably be coming from someone else. There's a SessionID, which is also coming with the request, that you use to know who is calling - did you just have that guy a minute ago, what was he doing etc.
- this also means that you need to take care to not reuse aliases, or to make sure you requery any transactional ones on every request, because any records you currently have in them may not be related to the current user.
- forget about any menus, switchboard forms, forms in general - you don't have anything of the kind in a web app. You get one long string as a request, you return one long string (i.e. the whole web page) as a response, and then you idle until the next request.
- everything comes as a string, goes as a string. All the values embedded in post data are also strings embedded in that long string, with delimiters so you (or your framework) can extract them. This is also how you "put a memvar into the screen" - no, you don't. You textmerge it into the long response string, which is luckily formatted exactly how it should be so the visitor's browser can use it as instruction (or metadata, if you will) for rendering the web page.

Basically, you only have to replace your head. Pretty much like you did when you switched from procedural to object-oriented code.