Putting a full-featured IDE on every user's desktop and providing them basically no guidance on how to use it would, in most circles, be considered a mistake. That mistake is also known as "Microsoft Office", which continues to haunt us.
Now, much of the macro-based application development in Office applications is written by non-programmers. But there's still a disturbing amount of code written by people who should know better, and thus you end up with mission-critical applications written in Microsoft Access.
Douglas inherited one such database. At some point, one of their end users got confused- this user was used to mainframe-based applications which present screenfuls of data and don't have scrolling. So, when presented with a window that could scroll, they were flummoxed. Why did the data they were looking at go away? Disabling scrollbars only got them so far, as the page-up/page-down keys still worked, so the obvious fix was to disable those keystrokes as well.
Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
Select Case KeyCode
Case vbKeyPageUp
Case vbKeyPageDown
Case Else
GoTo Exit_Form_KeyDown
End Select
KeyCode = 0
Exit_Form_KeyDown:
End Sub
This creates a global event handler on the form. The goal of this handler is to check the pressed key: if it's page-up/page-down, alter the reported KeyCode
to 0. For any other key, allow it to pass unchanged.
But the logic of it is a delightfully inverted approach. In our Select
(switch
) statement, we do nothing if it's our target key. But if it's a "valid" key, we jump via GoTo
to skip over the important line of code: KeyCode = 0
.
This block is just a small symptom of the overall design- the logic is impenetrable, the design is incomprehensible, and at every turn, given the choice between doing things the easy way or the hard way, the developers chose the hard way.
Which, I guess, is implied by the fact that they built this using Access.