Designing forms - what is important?

sunset1215

Registered User.
Local time
Today, 21:12
Joined
Apr 7, 2011
Messages
46
Hi all,

I'm working on creating a database, and i've already set up the tables and relations. Right now, i'm stuck on the forms. My idea of forms is just forms with subforms, so you can update all the related data in the same form.

But now that i'm designing the forms, i find that my forms are very cramped, or that i have a lot of subforms. So i was wondering, what is important when designing forms? how do you know when to put a subform and when not to put a subform? If you say related data, but the whole database itself is related isn't it?
 
I’m sure you will get lots of interesting answers to this question.
1. Lots of subforms. Use a tab control to manage the subforms. You can set it up so that you load the appropriate form in its Subform control only when that particular page of the tab control is clicked. This makes your database work faster, because when you open the form it only needs to load one subform, not a whole lot of subforms.
2. Allow users to search for a customer by name, before they hastily add a new customer.
3. Allow users to search before they hastily add a new of almost anything where there is likely to be a long list of those things.
4. A search form is an art in itself.
I like the search form here:
http://www.allenbrowne.com/ser-62.html
 
The most important aspect of form design is properly nomalized table structure behind it. Poor normalization can make for very clumsy forms.

It is really important not to present too much data at once. It might looked cramped to you but you manage because you have built familiarity during the design. The poor novice user just sees a bewildering nightmare.

Don't underestimate the value of whitespace. I have seen work from professional designer of considerable repute where they get this very wrong.

Sometimes it is better to pop up a form for the data entry than to have it as a subform. This allows plenty of room for entry without cramping the main form. A summary of the same data can be also be presented in a listbox for display only.

For example one might have a main form displaying data about a person. You can edit their main details here. Their children's name would be displayed in a listbox. Clicking on the entry in the listbox would pop up another instance of the main form to enter the child's details.

You can sometimes save yourself a lot of effort by reusing forms. This is generally easier with good normalization.

Making unnecessary controls invisible or disabled in a logical way is very important. It helps guide the user's attention. I always indicate editablity of textboxes by showing or hiding the border.

There are a lot of good tricks with mixing bound and unbound controls but this is an art.
 
the search form in the link looks really complicated. i will have to study it in more detail at home later.

about using tabbed controls. what if i have a subform in my subform again? also, it seems to me that navigating the sub-subforms is difficult. if i show the navigation buttons for my main form, subform and sub-subform, it looks confusing and all. sometimes i might even lose track of which record i'm at.

i once tried a method by creating buttons to open the related form in a new tab or popup, but the forms aren't linked when i create them separately. the primary key doesn't automatically get transferred. i have to use vba to copy my PK's value into the FK. Although it works, but i do not feel it is safe, and that it is prone to errors.

my knowledge of access is still very limited, so i may have misconceptions. please do correct me if i'm wrong.
 
With Search forms I like to have one box that searches multiple fields and then have a list box at the bottom. I also like using the on change event so the selection changes everytime a letter is typed. Frequently never need to finish the full search string as certain strings are almost unique after only a handful of letters are typed. The user then goes to the individual record by clicking on the line in the list box.

It will however depend on how many records you have.

I have only really written databases for smallish numbers of very high value items eg 2000 record CRMs / fixed asset registers.

In this case if you enter a first name or a surname chances are there will be very few examples. And if the list box contains other fields as well the user is usually able to determine which record of usually only a handful they are interested in and click on it rather than having to add additional searches. I really don't see the point of being able to select records based on an AND select of 5 fields with so few records.

I suspect you only need those more powerful search commands when you get into the hundreds of thousands of records in which case being faced by 100 Pauls maybe an issue. Even then in the UK though you could just input their postcode rather than name and that would probably do it.

I do quite a bit of triathlon races and getting quicker is a lot about simplicity. Bells and whistles on your bike? Take em off. Socks NO.

Less is more - and you pay for the privilege as well!!!! (bikes anyway)
 
i once tried a method by creating buttons to open the related form in a new tab or popup, but the forms aren't linked when i create them separately. the primary key doesn't automatically get transferred.

Use the OpenArgs argument of the OpenForm Method to do this.
 
One thing is to differentiate between search and data entry. They should be handled seperately. I'm just gonna talk on search forms because it's what I know.

The way I got my search forms cleaner is that I eliminated datasheets in my forms entirely. They are bulky, have locking editing concerns, and all sorts of other issues. Listboxes will give you the same functionality in almost every way when you are operating in read only mode, plus finer control of which columns exist and the awesome abilities to click through drill downs or right click contextual menus, or multiselect drill down.

The latter are some of the best ways to keep forms clean and intuitive. People like to click. Give them their clicky. Limiting noise is a big deal to me in these things.

That linked form, I dunno. I like the multiple selections. The record selection at the bottom makes me wince though. Record selections should not appear in search forms, that's why you are searching. And, why use a datasheet view? That view has some intrinsic inferred qualities, like the ability to edit, which shouldn't exist in a search form. But hey, like was mentioned above, there are going to be a LOT of different answers to this.

The main reason I thought to respond was that what it sounds like you are doing is similar to stuff I did with my first set of forms. Lots of russian dolls, forms within forms, which made things look really rough in the end.

Now I am just a big fan of seperate windows for stuff. That also allows you the computing ease of not having to run every query for every subform when it loads.
 
thanks all for the great input. i guess it's true when they say that the uses of access is only limited to your imagination. (i believe i read it somewhere, or it might be my imagination too.)

the progress with my database has stalled these few days. i would be staring at the database, and find myself not knowing what step i should do next. i'm very unsure of myself, and i've changed the tables and relationships for like 4 times already.

and the forms, it's just like emorris said. almost every form of mine has a form within, which made me start to feel like i'm doing something wrong. i feel like i'm stepping backwards for these 2 days instead of forward.

everything i've read up till now says that planning your database is the most important step of all. i'm really at fault here as i was rushing a bit, anxious to see the results. i'm going to use the weekend and re-plan the database again. hope that would help clear the blocks in my mind.


@Galaxiom
i didn't know there's a OpenArgs for the openform command. could you kindly post me an example?
 
Last edited:
i didn't know there's a OpenArgs for the openform command. could you kindly post me an example?

The OpenArgs argument is a Variant datatype that resolves to a string that becomes the OpenArgs property of the Form that is opened with the command. Pretty much anything can be done with it.

One of the most common is to set the value of new records created in the form, basically doing the same job as the LinkMaster and LinkChild fields in a subform.

The command to open the popup from the calling form:
Code:
 DoCmd.OpenForm "formname", , , , , , Me.controlname

In the BeforeInsert procedure of the popup form:
Code:
 Me.controlname = Me.OpenArgs
All new records will have the value from a control in the calling form automatically inserted into the control on the popup form.

If necessary, conditions can be used in the popup form's procedure to define when the argument is used.

OpenArgs is also useful to pass a value to be filtered or indeed the whole filter string. Or to find the record of interest in the popup.

Another way to insert the key automatically in new records of a popup form is to open a form containing a subform control that displays the form where you are wanting to add data. The Where argument of the OpenForm method is used to set the current record on the main form. The LinkMaster and LinkChild fields then load the fields on new records as normal.

The main form can be useful to display the context of the current task around an otherwise fairly anonymous looking form that can be reused in other places.
 
Last edited:
The command to open the calling form:
DoCmd.OpenForm "formname", , , , , , Me.controlname

In the BeforeInsert procedure of the popup form:
Me.controlname = Me.OpenArgs

All new records will have the value from a control in the calling form automatically inserted into the control on the popup form.

If necessary, conditions can be used in the popup form's procedure to define when the argument is used.

OpenArgs is also useful to pass a value to be filtered or indeed the whole filter string. Or to find the record of interest in the popup.

ok. let me see if i understand it.

the control name in Me.controlname is a control on the pop up form right?
so it will be something like:
DoCmd.OpenForm "formname", , , , , , Me.fkCusID

and in the beforeInsert procedure of the pop up form:
me.fkCusID=me.OpenArgs

but what does me.OpenArgs here refer to? somehow the code seems really simple, or i'm only complicating things myself.

Another way to insert the key automatically in new records of a popup form is to open a form containing a subform control that displays the form where you are wanting to add data. The Where argument of the OpenForm method is used to set the current record on the main form. The LinkMaster and LinkChild fields then load the fields on new records as normal.

The main form can be useful to display the context of the current task around an otherwise fairly anonymous looking form that can be reused in other places.

is this using the same OpenForm command? but instead of OpenArgs, you state the where condition in the filter argument?
 
the control name in Me.controlname is a control on the pop up form right?
so it will be something like:
DoCmd.OpenForm "formname", , , , , , Me.fkCusID

and in the beforeInsert procedure of the pop up form:
me.fkCusID=me.OpenArgs

Sorry I should have made that clearer. The First Me.controlname refers to a control (can be a field in a bound form) on the form that is calling the popup form.

The second is the control (or field in a bound form) on the popup form.

The pair work the same as the fields that you would use as the LinkMasterFields and LinkChildFields properties if the forms had been in a form/subform relationship.

(BTW The LinkMasterField can be a control instead of a field)

but what does me.OpenArgs here refer to? somehow the code seems really simple, or i'm only complicating things myself.

Me.OpenArgs is the OpenArgs property of the popup form. It will contain a string that is the resolution of what was entered in OpenArgs argument of the OpenForm command.

is this using the same OpenForm command? but instead of OpenArgs, you state the where condition in the filter argument?

Unfortunatley Microsoft didn't name the Where and Filter arguments very well but we are stuck with it.

The Filter argument is a string that is the name of a query. The Where argument is a string that is just like the Where clause of a query as you use in a form filter (without the Where).
 
ah. it's much clearer to me now. thanks for explaining it. right now i feel that learning access is like learning a new language. you have to speak its language before you can tell access to make things happen for you.
 
It is a new language and it has a rather contextually pedantic interpreter. Morever that interpreter will sometimes take deep offence if you say the wrong thing in the wrong place and provide a rather curt and unhelpful explanation. :rolleyes:

Like struggling with any new language you will sometimes find yourself using a lot of words to explain something complex to the compiler only to discover one day that there is a single equivalent expression that you didn't know about.

Oh, but mastery of the language is a wonderful thing (I expect ;)).
 
yes, you're definitely right about that. it's so frustrating at times when we can't understand each other. i'll be like "What's wrong with you? Why can't you understand me?". and all the while it's just sitting there smirking at me, thinking "Well, i don't understand you. You can either speak my language, or just walk away." (i'm thinking of them as bad guys here. hehe)

i've already borrowed books to read up on access. hopefully i can create the database of my dreams. :)
 

Users who are viewing this thread

Back
Top Bottom