HenryAnthony
Technical User
This is strange. I have a form and whenever I set a control's tab index to "6" tab order goes to "5" and then back to "0". Any ideas?
Henry
Henry
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Strange tab index problem? 3
- Thread starter HenryAnthony
- Start date
- Status
More info please... What version of Access? Is Tab Stop set to yes? How many controls on the form? This will help someone help you... Terry M. Hoey
th3856@txmail.sbc.com
While I don't mind e-mail messages, please post all questions in these forums for the benefit of all members.
th3856@txmail.sbc.com
While I don't mind e-mail messages, please post all questions in these forums for the benefit of all members.
-
1
- #3
You're probably just experiencing the normal way Access interacts with the Tab Index. Access has to have the Tab Index properties numbered from 0 to whatever at all times. But it lets you change them, so that you can specify the order. However, as soon as you assign a value, Access figures out what position you want that control, and renumbers all the Tab Index properties from 0 to whatever to put it in that position without changing the relative order of any of the other controls.
To keep from having things change around on you, all you have to do is set your Tab Index properties in ascending sequence. Or, use the Tab Order dialog box in Design View, which is easier. Rick Sprague
To keep from having things change around on you, all you have to do is set your Tab Index properties in ascending sequence. Or, use the Tab Order dialog box in Design View, which is easier. Rick Sprague
- Thread starter
- #4
HenryAnthony
Technical User
Access 97, 20 controls on form. Combination of fields, command buttons, check boxess. Also a subform. Tab stop set to Yes. I understand how the tab index order works. Other forms work OK. Just this one won't. I will rebuild the form from scratch and see what happens. Thanks for your replies to this minor yet annoying problem.
Henry
Henry
Is it only within the subform that you're having the problem? When you have a subform, there two two distinct tab orders, one for the form and one within the subform. (This also happens with tab controls, by the way.) The subform control's tab index specifies its tab order within the main form's controls. The controls in the subform have their own order, which applies when the main form's subform control has the focus.
Because of the way this works, you can't mingle the subform controls within the main form's tab order. Also, once the subform gets control, you can't get out of it by pressing Tab--you have to press Ctrl-Tab to get back to the main form.
In Access 2000, you can see the subform's controls while in design view, but not in Access 97, So you probably aren't confusing the subform's tab order with the main form's. But I thought I'd mention it, just in case. Rick Sprague
Because of the way this works, you can't mingle the subform controls within the main form's tab order. Also, once the subform gets control, you can't get out of it by pressing Tab--you have to press Ctrl-Tab to get back to the main form.
In Access 2000, you can see the subform's controls while in design view, but not in Access 97, So you probably aren't confusing the subform's tab order with the main form's. But I thought I'd mention it, just in case. Rick Sprague
- Thread starter
- #6
HenryAnthony
Technical User
Rick, that is good advise but not helpful to my particular situation. My problem is in the main form. I've tried deleting the subform and every other control one at a time and the problem persists. As I rebuild the form, there is no problem. I am probably spending more time on this than it is worth but this is one of those things I just want to find out why gosh darn it!
Henry
Henry
I know what you mean--it's nagging at me, too.
If you want to keep analyzing it, tell me, when you change a tab index to 6, and then it changes to 5, and then it changes to 0, does it do it right before your eyes, without you doing anything else in between? And what happens to the tab indexes of other controls that had 0 to 5? What kind of controls are these? Do you end up with duplicate tab indexes, or index values not used by any control? Rick Sprague
If you want to keep analyzing it, tell me, when you change a tab index to 6, and then it changes to 5, and then it changes to 0, does it do it right before your eyes, without you doing anything else in between? And what happens to the tab indexes of other controls that had 0 to 5? What kind of controls are these? Do you end up with duplicate tab indexes, or index values not used by any control? Rick Sprague
- Thread starter
- #8
HenryAnthony
Technical User
OK. This is even more odd than I thought. Here is the situation. I have deleted everything from the form other than the 6 controls in question. 4 controls are bound text boxes, 2 are combo boxes. There is one particular field named "Status" that, when tab index is set to 6 you cannot tab to the field. If I change it to any other number tabbing works properly.
I have deleted the field and dragged it back to the form from the list and it still won't work.
I have rebuilt the form from the same query as original and the problem is fixed. THEN if I delete the "Status" field from the new form, copy and paste the problematic text box from the original form to the new one, delete it from the new one and then drag the field back in from the field list the problem is recreated on the new form. I'm no software engineer but there must be some kind of corruption going on here. Thanks for your interest.
I have deleted the field and dragged it back to the form from the list and it still won't work.
I have rebuilt the form from the same query as original and the problem is fixed. THEN if I delete the "Status" field from the new form, copy and paste the problematic text box from the original form to the new one, delete it from the new one and then drag the field back in from the field list the problem is recreated on the new form. I'm no software engineer but there must be some kind of corruption going on here. Thanks for your interest.
After you delete Status from the new form, then paste the malfunctioning Status from the other form, does it work right? (You said that when you followed this by deleting the pasted one and dragging from the field list again it malfunctioned.)
You shouldn't even be able to set this control's tab index to 6. It should change to 5 on the spot if you do, since there are only 6 controls and they're numbered from 0. I tried to duplicate your form, with 4 text boxes and 2 combos. I changed one of the text box names to Status, then tried to set its tab index to 6. Access scolded me and told me to use 0 to 5.
Does the View>Tab Order dialog look normal? Check it for unaccounted-for controls. Also make sure there are no controls in your form's header or footer.
The controls we see in the toolbox are regular VB controls "wrapped" in a layer so that Access can make sure you don't do anything that would change something Access depends on. There may be properties of the underlying control that are not exposed to us. I'm getting a hunch that there is such a property named "Status", and because you've named your control the same you're revealing a bug in the Access layer. I'd be interested in experimenting with modifying the name of this control.
Was this form created the normal way, as opposed to, say, importing or converting it from a previous version of Access? Rick Sprague
You shouldn't even be able to set this control's tab index to 6. It should change to 5 on the spot if you do, since there are only 6 controls and they're numbered from 0. I tried to duplicate your form, with 4 text boxes and 2 combos. I changed one of the text box names to Status, then tried to set its tab index to 6. Access scolded me and told me to use 0 to 5.
Does the View>Tab Order dialog look normal? Check it for unaccounted-for controls. Also make sure there are no controls in your form's header or footer.
The controls we see in the toolbox are regular VB controls "wrapped" in a layer so that Access can make sure you don't do anything that would change something Access depends on. There may be properties of the underlying control that are not exposed to us. I'm getting a hunch that there is such a property named "Status", and because you've named your control the same you're revealing a bug in the Access layer. I'd be interested in experimenting with modifying the name of this control.
Was this form created the normal way, as opposed to, say, importing or converting it from a previous version of Access? Rick Sprague
-
2
- #10
I'll throw my 2 cents in here and Rick, it's for sure. Status as a field name is a no no. It must be bracketed or all hell breaks loose. Having fought with Me.Status for a length of time, all was fine when replaced with Me![Status].
Good luck Gents! Gord
ghubbell@total.net
Good luck Gents! Gord
ghubbell@total.net
Gord, thanks! I'd always wondered why Access-generated code insists on using the brackets even when there are no syntax-disrupting characters in the name, but now I guess I know. I had been using and promoting the rule that you only have to use brackets when they would prevent a syntax error, but now I think I'll use (and recommend using) them all the time. Rick Sprague
- Thread starter
- #12
HenryAnthony
Technical User
Sorry if this is a duplicate post. Something went weird on our network and wasn't sure if it went through.
Rick,
>>After you delete Status from the new form, then paste the malfunctioning Status from the other form, does it work right? <<
No
>>You shouldn't even be able to set this control's tab index to 6.<<
You are correct. I was wrong in stating 6 controls. There are 7. Looking at the index number made me say 6 (duh).
>>Does the View>Tab Order dialog look normal?<<
Yes
>>Check it for unaccounted-for controls. Also make sure there are no controls in your form's header or footer.<<
None and No
>>I'd be interested in experimenting with modifying the name of this control.<<
I will try and let you know what happens
Was this form created the normal way, as opposed to, say, importing or converting it from a previous version of Access?
All normal: 1. Form 2. New 3. Select the query 4.Drag fields from field list
Gord,
>>Status as a field name is a no no.<<
As a field name in a table it has never caused any problems. I am not using it in any code but will keep your tip in mind. Also, when I rebuild the form from scratch everything works fine but I will try renaming.
Thank you guys, this is just something screwy.
Rick,
>>After you delete Status from the new form, then paste the malfunctioning Status from the other form, does it work right? <<
No
>>You shouldn't even be able to set this control's tab index to 6.<<
You are correct. I was wrong in stating 6 controls. There are 7. Looking at the index number made me say 6 (duh).
>>Does the View>Tab Order dialog look normal?<<
Yes
>>Check it for unaccounted-for controls. Also make sure there are no controls in your form's header or footer.<<
None and No
>>I'd be interested in experimenting with modifying the name of this control.<<
I will try and let you know what happens
Was this form created the normal way, as opposed to, say, importing or converting it from a previous version of Access?
All normal: 1. Form 2. New 3. Select the query 4.Drag fields from field list
Gord,
>>Status as a field name is a no no.<<
As a field name in a table it has never caused any problems. I am not using it in any code but will keep your tip in mind. Also, when I rebuild the form from scratch everything works fine but I will try renaming.
Thank you guys, this is just something screwy.
Your very welcome Rick. The real point is though, we all have to learn or sort of try to remember, the Access reserve words. Working with the dot is a real time saver and does give a sincere compile when you do compile. I use the dot as much as possible for this reason and (bang!..head on desk again..) have learned to always choose "abnormal" field names... "GordStatus" or "GordDate". Fix how they are seen with their "Caption" property. Date. Now there's the biggest nightmare I've ever seen.... Gord
ghubbell@total.net
ghubbell@total.net
Gord,
In this case, though, Status is not a reserved word, keyword, or documented property. My speculation was that it's a hidden property. We shouldn't be expected to remember not to use those!
I used to have constant problems with fields I called "Name", which really is a property name. For some reason, it seemed to give me a problem more with reports. But now I'm on the lookout for that problem.
I don't know why you think using "." instead of "!" is a real timesaver, but if I were you I'd get out of the habit real soon. Besides getting the wrong thing if your field has a property name, I think I remember reading that it won't work any more in Office XP or VB.Net. Syntax has really been tightened up in VB, and I'm that surely means in VBA. Rick Sprague
In this case, though, Status is not a reserved word, keyword, or documented property. My speculation was that it's a hidden property. We shouldn't be expected to remember not to use those!
I used to have constant problems with fields I called "Name", which really is a property name. For some reason, it seemed to give me a problem more with reports. But now I'm on the lookout for that problem.
I don't know why you think using "." instead of "!" is a real timesaver, but if I were you I'd get out of the habit real soon. Besides getting the wrong thing if your field has a property name, I think I remember reading that it won't work any more in Office XP or VB.Net. Syntax has really been tightened up in VB, and I'm that surely means in VBA. Rick Sprague
Rick,
I knew I had seen this discussion before. Try to get your hands on a copy of July 99 Access-Office-VB Advisor from . Contributing writer Andy Baron has a wonderful article describing the virtues and proper use of both the "bang" ! and the dot, titled "Cleaner Coding: Bang vs. Dot. I'll quote a bit here for all: "It's just a coincidence that most of the things you name in Access end up in collections. Use bangs because they're being identified as members of a collection, not because you named them. FormName!ControlName is actually shorthand for FormName.Controls!ControlName - the controls collection can be left out because it is the default property of an Access form." More... "A dot is used to seperate an object from a property or method of that object. Using the dot here is completely kosher, because Access provides two totally different programmatic routes to the controls on a form. In addition to ControlName being a member of the controls collection of the form, it's also a property of the form. If you check the Object Browser, you'll find that everytime you add a control to a form (or report), Access adds a property with the same name and type <- Gord: another evil word to name a field> as your control to the form's class in your VBA project." "One big advantage of using the dot in VBA is that unless there's a bang earlier in the expression, you'll get a handy Intellisense drop-down list, showing you all the properties you can choose from. Your form's controls and fields will be on the list which saves time, and prevents typing errors." "Using dots rather than bangs also makes your code run a bit faster. Your users are unlikely to notice a difference, but every little bit of performance helps!" "The downside of using the dot? You may run into trouble if your control or field has the same name as one of the built-in properties of a form-so don't do that!" (Now we know all about that part....) Mr. Baron concludes "Old habits die hard, but this old use of bangs in Access code may be worth changing. Try it!"
Well at least it's nice to have a choice!
All quotes here are from Mr. Andy Baron and without permission. Sorry Andy, but thanks very much for a good read!
Gord
ghubbell@total.net
I knew I had seen this discussion before. Try to get your hands on a copy of July 99 Access-Office-VB Advisor from . Contributing writer Andy Baron has a wonderful article describing the virtues and proper use of both the "bang" ! and the dot, titled "Cleaner Coding: Bang vs. Dot. I'll quote a bit here for all: "It's just a coincidence that most of the things you name in Access end up in collections. Use bangs because they're being identified as members of a collection, not because you named them. FormName!ControlName is actually shorthand for FormName.Controls!ControlName - the controls collection can be left out because it is the default property of an Access form." More... "A dot is used to seperate an object from a property or method of that object. Using the dot here is completely kosher, because Access provides two totally different programmatic routes to the controls on a form. In addition to ControlName being a member of the controls collection of the form, it's also a property of the form. If you check the Object Browser, you'll find that everytime you add a control to a form (or report), Access adds a property with the same name and type <- Gord: another evil word to name a field> as your control to the form's class in your VBA project." "One big advantage of using the dot in VBA is that unless there's a bang earlier in the expression, you'll get a handy Intellisense drop-down list, showing you all the properties you can choose from. Your form's controls and fields will be on the list which saves time, and prevents typing errors." "Using dots rather than bangs also makes your code run a bit faster. Your users are unlikely to notice a difference, but every little bit of performance helps!" "The downside of using the dot? You may run into trouble if your control or field has the same name as one of the built-in properties of a form-so don't do that!" (Now we know all about that part....) Mr. Baron concludes "Old habits die hard, but this old use of bangs in Access code may be worth changing. Try it!"
Well at least it's nice to have a choice!
All quotes here are from Mr. Andy Baron and without permission. Sorry Andy, but thanks very much for a good read!
Gord
ghubbell@total.net
Gord,
Well, you've finally answered a question I've had for years! I knew that the dot worked for fields on a form or report, but I never knew why, and I never saw any documentation that Access creates a property for you. So I always worried it wasn't Kosher. Since it is, though, and it's clear that a property lookup will be faster than a collection lookup, I can understand Baron's recommendation.
You jogged my memory. I remember now that the syntax tightening in .Net is that there will be no default properties for objects. My jaw dropped when I read that! Can you imagine how much code that breaks?
(The reason for it has to do with .Net getting rid of the Set statement. The Let statement (with the Let keyword still optional) will be used to assign to both variables and objects. But this creates an ambiguity if default properties are allowed: Does "myvariant = Me" assign the form object, or the form's Name (default property)? They resolved the ambiguity by abolishing default properties.
What Microsoft had against the Set statement, I have no idea! Rick Sprague
Well, you've finally answered a question I've had for years! I knew that the dot worked for fields on a form or report, but I never knew why, and I never saw any documentation that Access creates a property for you. So I always worried it wasn't Kosher. Since it is, though, and it's clear that a property lookup will be faster than a collection lookup, I can understand Baron's recommendation.
You jogged my memory. I remember now that the syntax tightening in .Net is that there will be no default properties for objects. My jaw dropped when I read that! Can you imagine how much code that breaks?
(The reason for it has to do with .Net getting rid of the Set statement. The Let statement (with the Let keyword still optional) will be used to assign to both variables and objects. But this creates an ambiguity if default properties are allowed: Does "myvariant = Me" assign the form object, or the form's Name (default property)? They resolved the ambiguity by abolishing default properties.
What Microsoft had against the Set statement, I have no idea! Rick Sprague
- Thread starter
- #17
HenryAnthony
Technical User
Gord and Rick,
I'm glad I started this thread. While I will probably never understand my original problem, I have certainly learned how to avoid others in the future.
Best regards,
Henry
I'm glad I started this thread. While I will probably never understand my original problem, I have certainly learned how to avoid others in the future.
Best regards,
Henry
- Status
Similar threads
- Locked
- Question
- Locked
- Question