- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
So this is a technical (non-)solution to a human training issue? (AKA add code solely because someone wants you to deal with a Recalcitrant Idiot User.)
I mean, yes, the code is a moderate WTF by itself, but the fact and reason that it exists are the real WTF today.
Admin
"What is this rectangle that lights up to begin with?" asked another user, and all the programmers were summarily fired.
Rows of typewriters soon started being manned by dozens of clerks, writing all the reports one letter at a time.
Admin
They should have just deleted the data that did not fit the window
Admin
While consulting for a Fortune 5 PetroChem company on network issues, I sniffed out an Access app that shipped a copy of it's entire database to all other registered users of the app EVERY TIME A RECORD WAS SAVED. About 40 users across 20 sites were taking all available bandwidth after this thing had been in operation for a few weeks (star network, anyone?) Killing it took a board level mandate, after which network utilization dropped back to 30%.
Admin
Hm, don't check Altus Vario… (BTW: It works fine ;) )
Admin
TRWTF being that they didn't investigate or know about the user form's properties to disable the window content scrolling if it's so undesired. 😒 If one window behaves differently, compared to another, wouldn't the first approach be comparing the properties of both?
VBA may appear limited and unprofessional, but most of that is from all the abuse, which is a consequence of people's underestimation of the complexity of things, and overestimation of their own capabilities. Or just desparation because nobody else is there for the task(s) at hand, and somebody just has to do it. This used to drive a lot of non-developer employees into their first steps with VBA macros. The macro recorder feature supports learning, although most of the time it's not actually useful, still helps to get the job done. I suspect that approach is the prime reason for the miserable quality we usually face after pushing Alt-F11. You can create professional solutions though if you know what you are doing. Apart from this WTF being a totally wrong approach, imho the code is still legit. You want to intercept and suppress some keys, the list of which is not fully known yet and might need to be extended later. A CASE statement in the KeyDown event handler is the easiest way to do that, and better readable than the alternative which would be an IF statement having a huge chain of OR-combined comparisons. CASE is extended easily by adding more lines for keys to be suppressed, so why not. This could have been achieved without a GOTO, however, it is possible that we don't see the entire code in this example. The final part of the method may contain some cleanup code that should be executed in any case, so it's better to give it a label and use that to jump to this point instead of using EXIT SUB to leave the method instantly without cleaning up. I mean, even C# supports labels and GoTo statements. It's considered kid stuff, but actually makes things so much easier for developers as well as readers - if applied correctly!
Admin
Indeed. To paraphrase Dijkstra "Bad developers considered harmful."
Admin
Even mainframe apps could scroll if they were designed to. Conventionally the PF7 and PF8 keys were used for page up and page down.
Admin
Mainframe dialog systems (here considered: 3270-based) actually were able to scroll, and they did, typically (almost) one screen-height at a time. That is what the "Page Up" and "Page Down" keys (or PF9 and PF10 in most cases) - on the keyboard! - were intended for; it was written on them, and it was written on the screen (top and bottom of data area to indicate if there was more content above or below, and lower information area which keys could be used). This was often required to work with forms on display systems that only had 80x24 for presenting content, usually in editors or extensive forms. Later, extended screen sizes like 80x43, 132x27, and 160x62 became available. That is characters, not pixels, of course.
However, badly written programs could omit those decades-old features and spoon-feed dialog elements to the user, instead of using the comfortable and efficient means of using multi-screen forms. But solely coming from a mainframe environment is no excuse for being stupid. Doing stupid things in "Microsoft Office" is not a fault of the mainframe world.
Admin
A non-programmer created an Access-driven application for a company I once worked for. Most of the fields were type Text, and they used the default size Access provided (255). Apparently this is fixed, not variable, and so the table became very large...