A common programming mistake is to hard-code literals that corresponds to some property. That is particularly true with certain controls like tab controls & pages. The tab control exposes a Value property that indicates the current tab and the pages contains a PageIndex property that indicates its position in the tabs of the control.
Thus, it’s common to see code like this:
|
1 2 3 4 5 6 7 8 9 |
Private Sub myTabControl_Change() Select Case Me.myTabControl.Value Case 0 'Widgets 'Do stuff with the 1st tab Case 1 'Thingamigjig 'Do stuff with the 2nd tab Case 2 'Gobbledgock 'Do stuff with the 3rd tab End Sub |
This means that if the tab control changes (e.g. new page inserted in middle or is rearranged), we will end up with code running incorrectly. To avoid this extra maintenance, we can do this instead:
|
1 2 3 4 5 6 7 8 9 |
Private Sub myTabControl_Change() Select Case Me.myTabControl.Value Case Me.pagWidget.PageIndex 'Do stuff with the widget tab Case Me.pagThingamigjig.PageIndex 'Do stuff with the thingamigjig tab Case Me.pagGobbledgock.PageIndex 'Do stuff with the gobbledgock tab End Sub |
This enables us to have code that will always work even if we later re-arrange tabs or insert new tabs in middle without breaking the functionality we want for other tabs. More importantly, if we delete a tab, this will cause a compile time error to remind us to clean up the Case that no longer applies for the deleted tab. That happens because we reference the Me.pagXXXX page control.