Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.orgYou may find that the database being shipped with OpenOffice (ver.2 and higher) delights you as much as it has me. This page tries to help you use it.
Forget anything you may have heard about Adabas, which came with Star Office, the commercial version of Open Office 1. The current Open Office's database, "Base", aka "ooBase", is unrelated. And remember that Open Office, including ooBase, is free! But don't let that fool you. And it's not new. Big organizations, government and civilian, are adopting it as their standard office suite... and saving million$, but still Getting The Job Done.
There's more about ooBase in the main index to this material.
This page is "browser friendly". Make your browser window as wide as you want it. The text will flow nicely for you. It is easier to read in a narrow window. With most browsers, pressing plus, minus or zero while the control key (ctrl) is held down will change the texts size. (Enlarge, reduce, restore to default, respectively.) (This is more fully explained, and there's another tip, at my Power Browsing page.)
Page contents © TK Boyd, Sheepdog Software ®, 2/06-5/09.
The page you're reading is an early version of an explanation of how to put radio buttons on a form. This can be useful to help users enter only valid data. For instance, if your database is about people, and you want to record the gender of each person, radio buttons, one for "male", one for "female", to click might be a good solution. In the example that follows, we are going to record details of some computers. Specifically, we will record whether they are laptops, towers, or have horizontal cases.
An interesting question arrived with my email. In essence it asked...
How do I put radio buttons on the data entry form of a database to keep track of the case type of some computers?
For the sake of this example of an aspect of that, we are only going to have two fields.
The first: a unique identifier, a "serial number" if you like, for each PC.
The second field: records whether the computer is a laptop, of the "tower" type, or one of the older-style horizontal slabs.
The "tricky" bit we will explore in this tutorial is the use of radio buttons to input the PC's case style.
So... down to some details.
The "serial number" field will be of type text, and will be the table's primary key. It will be called "ID". In the real world, you'd do something clever in your ID assignments, but for the purposes of the exercise, I'm just calling the different machines PC1, PC2, PC3, etc.
Building databases that work well is all about seeing that you have choices, seeing ALL of your choices, and making the right choices.
As I was building the database, I foolishly called the second field "type". Happily, I hadn't done too much work yet, so just scrapped my first attempt, and started again! (The word "type" has other, important, uses in database design work, so it is best to avoid adding another use of the same word into your work. The same is true of the words "case" and "form", which were my next candidates for the field's name!)
I settled (eventually) on "CaseShape" as the name for the second field. By the way, I'm calling the table CaseShapeTable.
I set CaseShape up as a Tiny Integer type field.
I chose (remember what I said a moment ago about choices) to use 0, 1 , 2 or 3 as the values to stand for "unknown", "tower", "horizontal" and "laptop" respectively. Lots of room for better choices here... but for now, deal with these choices!
The Big Choice I made was to ALLOW the user to enter a code for "not yet entered". You could argue that for this application you might want to force the operator to put something in this field every time, something other than "unknown".
Another Big Choice made was that (for now) it will be possible to add a line to the table (i.e. put another computer in the database) without giving ANY answer to the "what Case Style?" question.
Important General Point: In database work, there is a Big Difference between "nothing entered into this field of this record (column of the table, at this row)" and an entry that says "unknown".
We may well before we are done go back and revise the table's specifications so that the user must AT LEAST put "0" (code for "unknown") into the CaseShape field whenever creating a record for a previously unrecorded computer. And after that, we may choose to remove "0" as one of the options.
Always start small, and build things up. But try to know where you are going before you take those first steps.
The first steps of the database described above were the establishment of the empty shell, the building of the simple table "CaseShapeTable", and the entry, by hand, directly into the table of a few records.
Then a form was started, using the Form Wizard. Answers to many of the wizard's questions were, I hope, obvious. Just in case, here are the choices I made, in an abbreviated presentation....
(The "DE" suffix signifies "Data Entry")
So far so good... that "should" work... and did in my Windows box... and eventually it did on my Ubuntu box (Ubuntu 7.04/ ooBase 2.2.0... but that was a while ago... everyone should upgrade to version 3). You shouldn't, by now (5/09) have to go to the lengths I went to, but if you are having trouble with any aspect of Open Office on an Ubuntu box, especially with matters of forms, see my tutorial on Fixing The Form Wizard. I'm very new to Linux, and my Ubuntu box was only recently set up.
I opened the form and tried it... it "worked", but I had to enter the CaseShape data by hand... not what I wanted... but a start.
Now I will show you how I replaced the field for typing in the case shape code with radio buttons to accomplish the entry of the data for that field. A radio button is a "thing" that is either down or up. You change its state by clicking on it. The clever thing about radio buttons is that only one of the radio buttons in any group can be "down" at a time. Click on, say, button "2", and any other radio button in its group which was down pops up as soon as button "2" goes down.
Closed the form. Reopened it in edit mode.
Then I used View| Toolbars | Form Controls
Clicked on "More Controls" on that (lower left), access the icon to put a Group Box control on the form. Group boxes define... groups! Remember we talked about only one radio button in a group being down at one time, a moment ago? The Group Box is how you define "groups" of radio buttons (among other things).
From the "More Controls" palette, without doing anything to the existing "Case Shape" label and text box, I clicked on "Group Box", and one dragged out on the form and went through the wizard that gave rise to....
Names for options fields: Typed "Horizontal", pressed enter; typed "Tower", pressed enter; typed "Laptop", pressed enter.
That populated the "Options Fields" memo with all the values I wanted, so I then clicked the "Next" button.
Answered the next question "Should one... be... default" NO, and clicked Next.
In the next stage of the wizard, I assigned the values that should be assigned to each option. How I was supposed to do this wasn't immediately obvious... but it wasn't hard, either. In fact, ooBase had already set good values for me. When you've got to the "Group Element Wizard- Field Values step, you should see, in the memo at the right hand side of the dialog, the option fields you have set up. (These will give rise to your radio buttons in due course. Two lines, i.e. two fields: two buttons.)
"The secret": Notice that one of the "Option fields" is selected, i.e. (on many machines) the text is white on a blue background. (On every computer: Presented looking somehow different from the others.)
You can change WHICH option field is selected by various means, the simplest being to click on the one you want to select.
At the left, there is an edit box under the text "Which value do you want to assign to each option?"
This in fact is misleading. It should say "WHAT value do you want to assign to THIS option?"
There will (probably) be something in the edit box. You can change it, if need be. Whatever is in the edit box will, at the end of the day, be what is "automatically typed" by clicking ONE OF the radio buttons. Which one? The one that is currently selected in the memo. To set what is "automatically typed" when you click one of the OTHER radio buttons, CHANGE WHICH "option field" is selected in the "option fields" memo, by clicking on a different one.
Work your way through all of the lines in the "option fields" memo, filling in suitable values (in the edit box) for each of them. You can review the settings you've made simply by once more clicking on each option field in turn, looking at what comes up in the edit box.
A gotcha: Is is entirely possible... but would be entirely pointless... to set the value for two or more radio buttons to be the same value. Be sure you haven't done this by mistake.
In the next dialog, say that you want to save the value in the CaseShape database field. Click "Next".
Give the option group box a caption. Something like "Choose case shape". Click the "Finish" button.
Close the form, to complete the editing. Note that at this time you will have two ways of setting the CaseShape field. It WILL work, remarkably enough.
Reopen the form, for data entry. (Double click on it in the main ooBase panel.) You should find that you can enter new records, or edit old ones, using either the label + edit box the form wizard created, OR the radio buttons in the option group. If you click on one of the buttons, the value in the edit box will change immediately. If you change what's in the edit box AND move to a different control, the radio buttons will be updated.
(A little "gee whiz" aside: The first time I made an option group box a moment ago, I was working quickly, not documenting the steps. I tried it again, typing this as I went, a moment later... and was left with a form with THREE ways to change the value in the CaseShape field... and they coexisted quite happily.)
Close the form, re-open it in edit mode. Delete the label and edit box for CaseShape put onto the form by the form wizard.
Nearly there! We'd be done, in some circumstances. However, in this database (and similar ones), I think we want to say that you can't add a record unless you indicate a CaseShape. Furthermore, I'm not going to allow the user to "cheat" with a "not know" (as opposed to "nothing entered yet") entry.
Because I knew where I was going when I started developing this, achieving these last frills is easy. (Hmmm... "because I knew where I hoped I'd be able to go" might be more accurate...)
Close the form.
Reopen the TABLE for edit.
Click on the CaseShape line. Down at the bottom of the window you'll see some properties. Change "entry required" to Yes. Do NOT put in a default value. (See below regarding defaults). Save your change, close the window, reopen the data entry form and see how well it works!
ARGHH! That "should" have worked. But my system refused to modify the tables properties the way I wanted it to. But when I simple rebuilt the whole thing from scratch, with the CaseShape "entry required" property "yes" from the start, all was well. Sigh.
A Problem: some database designers would be unhappy with using the codes (1,2,3 for "tower", "horizontal", "laptop") I can see their point... in some circumstances. If the codes are going to stay buried inside the system, I'm not TOO worried by their use. However, in this example, maybe it would have been better to code the "CaseShape" as a single character, and use t, h and l to stand for the different shapes.
Defaults: In the example, because of the nature of the work it was doing, I quite deliberately set things up so that an operator would have to select tower, horizontal or laptop every time. I didn't make one of them the default, on the assumption that the operator would remember to change the value from the default when necessary. In a different application, it might make sense to have a default value for some fields. Now, this can be done at the stage when you are defining the table. I suspect that you will come to regret doing that, more often than not. Put no default in at the table level. Use the "Should one option... be... default?" opportunity you get during the Options Group wizard to set one of the options as the default for the field.
This material is "browser-friendly"... in particular, you can (and I recommend that you do!) make your browser window narrow, so that you don't have to try to read long lines.
I dislike 'fancy' websites with more concern for a flashy appearance than for good content. For a pretty picture, I can go to an art gallery. Of course, an attractive site WITH content deserves praise... as long as that pretty face doesn't cost download time. In any case....
I am trying to present this material in a format which makes it easy for you to USE it. See the main index to this material for more information about the way it is posted.
PLEASE >>> Click here to visit editor's Sheepdog Software (tm) freeware, shareware pages <<< PLEASE
If you liked this ooBase tutorial, see the main index for information other help from the same author.
Editor's email address. Suggestions welcomed! - - - Want a site hosted, or email? I like 1&1's services.
Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org
. . . . . P a g e . . . E n d s . . . . .