AUTHOR'S MAIN SITE   > > > > >  TABLE OF CONTENTS for Open Office database tutorials. Delicious.Com Bookmark this on Delicious    StumbleUpon.Com Recommend to StumbleUpon


Open Office Database
Radio Buttons: A useful way to circumscribe and facilitate data entry on forms.

Also: An example of stepwise development

You may find that the database included in OpenOffice delights you as much as it has me. This page tries to help you use it.

Remember that Open Office, including ooBase, is free. Don't let that fool you, though. Big organizations, governmental and civilian, have adopted it as their standard office suite... and saving million$, but still Getting The Job Done. And making things easy for users on different platforms... Linux, Mac, Windows all spoken here!

There's more about ooBase in the main index to this material. Adabas? Star Office? Ancient history.

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 fully explained, and there are more tips, at my Power Browsing page.)

Page contents © TK Boyd, Sheepdog Software, 2/06-10/12.



Radio Buttons for Forms_______________

The page you're reading explains 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 for "male" and "female" 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.

The question

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.

Edition:

From time to time, I revisit old pages I've published, and work through them as if I didn't know how to do what the page explains. I have done that with this page, using Windows XP and Open Office version 3.2.1. What is here should work with any post- version- 2 edition of Open Office, but it should work exactly as stated with OO 3.2.1

I don't, in general, like having to update things. However, in the case of Open Office, I have found updating to be worthwhile. (That link will open in a new tab or window, so you can get back here easily afterwards if you want to know more about my views on updating OO.)

What do we need... What will our database schema be?

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.

The route to success... stepwise development

Always start small, and build things up. But try to know where you are going before you take those first steps.

Creation of the database began with building the simple table "CaseShapeTable" described above.

To recap things I've already said: The database's only table has the following fields....

NAME      //  PROPERTIES   //   SAMPLE VALUES
----------------------------------------------
ID        //  Text, 5 characters, primary key // PC01, PC02... PC10, PC11...
CaseShape //  TinyInteger // 0, 1 , 2 or 3

I set the "Entry Required" property of the first field to "Yes". Enter PC01, PC02, etc (i.e. not PC1, PC2) for the first 9 PCs, and you won't have odd sequences when you list the records by ID.

Once the (empty) table was in place, a form was started, using the Form Wizard. Answers to many of the wizard's questions were, I hope, obvious. To be on the safe side, here are the choices I made, in an abbreviated presentation....

(The "DE" suffix signifies "Data Entry")

So far so good... that "should" work... and it 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 (October 2010) 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 was very new to Linux, and back then, my Ubuntu box was only recently set up.

ANYWAY... I then used the form to enter some data.

... 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.

Added a "Group Box" control to the form from the "More Controls" toolbar.

If you need help accessing the More Controls toolbar, visit my "Naming of Parts" note on that and the Form Controls toolbar. It will open in a new tab or window. The "Group Box" control is number 13 in the image... a square surrounded by a dotted line containing two lines each consisting of ". _"

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 dragged one 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.

I then answered the next question "Should one... be... default" NO, and clicked Next.

The next stage of the wizard, the one where "Field Values" appears in the dialog title, assigns the values that should be assigned to each option. ooBase had already set things up the way I wanted them... but this wasn't immediately obvious to me.

The window had an edit box on the left under "What value do you want to assign to each option?". (One could argue that this might be better labeled "What value do you want to assign to this option?".) The edit box is showing the value which will be assigned to the field if you click on the radio button (which will be created in a moment) with the label shown by the currently selected line in the "Options Fields" memo at the right hand side of the window. When I clicked on the different possible values in the memo, the way the dialog worked became more clear to me.

You can change the contents of the edit box. Whatever is in the edit box will be what is "automatically typed" by clicking the radio button which is currently selected in the memo. To set what is "automatically typed" when you click one of the OTHER radio buttons, CHANGE which line is selected in the "option fields" memo, which can be done most simply 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.

Click Next.

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.

Save the form and close it, 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.

Be sure that you are entering new records... not just editing old ones... if that's what you are meaning to do. Changing "PC01" to "PC03" doesn't create a new record! It merely changes the ID of the old PC01 record to PC03. Use the navigation bar (or ctrl-alt plus the left or right arrow keys) to move from record to record. If you "go past" the last record in the table, you will have a blank form into which you can type a new record. Alternatively, use the "new record" button-icon on the navigation bar.

N.B.: If you open up a "raw" view of the table, to monitor your success (or otherwise, sigh) at entering records with your form, you need....

So far, so good!

(A little "gee whiz": The first time I made an option group box, 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 which were put onto the form by the form wizard.

Points to consider

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. Put in "0" (zero) for the default value... our code for "don't know". (See below regarding defaults). Save your changes, close the window, reopen the data entry form and see how well it works!

A Problem: some database designers would be unhappy with using the codes (0, 1, 2, 3 for "unknown", "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 u, 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.

There is a BIG difference between "no datum entered" and "unknown" when you are working with databases.

In the database just described, we have "cheated". No record will be in a "no datum entered" state, as far as the CaseShape field is concerned... but to a user of our radio button based form, there will appear to be records where none of the "admitted to" values for CaseShape has been assigned for that computer. We've arranged things so that a "special" default (zero) is supplied by the table design, for instances where the user doesn't specify a CaseShape. This allowed us to say "No" to the "Should one option... be... default?" question during the Options Group wizard; it allowed us to avoid setting one of the options as the default for the field... while still ensuring that every field in every record had something in it.

There will be times when you have "empty" (nothing entered yet) fields in some records in a database... but they can lead to problems, and it may be as well to avoid the situation.

It gets even more subtle... You can have a text field with nothing in it. That is different from a text field which hasn't has anything entered! But don't worry too much about these things! I suspect you'll be able to deal with the times they matter as they arise... now that you are alerted to the subtleties!



Editorial Philosophy

I dislike 'fancy' websites more concerned with a flashy appearance than for good content. For a pretty picture, I can go to an art gallery. Not everyone has fast broadband.

I present this material in a format aimed at to helping you USE it. There are two aspects to that: The way it is split up, and the way it is posted. Details at my page about how the material is split up and how it is posted.

Please remember the material is copyright. (TK Boyd, 2006 and later) The procedures in the page just cited are suggested only for convenient personal use of the material, however, also....

Feel free to use this information in computer courses, etc, but a credit of the source, quoting the URL, would be appreciated. If you simply copy the pages to other web pages you will do your readers a disservice: Your copies won't stay current. Far better to link to the original pages, and then your readers will see up-to-date versions. For those who care- thank you. I have posted a page with more information on what copyright waivers I extend, and suggestions for those who wish to put this material on CDs, etc. (There is at least one prison using the material for inmate education. Situations do exist where good internet connections are not possible!)

Translations are welcomed. Tell me about yours, so I can post links to it. (More information at the page about copyright waivers.)


Ad from page's editor: Yes.. I do enjoy compiling these things for you... I hope they are helpful. However.. this doesn't pay my bills!!! If you find this stuff useful, (and you run an MS-DOS or Windows PC) please visit my freeware and shareware page, download something, and circulate it for me? Links on your page to this page would also be appreciated!

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.




Valid HTML 4.01 Transitional Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.orgMostly passes. There were two "unknown attributes" in Google+ button code. Sigh.


One last bit of advice: Be sure you know all you need to about spyware.

. . . . . P a g e . . . E n d s . . . . .