Full Version: Tabbing through Tab Controls - possible? (re-posting)
UtterAccess Forums > Microsoft® Access > Access Forms
I have a form that has a Tab Control with multiple pages. Each page has 1 or more fields on it (not subforms or anything like that). I would like for the user to be able to tab through all the fields on the form, including those on the tab control, but I can't seem to get it to do that.
Is this possible?
balaji tried to help but wasn't able to provide an answer. Anyone have ideas?
Here's the dilemma. I have a macro that runs whenever you move from record to record called GoToNextRecord (it's on the form's OnCurrent event). Among many other things, it sets focus on the first tab of my Tab Control (so that if the user left off on a different tab on the previous record, it puts the first tab in "front") and then moves to another field on the form. Note: the macro specifically refers to the PAGE name (IssueDescription_Page), not the field on it.
Ok, so now we put a macro (that triggers on Lost Focus) called GoToActionPlan on the field (Issue Description) on that page, that puts focus on the field on the next tab.
Hypothetically, I would expect that to work. Unfortunately, when GoToNextRecord fires, it puts focus not on the page (IssueDescription_Page) but on the field on that page (IssueDescription). Because focus is now on the IssueDescription field, the GoToActionPlan macro fires which puts focus on the second tab and the GoToNextRecord event fails.
To try and work around this, I put a test text field on the IssueDescription_Page and set the GoToNextRecord macro to point to that field and then move to the next field I want to have focus, but that didn't help. I also tried putting the GoToActionPlan macro on the Exit event for the IssueDescription field, but that didn't work either.
So, based on my current configuration, it appears that the GoToNextRecord does not differentiate a tab page from the fields on it since it works the same whether you refer to the page or to a field on the page.
This leaves me with the 2 following questions:
How to make a macro differentiate between a tab page and a field on it?
Is there some other way to accomplish my task.
I have attached a stripped down copy of the database to make it easier. Note: The MoveScreenUp field is the yellow box at the top of the Issues form. It is very small, has no fill and no border but I made it bigger to avoid confusion.
Jack Cowley
You are not going to like what I have to say, but your database structure is not normalized. Your table "Issues" has 'repeating groups', your tables do not have Primary Keys and you should consider using standard naming conventions for the objects in your database and do not put spaces in object names...
roperly normalizing your structure is going to make a difference in your form. Some items, like the hyperlinks and the Yes/No fields will become values in a subform, not fields currently on your form.
I would strongly suggest you normalize your structure then revisit your form(s)... It is going to take time but in the long run it will be in your best interest IMHO....
My 3 cents worth..
The naming convention issue I know about...I figured out too late not to put spaces in field names and now they are so entrenched in the macros and codes and formulas, it would be a pain to change them.
Is for normalization...I don't know what that means. Can you explain? Also, what are repeating groups?
Jack Cowley
Normalization is the foundation that you build your database on and with your Issues table you have a 'weak' foundation. There are many articles here in the Archives on normalization and there is a ton of information available to you on the Internet, but I suggest you start by reading this article.
nce you have the gist of Normalization then you want to break out the 'repeating groups' (Yes/No, hyperlinks) and put them in related tables, where they belong. As an example lets assume you have 5 Yes/No fields in your current table that are about Responses. Here is what that table would look like:
ResponseID (PK and auto)
ResponseDescription (Text)
Now you need another table...
IssusesAndResponsesID (PK and auto)
IssuesID (FK to tblIssues)
ResponseID (FK to tblResponses and will be a combo box on your form)
Response (Yes/No)
Oknow this is confusing as it is very different that working in the world of paper forms and the way you have done things before you discovered a Relational Database called Access...
One of the reasons for the other tables is - What if you need to add another response Yes/No field to your table in 6 months? As your table stands you have to modify the table and then change every form and query in the db that use that table. With the above you simple add a new record to the tblResponses and you have to change nothing...
Crud...the link didn't work. Can you re-create it?
Here's the stupid part...I'm ok with a goodly chunk of Access but I really don't understand relationships, joins, referential integrity, primary and foreign keys, etc. Obviously, that's a little like saying I'm ok with Excel but don't understand add, subtract, multiply and divide...a hole in my knowledge you could fly the space shuttle through.
Osuppose I best bite the bullet and actually learn that part (keeping in mind I'm sitting here at my desk with a 1300 page book called the Access Bible).
Yipes! That's a bit overwhelming and I don't know if I have that much time (I have a set window of time in which I have to finish the database).
Jack Cowley
I'm sorry about the link. Try this and see if it works...
You are in the boat all of us have been in at one time or another. We start out with tables and forms and nobody let us know about normalization until we were well into a project and things start going South, at a rapid rate, and work arounds were getting harder and harder to implement. Normalization is not the easiest concept to grasp, but I am confident that you will come to grips with it in short order. Just be patient as it will test your patience...
Now look in the Index of the Access Bible and see if the mention Normalization and if they do read what they have to say... I don't have the book so I don't know how thorough it is. There is a lot of information in our Archives and on the Internet so you should have plenty of resources at your fingertips...
Good luck and if you have questions you know where to come for assistance... uarulez2.gif
Yes, that worked. Ok, looks like I have a lot of reading to do tomorrow.....
Jack Cowley
Yep, you have your work cut out for you for the next bit of time. I realize that you have to finish the db by a given time and going back to the beginning seems like a huge waste of time, but it may actually save you time in the long run. Trying to get data out of the db, if it is not normalized, can take up more time than you will spend getting it right from the get-go...
Good luck! o!
Please take what Jack is saying to heart and fix the issues with your database now. Can a work around done...probably...but I can assure you that once you get this database working the way they want it NOW, they will change their minds about something or want to add something new to it and one day you will have to rebuild the database which will involve more time as you will have a database that is always being used while you are trying to rebuild it.
I have learned this lesson the hard way (several times)!
PS...Hi Jack sad.gif
Jack Cowley
Thanks Lena! PM has been sent...
I mentioned to my manager that the database needs normalization and that I need to do some reading and research regarding it. His first question was "what is the benefit of doing it?" and his second question was "what are the implications if we don't?". I told him I don't know the answer to those questions yet.
Can you provide insight or does the link you included already address that?
From my experience the implications of not doing so is the possibility of incorrect information in your reports. Also, your manager may decide that he wants to view the information in a different format and it may not be possible without having the database normalized. He may tell you now that he won't want it changed, but in the many databases that I have made, there is only 1 that I haven't made additional changes too (and that is most likely cause I don't work for that department anymore).
The benefits of doing so is many. First off, you should do this so that you learn to use access correctly, second it will take less work on the part of those entering the information as there won't be redundant information being entered. Getting information out of the database in an understandable format will be much easier.
Let me explain the redundant information...lets say that you are creating a database about people and you are storing their addresses. If I was making this database I would store the City, State and Zip Code in a table. In the table that holds the persons address I would only have the Zip Code. When putting the information together (for example Mailing Labels) I would pull the City and State onto the label using the Zip Code. Now if you have a database that holds information for only a handful of people it wouldn't be such a big deal...but imagine if this database held the information for 1000s of people. Typing the City, State and Zip Code for each person would be a waste of time.
There are many other reasons for building a database the right way!
Jack Cowley
The benefits are that your database will work. You can make a non-normalized database work, but finding ways to make it work can drive you nuts. The amount of time you would spend finding a work around would have been much better spent normalizing the structure in the first place.
The implications are that getting the results you need from the database may mean unneeded hours of looking for the elusive work around that I just mentioned. I am trying to think of an analogy and the only thing that comes to mind is a building a house with a bad foundation. The further you get into construction the more difficult it becomes because the foundation does not support the structure.
Let me try to give you a simple example. Lets make a survey and here is our question table:
QuestionID (PK and auto)
A week after you have your forms and stuff working the boss says, "We need to add two more questions!" Your only alternative is to add two more questions to the table and change all the forms related to this table and possibly others as well.
If we design our question table like this:
QuestionID (PK and auto)
Now we can have 1 question in our survey and next week we can have 5 and the week after 10 and with no changes necessary to our table as all we do is add a new record (question) to the table using a form. This means that once the db is done ANYONE can add or delete questions with simple changes made to the table via a form.
I hope this makes sense and if your boss is undecided then tell him that my dad always told me that if the job is worth doing it is worth doing right....
Good luck!!!
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.