I have taken on a project of converting Microsoft Access databases to web-based applications. (Call me foolhardy - or worse ;-)) This will involve translating a form into a web equivalent. I’m writing a VBA script to automate as much of this as possible. So far the results, which are certainly not worth showing, have given me a set of form controls and no syntax errors. I’m now at the point where I want to translate the positioning data (measured in Twips - 1/1440 inch) to html standards (presumably pixels?).
I have adopted the following strategy:
Each Access form gets its own html file, and its own CSS file (see attached files - you’ll need to strip off the .txt)
Each Access form control is given both an HTML name and also an HTML id, that match the Access control name.
In the accompanying CSS file, each HTML id gets a position:absolute, and the four values (top, left, height, width) in pixels (for now)
My question is - are there other things I should be adding? Any suggestions will be appreciated!
In css, the html-comment tags <!-- … –> are not allowed. Comments in css must be inside a /* … */ pair.
All <input>'s in the html must get the {position:absolute;} property. In css you can do that in 1 line for all, with a simple:
css input {position:absolute;}
The css property/values of an element have to be wrapped in a { … }.
The values have to get a unit, otherwise the browsers don’t not know what distances have to be computed.
So the beginning of the stylesheet can be:
/* CSS File created by DB2WEB 12/23/2013 5:08:28 PM */
/* frmProject; */
input { position: absolute; }
/* CSS style info for txtProjectName */
#txtProjectName { top:24px; left:144px; width:288px; height:15px; }
/* CSS style info for Label1 */
#Label1 { top:24px; left:72px; width:68px; height:15px; }
...
etc.
If you have changed both files in this way (and have them in the same directory), you can open the html-file in the browser and see if it’s the desired result.
Good luck!
The only other CSS coding I’ve done was some hand-assembled code for a more ‘typical’ web-site, and that was largely based in following cryptic hints from various books! You reminded me of a whole load of things that I’d forgotten!
I now have a little bit of progress! I’ve reattached the two files - cleaned up as per your suggestions.
Questions remaining:
I can’t seem to stretch the controls across the full width of the form. Everything is still bunched up towards the left.
The vertical alignment seems totally skew-wiff (technical term from my childhood!) This is where such magical incantations as “float” and “span” will undoubtedly come into play, but my task is still to be able to do the conversion without manual tweaking (As an example, the ropwse… and Scan buttons should be on the same line, and (later on) the Browse… and Create buttons should also be on the same line. In each instance the Browse… button comes first - quite unlike the way they’re being rendered!
One thing I am doing, which ay have a deleterious effect is, whenever I detect a new line (the .left position drops back dramatically), I issue a <br /> tag in the html. I’m wondering if this creates a new ‘box’, and hence disrupts all my absolute positionings?
Thanks, again, for your assistance! Have a great Christmas!
Tony
PS I’ve also added an internal file which has the positional parameters for all the controls - it has them in the sequence in which the conversion process deals with them. The header line has some book-keeping details, including the width of the form (11835 Twips) and the line offset to the literal pool (the last couple of lines) which is the source for all the captions.
Yes, I see. - The most of your stylesheet isn’t used! The culprit is the omitted curly bracket } in the end of each style-declaration. They start as intended with the opening { but they don’t end!
The vertical alignment seems totally skew-wiff. (…)
I see that too: without stylesheet it is even better!
Here the culprit is the {position: absolute;} of all the input elements. If you forget that, it will be more a form.
======= Finding the truth
The best you can do to get it all proper coded, is to check the html- and css-file every now and then with the validators.
There was a typo in the xmlns-declaration (www.w3.or instead of www.w3.org).
But better than a Transitional doctype (with the intention to serve websites from before 1999) is the use of a doctype for the modern standards; all browsers can handle that. The easiest way is to take the html5 doctype, written as: <!DOCTYPE html><html lang=“en”><head>… etc.
Added: the still missing charset-<meta>, a page title, and the <head>/<body> sections.
An input element with type=“input” doesn’t exist, has to be: type=“text”.
An input element with type=“label” doesn’t exist either. I got the feeling that you mean boxes which cannot be filled bu the user, but will be filled automatically after clicking the “Scan” button. - So made them text-boxes with a disabled status (and a default value to see what will come in).
The ComboBox’s had no input type. I guess you mean roll-out selecting boxes with several options. Changed them in <select><option>… etc.
=======
When I see this, I think a lot of the css properties (almost all fixed distances in px) can be missed, simplifying the css-computing.
Browsers can handle much things on a page automatically, without css instructions.
It even can be dangerous to set distances in fixed px: if a visitor is enlarging the font-size for better reading, the design can break.
But before we can do that, I should like to hear if this are the headlines of what you mean.
Can you make a sketch with the design you want to give it?
A good Christmas too!
BTW: Never done something with VBA, and never heard about “Twips”. My vocabulary is growing.
Here is the last iteration that I’m going to do in 2013. As you can imagine, part of the problem is finding ways to translate your very good suggestions into rigorous algorithmic determinations of when to do what. However, that’s what I agreed to do.
I’ve implemented pretty well all of your suggestions. However, the Scan and Create buttons still need to find their way to the same lines as the two Browse… buttons. Also, all the text boxes should be aligned, but the label text seems to be truncating itself to only the width needed to display the label caption.
I was pleased to discover that a <select…> does not need to have options! They will be loaded (by JavaScript) as part of the form initialization, or by a data retrieval action (from a command button).
Any ideas about these two niggles? Then I’m taking a week off to celebrate Christmas and the New Year.
Happy Holidays,
Tony
PS I tried the “add a .txt” extension to see if I could upload a copy of the Access database, however it blew through the size limit for ‘text’ files. Oh well!
I’ve found that I can compress a ~4200KB file and attach as a zip to get around the size limits.
If you do this, please make sure there isn’t anything “sensitive” in it eg. passwords etc.[/ot]
(As an example, the ropwse… and Scan buttons should be on the same line, and (later on) the Browse… and Create buttons should also be on the same line. In each instance the Browse… button comes first - quite unlike the way they’re being rendered!
