If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
Tab Form navigation
Brendan,
You're not quite right here. The problem is that the arrow keys do not navigate "properly" through an option group if you have two or more columns of buttons, so code IS requirted to fix this. As I found out from discussing this with someone else here recently, "the cursor (down arrow) always goes to the next option whose Top property is = the current option." In other words, if you have two columns of buttons, the down arrow bops around between the two columns instead of going down the first column and then down the second (likewise with the up arrow). I already adapted the code you posted to fix this (I used the form's KeyDown event) and it works great. However, the total number of buttons has to be hard-coded into that routine. I was simply wondering here if the program could find out the number of buttons instead of me hard-coding that value. That way if the number of buttons changes, then the code doesn't have to change. ctdak "Brendan Reynolds" wrote: The arrow keys navigate through the controls in an option group, no code required. An option group does have a Value property, which returns the Value of the selected control within the option group. It also has a Controls property, which returns a collection of the controls contained in the option group - this includes labels as well as check boxes or radio buttons. The main difficulty in adapting the code I posted to work with an option group, though, is that an option group does not have a KeyDown event. Perhaps it might be possible to use the form's KeyDown event (set the form's KeyPreview property to 'Yes' before trying to use this event) and check the ActiveControl property to determine whether one of the controls in the option group is the active control. I wouldn't do it myself, though - not when the arrow keys already provide the desired behaviour for free. -- Brendan Reynolds "ctdak" wrote in message ... Brendan, Thanks for doing all the work for me. The pieces of the coding puzzle I was missing here were the ".Value" and the ".Pages.Count". This is what I was looking for. It works great. Would you happen to know if the same kind of thing can be done with an option group? In other words, is there a way for the program to know how many option buttons exist (similar to "Pages.Count") and which option button the user is currently on (similar to ".Value"). ctdak "Brendan Reynolds" wrote: Private Sub TabCtl0_KeyDown(KeyCode As Integer, Shift As Integer) Select Case KeyCode Case vbKeyPageDown If Me.TabCtl0.Value Me.TabCtl0.Pages.Count - 1 Then Me.TabCtl0.Value = Me.TabCtl0.Value + 1 Else Me.TabCtl0.Value = 0 End If Case vbKeyPageUp If Me.TabCtl0.Value 0 Then Me.TabCtl0.Value = Me.TabCtl0.Value - 1 Else Me.TabCtl0.Value = Me.TabCtl0.Pages.Count - 1 End If Case Else 'do nothing End Select End Sub -- Brendan Reynolds "ctdak" wrote in message ... I appreciate your responses, but you're missing my point. Let me be more specific. I want to enable the PageDown key to move the user to the next sequential tab (from whichever tab he is currently on), and to enable the PageUp key to move the user to the previous sequential tab (from whichever tab he is currently on). What Bob showed me earlier will only move to one particular tab all the time. So, as I said I need a way to know the user's current tab in order to know which tab to move him to. ctdak "Al Camp" wrote: ctdak, Not true. Either method above will move to the correct tab, no matter where you are on the main form. -- hth Al Camp Candia Computer Consulting - Candia NH http://home.comcast.net/~cccsolutions "ctdak" wrote in message ... Great, this is along the lines of what I was looking for. But the program has to know which tab the user is moving from in order to move the user to the right one (the next one with a PageDown key press for instance). Is there a way to ascertain the user's current tab, perhaps by the tab caption or some other tab property? ctdak " wrote: Code to move to the second tab of a tab control named TabCtl0 (not a very meaningful name). Note that tab controls are zero based, so (1) is the second tab.... Me.TabCtl0.Pages(1).SetFocus Bob |
#12
|
|||
|
|||
Tab Form navigation
Thanks for the clarification. I don't think I've ever used an option group
with more than one column. If I had that many options, I'd go for a combo box or list box rather than an option group, as it takes less screen space. As I mentioned previously, the Controls collection of an option group includes all controls in the option group, including labels. Usually, each button or check box in the option group will have a label, and the option group itself will have a label. Therefore *usually* the number of buttons or checkboxes in the option group will be (NameOfOptionGroup.Controls.Count - 1) \ 2 -- Brendan Reynolds "ctdak" wrote in message ... Brendan, You're not quite right here. The problem is that the arrow keys do not navigate "properly" through an option group if you have two or more columns of buttons, so code IS requirted to fix this. As I found out from discussing this with someone else here recently, "the cursor (down arrow) always goes to the next option whose Top property is = the current option." In other words, if you have two columns of buttons, the down arrow bops around between the two columns instead of going down the first column and then down the second (likewise with the up arrow). I already adapted the code you posted to fix this (I used the form's KeyDown event) and it works great. However, the total number of buttons has to be hard-coded into that routine. I was simply wondering here if the program could find out the number of buttons instead of me hard-coding that value. That way if the number of buttons changes, then the code doesn't have to change. ctdak "Brendan Reynolds" wrote: The arrow keys navigate through the controls in an option group, no code required. An option group does have a Value property, which returns the Value of the selected control within the option group. It also has a Controls property, which returns a collection of the controls contained in the option group - this includes labels as well as check boxes or radio buttons. The main difficulty in adapting the code I posted to work with an option group, though, is that an option group does not have a KeyDown event. Perhaps it might be possible to use the form's KeyDown event (set the form's KeyPreview property to 'Yes' before trying to use this event) and check the ActiveControl property to determine whether one of the controls in the option group is the active control. I wouldn't do it myself, though - not when the arrow keys already provide the desired behaviour for free. -- Brendan Reynolds "ctdak" wrote in message ... Brendan, Thanks for doing all the work for me. The pieces of the coding puzzle I was missing here were the ".Value" and the ".Pages.Count". This is what I was looking for. It works great. Would you happen to know if the same kind of thing can be done with an option group? In other words, is there a way for the program to know how many option buttons exist (similar to "Pages.Count") and which option button the user is currently on (similar to ".Value"). ctdak "Brendan Reynolds" wrote: Private Sub TabCtl0_KeyDown(KeyCode As Integer, Shift As Integer) Select Case KeyCode Case vbKeyPageDown If Me.TabCtl0.Value Me.TabCtl0.Pages.Count - 1 Then Me.TabCtl0.Value = Me.TabCtl0.Value + 1 Else Me.TabCtl0.Value = 0 End If Case vbKeyPageUp If Me.TabCtl0.Value 0 Then Me.TabCtl0.Value = Me.TabCtl0.Value - 1 Else Me.TabCtl0.Value = Me.TabCtl0.Pages.Count - 1 End If Case Else 'do nothing End Select End Sub -- Brendan Reynolds "ctdak" wrote in message ... I appreciate your responses, but you're missing my point. Let me be more specific. I want to enable the PageDown key to move the user to the next sequential tab (from whichever tab he is currently on), and to enable the PageUp key to move the user to the previous sequential tab (from whichever tab he is currently on). What Bob showed me earlier will only move to one particular tab all the time. So, as I said I need a way to know the user's current tab in order to know which tab to move him to. ctdak "Al Camp" wrote: ctdak, Not true. Either method above will move to the correct tab, no matter where you are on the main form. -- hth Al Camp Candia Computer Consulting - Candia NH http://home.comcast.net/~cccsolutions "ctdak" wrote in message ... Great, this is along the lines of what I was looking for. But the program has to know which tab the user is moving from in order to move the user to the right one (the next one with a PageDown key press for instance). Is there a way to ascertain the user's current tab, perhaps by the tab caption or some other tab property? ctdak " wrote: Code to move to the second tab of a tab control named TabCtl0 (not a very meaningful name). Note that tab controls are zero based, so (1) is the second tab.... Me.TabCtl0.Pages(1).SetFocus Bob |
#13
|
|||
|
|||
Tab Form navigation
Al,
Thanks for explaining what you were thinking. Your rationale might make sense except that I have only one Access application to worry about for my users, so "standardization" is a non-issue for me. Even if it were an issue, I often find inconsistencies with so-called standards in MS applications, and neither are they the best. There is nothing "questionable" in my mind about the convenience of "sequential tab accessing", as you suggested. It is very intuitive for the user, much more so that "Alt-anything". (And all the more so when to the user a multi-tab form looks like a different "record" is associated with each tab.) By the way, if Access standards were truly standard, then in my opinion PageDown and PageUp would move a user between records (report pages) when viewing a report on the screen, instead of moving the view down/up on one page. Maybe the attempt was to make that function like in Word, but then the bottom of the screen looks just like an Access form. So much for standards! ctdak "Al Camp" wrote: ct, I see that Brendan has provided you a good solution... In my first reply, I thought that I had suggested not using the PageUp/Dn keys for functions other than the default function of navigating/moving from record to record. I see that I forgot to do that, and since my solution was really targeted towards using the standard Alt-Something method of accessing tabs at will... without that caveat, my solution appeared to be out of synch with your question... I would still suggest that you not "override" default Access foem key functions. As a productivity issue, there is something to be said for keeping all Access applications "standardized", so that users are always presented the same form maintenance interface from one app to another. I'm just trying to weigh the "de-standardization" of your form navigation against the questionable convenience of "sequential" tab accessing... OK, there's my 2 cents... for what it's worth. - hth Al Camp Candia Computer Consulting - Candia NH http://home.comcast.net/~cccsolutions "ctdak" wrote in message ... I appreciate your responses, but you're missing my point. Let me be more specific. I want to enable the PageDown key to move the user to the next sequential tab (from whichever tab he is currently on), and to enable the PageUp key to move the user to the previous sequential tab (from whichever tab he is currently on). What Bob showed me earlier will only move to one particular tab all the time. So, as I said I need a way to know the user's current tab in order to know which tab to move him to. ctdak "Al Camp" wrote: ctdak, Not true. Either method above will move to the correct tab, no matter where you are on the main form. -- hth Al Camp Candia Computer Consulting - Candia NH http://home.comcast.net/~cccsolutions "ctdak" wrote in message ... Great, this is along the lines of what I was looking for. But the program has to know which tab the user is moving from in order to move the user to the right one (the next one with a PageDown key press for instance). Is there a way to ascertain the user's current tab, perhaps by the tab caption or some other tab property? ctdak " wrote: Code to move to the second tab of a tab control named TabCtl0 (not a very meaningful name). Note that tab controls are zero based, so (1) is the second tab.... Me.TabCtl0.Pages(1).SetFocus Bob |
#14
|
|||
|
|||
Tab Form navigation
Thanks a lot again! This did the trick for me. (It looks like the Controls
collection does not include controls like regular option buttons or aesthetic boxes and labels, etc, that also happen to be within the option group on the form.) ctdak "Brendan Reynolds" wrote: Thanks for the clarification. I don't think I've ever used an option group with more than one column. If I had that many options, I'd go for a combo box or list box rather than an option group, as it takes less screen space. As I mentioned previously, the Controls collection of an option group includes all controls in the option group, including labels. Usually, each button or check box in the option group will have a label, and the option group itself will have a label. Therefore *usually* the number of buttons or checkboxes in the option group will be (NameOfOptionGroup.Controls.Count - 1) \ 2 -- Brendan Reynolds "ctdak" wrote in message ... Brendan, You're not quite right here. The problem is that the arrow keys do not navigate "properly" through an option group if you have two or more columns of buttons, so code IS requirted to fix this. As I found out from discussing this with someone else here recently, "the cursor (down arrow) always goes to the next option whose Top property is = the current option." In other words, if you have two columns of buttons, the down arrow bops around between the two columns instead of going down the first column and then down the second (likewise with the up arrow). I already adapted the code you posted to fix this (I used the form's KeyDown event) and it works great. However, the total number of buttons has to be hard-coded into that routine. I was simply wondering here if the program could find out the number of buttons instead of me hard-coding that value. That way if the number of buttons changes, then the code doesn't have to change. ctdak "Brendan Reynolds" wrote: The arrow keys navigate through the controls in an option group, no code required. An option group does have a Value property, which returns the Value of the selected control within the option group. It also has a Controls property, which returns a collection of the controls contained in the option group - this includes labels as well as check boxes or radio buttons. The main difficulty in adapting the code I posted to work with an option group, though, is that an option group does not have a KeyDown event. Perhaps it might be possible to use the form's KeyDown event (set the form's KeyPreview property to 'Yes' before trying to use this event) and check the ActiveControl property to determine whether one of the controls in the option group is the active control. I wouldn't do it myself, though - not when the arrow keys already provide the desired behaviour for free. -- Brendan Reynolds "ctdak" wrote in message ... Brendan, Thanks for doing all the work for me. The pieces of the coding puzzle I was missing here were the ".Value" and the ".Pages.Count". This is what I was looking for. It works great. Would you happen to know if the same kind of thing can be done with an option group? In other words, is there a way for the program to know how many option buttons exist (similar to "Pages.Count") and which option button the user is currently on (similar to ".Value"). ctdak "Brendan Reynolds" wrote: Private Sub TabCtl0_KeyDown(KeyCode As Integer, Shift As Integer) Select Case KeyCode Case vbKeyPageDown If Me.TabCtl0.Value Me.TabCtl0.Pages.Count - 1 Then Me.TabCtl0.Value = Me.TabCtl0.Value + 1 Else Me.TabCtl0.Value = 0 End If Case vbKeyPageUp If Me.TabCtl0.Value 0 Then Me.TabCtl0.Value = Me.TabCtl0.Value - 1 Else Me.TabCtl0.Value = Me.TabCtl0.Pages.Count - 1 End If Case Else 'do nothing End Select End Sub -- Brendan Reynolds "ctdak" wrote in message ... I appreciate your responses, but you're missing my point. Let me be more specific. I want to enable the PageDown key to move the user to the next sequential tab (from whichever tab he is currently on), and to enable the PageUp key to move the user to the previous sequential tab (from whichever tab he is currently on). What Bob showed me earlier will only move to one particular tab all the time. So, as I said I need a way to know the user's current tab in order to know which tab to move him to. ctdak "Al Camp" wrote: ctdak, Not true. Either method above will move to the correct tab, no matter where you are on the main form. -- hth Al Camp Candia Computer Consulting - Candia NH http://home.comcast.net/~cccsolutions "ctdak" wrote in message ... Great, this is along the lines of what I was looking for. But the program has to know which tab the user is moving from in order to move the user to the right one (the next one with a PageDown key press for instance). Is there a way to ascertain the user's current tab, perhaps by the tab caption or some other tab property? ctdak " wrote: Code to move to the second tab of a tab control named TabCtl0 (not a very meaningful name). Note that tab controls are zero based, so (1) is the second tab.... Me.TabCtl0.Pages(1).SetFocus Bob |
#15
|
|||
|
|||
Tab Form navigation
Option buttons are included if you create the option button directly within
the frame. They are not included if you create them on the form, then drag them into the frame. If you do that accidentally, you can add the control to the option group by selecting the control, cutting it to the clipboard, then selecting the frame and pasting the control back from the clipboard. Labels are included if they are attached to the frame control or one of its child controls, but not if they are unattached or attached to a control that is not a child control of the frame control. -- Brendan Reynolds "ctdak" wrote in message ... Thanks a lot again! This did the trick for me. (It looks like the Controls collection does not include controls like regular option buttons or aesthetic boxes and labels, etc, that also happen to be within the option group on the form.) ctdak "Brendan Reynolds" wrote: Thanks for the clarification. I don't think I've ever used an option group with more than one column. If I had that many options, I'd go for a combo box or list box rather than an option group, as it takes less screen space. As I mentioned previously, the Controls collection of an option group includes all controls in the option group, including labels. Usually, each button or check box in the option group will have a label, and the option group itself will have a label. Therefore *usually* the number of buttons or checkboxes in the option group will be (NameOfOptionGroup.Controls.Count - 1) \ 2 -- Brendan Reynolds "ctdak" wrote in message ... Brendan, You're not quite right here. The problem is that the arrow keys do not navigate "properly" through an option group if you have two or more columns of buttons, so code IS requirted to fix this. As I found out from discussing this with someone else here recently, "the cursor (down arrow) always goes to the next option whose Top property is = the current option." In other words, if you have two columns of buttons, the down arrow bops around between the two columns instead of going down the first column and then down the second (likewise with the up arrow). I already adapted the code you posted to fix this (I used the form's KeyDown event) and it works great. However, the total number of buttons has to be hard-coded into that routine. I was simply wondering here if the program could find out the number of buttons instead of me hard-coding that value. That way if the number of buttons changes, then the code doesn't have to change. ctdak "Brendan Reynolds" wrote: The arrow keys navigate through the controls in an option group, no code required. An option group does have a Value property, which returns the Value of the selected control within the option group. It also has a Controls property, which returns a collection of the controls contained in the option group - this includes labels as well as check boxes or radio buttons. The main difficulty in adapting the code I posted to work with an option group, though, is that an option group does not have a KeyDown event. Perhaps it might be possible to use the form's KeyDown event (set the form's KeyPreview property to 'Yes' before trying to use this event) and check the ActiveControl property to determine whether one of the controls in the option group is the active control. I wouldn't do it myself, though - not when the arrow keys already provide the desired behaviour for free. -- Brendan Reynolds "ctdak" wrote in message ... Brendan, Thanks for doing all the work for me. The pieces of the coding puzzle I was missing here were the ".Value" and the ".Pages.Count". This is what I was looking for. It works great. Would you happen to know if the same kind of thing can be done with an option group? In other words, is there a way for the program to know how many option buttons exist (similar to "Pages.Count") and which option button the user is currently on (similar to ".Value"). ctdak "Brendan Reynolds" wrote: Private Sub TabCtl0_KeyDown(KeyCode As Integer, Shift As Integer) Select Case KeyCode Case vbKeyPageDown If Me.TabCtl0.Value Me.TabCtl0.Pages.Count - 1 Then Me.TabCtl0.Value = Me.TabCtl0.Value + 1 Else Me.TabCtl0.Value = 0 End If Case vbKeyPageUp If Me.TabCtl0.Value 0 Then Me.TabCtl0.Value = Me.TabCtl0.Value - 1 Else Me.TabCtl0.Value = Me.TabCtl0.Pages.Count - 1 End If Case Else 'do nothing End Select End Sub -- Brendan Reynolds "ctdak" wrote in message ... I appreciate your responses, but you're missing my point. Let me be more specific. I want to enable the PageDown key to move the user to the next sequential tab (from whichever tab he is currently on), and to enable the PageUp key to move the user to the previous sequential tab (from whichever tab he is currently on). What Bob showed me earlier will only move to one particular tab all the time. So, as I said I need a way to know the user's current tab in order to know which tab to move him to. ctdak "Al Camp" wrote: ctdak, Not true. Either method above will move to the correct tab, no matter where you are on the main form. -- hth Al Camp Candia Computer Consulting - Candia NH http://home.comcast.net/~cccsolutions "ctdak" wrote in message ... Great, this is along the lines of what I was looking for. But the program has to know which tab the user is moving from in order to move the user to the right one (the next one with a PageDown key press for instance). Is there a way to ascertain the user's current tab, perhaps by the tab caption or some other tab property? ctdak " wrote: Code to move to the second tab of a tab control named TabCtl0 (not a very meaningful name). Note that tab controls are zero based, so (1) is the second tab.... Me.TabCtl0.Pages(1).SetFocus Bob |
#16
|
|||
|
|||
Tab Form navigation
"Standard" Windows navigation in a tabbed dialog box is CTRL-TAB to move one
tab forward and SHIFT-CTRL-TAB to move backwards. This is consistent with keyboard navigation in Access Tab controls. "ctdak" wrote: Al, Thanks for explaining what you were thinking. Your rationale might make sense except that I have only one Access application to worry about for my users, so "standardization" is a non-issue for me. Even if it were an issue, I often find inconsistencies with so-called standards in MS applications, and neither are they the best. There is nothing "questionable" in my mind about the convenience of "sequential tab accessing", as you suggested. It is very intuitive for the user, much more so that "Alt-anything". (And all the more so when to the user a multi-tab form looks like a different "record" is associated with each tab.) By the way, if Access standards were truly standard, then in my opinion PageDown and PageUp would move a user between records (report pages) when viewing a report on the screen, instead of moving the view down/up on one page. Maybe the attempt was to make that function like in Word, but then the bottom of the screen looks just like an Access form. So much for standards! ctdak "Al Camp" wrote: ct, I see that Brendan has provided you a good solution... In my first reply, I thought that I had suggested not using the PageUp/Dn keys for functions other than the default function of navigating/moving from record to record. I see that I forgot to do that, and since my solution was really targeted towards using the standard Alt-Something method of accessing tabs at will... without that caveat, my solution appeared to be out of synch with your question... I would still suggest that you not "override" default Access foem key functions. As a productivity issue, there is something to be said for keeping all Access applications "standardized", so that users are always presented the same form maintenance interface from one app to another. I'm just trying to weigh the "de-standardization" of your form navigation against the questionable convenience of "sequential" tab accessing... OK, there's my 2 cents... for what it's worth. - hth Al Camp Candia Computer Consulting - Candia NH http://home.comcast.net/~cccsolutions "ctdak" wrote in message ... I appreciate your responses, but you're missing my point. Let me be more specific. I want to enable the PageDown key to move the user to the next sequential tab (from whichever tab he is currently on), and to enable the PageUp key to move the user to the previous sequential tab (from whichever tab he is currently on). What Bob showed me earlier will only move to one particular tab all the time. So, as I said I need a way to know the user's current tab in order to know which tab to move him to. ctdak "Al Camp" wrote: ctdak, Not true. Either method above will move to the correct tab, no matter where you are on the main form. -- hth Al Camp Candia Computer Consulting - Candia NH http://home.comcast.net/~cccsolutions "ctdak" wrote in message ... Great, this is along the lines of what I was looking for. But the program has to know which tab the user is moving from in order to move the user to the right one (the next one with a PageDown key press for instance). Is there a way to ascertain the user's current tab, perhaps by the tab caption or some other tab property? ctdak " wrote: Code to move to the second tab of a tab control named TabCtl0 (not a very meaningful name). Note that tab controls are zero based, so (1) is the second tab.... Me.TabCtl0.Pages(1).SetFocus Bob |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
ECHO Causing Problems | DS | General Discussion | 5 | May 17th, 2005 02:19 AM |
Need Help In Printing Current Record in Specific Report | RNUSZ@OKDPS | Setting Up & Running Reports | 1 | May 16th, 2005 09:06 PM |
Need to clear controls of Filter form | Jan Il | Using Forms | 2 | November 28th, 2004 02:04 PM |
open a form through a subform in access 2000 | Tammy | Setting Up & Running Reports | 12 | October 22nd, 2004 02:43 PM |
auto entry into second table after update | Tony | New Users | 13 | July 9th, 2004 10:42 PM |