- 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
Hah! That way, when people complain due to poor application response, he can decrease the timer event delay and collect a bonus for "performance enhancements"!
Brillant!
Admin
Wow! this is a true WTF! I wonder if the original author(s) of this super advanced Paybck application were trying to "outsmart" MS VB6 events or they just didn't know any better?
Admin
It can be worst than the shit I usually found in my current job old code. GUI Forms where the user must click the buttons in a rather obscure order to get things working. If (s)he clicks in the wrong order, heavy shit may happen. I'm going to send you some snippets of this crap as soon as I figure out which one is WORST...
Admin
Event....Whats an Event?????
Admin
I would hate to have to be on the one who has to use that.
Admin
OMG, every three seconds? i hope you're exaggerating!
Can't believe someone could make a program and not know what an event is, its impossible?
Admin
Dude, that code smells like my ass!
This is probably one the funniest things I've ever seen on here Alex! Thank you for making my day.
Admin
This is a system for those of us who are nostalgic for the good old days of the C-64, when most operations of moderate complexity required a 30-second wait. If only he could work ", 8, 1" into the interface somehow.
Admin
Even worse, they apparently understand events (the timer), just not the concept that a user can generate them.
Admin
You mean you didn't wipe or wash it in a year?
Admin
Come on - it's not a bug, it's a feature. If it weren't for the up to 3s delay, how would you be able to trigger an illegal action? You just couldn't!
Admin
I'm pretty sure this programmer knew what events are... after all, he/she wrote one! I strongly suspect it was a case of, "hey, I've got to put this validation in the events for lstCourses, lstCourseTypes, txtCourseType, etc... but damn, I don't want to repeat the same block of code everywhere. What do I do? I know, I'll put it all in a timer event!" And not realizing that you can actually, you know, create your own functions inside of a form, and you don't have to rely on double-clicking on a control in the designer.
And you have to love using Hungarian notation for controls (tspCourseInfo? WTF is a 'tsp'?) but not for the variables.
And that stupid default VB6 icon on the window. They might as well just put "Crapware" in the title bar.
Of course, with the advent of the web, users now expect there to be a slight delay after they click on something. Maybe they would get confused if stuff happened instantly. Maybe this is a very forward-looking approach, after all!
Admin
There is a mandatory 3-second waiting period on potentially stupid database interactions.
Admin
I am not a VB person, but does an event fire is something else comes and changes the state programmatically. What if another section of the program was changing lstCourseTypes.Enabled or lstCourses.Enabled - say when a network resource giving this data went down. Sure, a sane person would put this code into its own routine and then whoever programmatically changed something on GUI could simply call UpdateControls to make sure their changes were reflected in the control logic.
This could even be a defensive move because the bozo in the next cube (who is also the boss' son) will not make a change in his code that does the change and insists that you change because his code is properly designed.
Or it could be that the coder is simply clueless.
Admin
This is the sort of code that demonstrates why every developer ought to be instructed in state machines.
Admin
I can't see any reason to use a timer in this fashion...Even if you needed things to happen in 3 second increments, it would be far far better to handle that in the backend code rather than make users work with a half-assed cyclical system.
I can't imagine a scenario where you'd want a user interface to have any sort of functionality dependant on a timer...The user should always be able to do their user things...If you have some crazy transaction journaling system in the background that fires every 66789 seconds or something, they don't need to know about it. The whole point of an interface is to hide that crap from them, so their tiny minds don't asplode.
Admin
I've seen code that does just this without the big delay, that is, setting control state from a central routine when the application is idle (like here for example). The programmer in this case probably saw something like this, thought, "Keen! I gotta do it like that!" and couldn't figure out any other way in VB. It's been too long since I've done VB, so I don't remember if it has something akin to Application.Idle or not.
Admin
Event handlers, anyone? Anyone? ANYONE????
....
....
....
</dead_silence>
Admin
This is offtopic, but Oliver Klozoff and I have finally finished battling a problem with a C++ component written at my company that warranted a new design antipattern article (I added it to wikipedia)
http://en.wikipedia.org/wiki/Object_cesspool
Admin
You all's guess is as good as mine on this one. I've looked through the other forms in this application and they all use a more sane method of deciding which controls are visible/enabled under which circumstances. My guess is the original developer just though this'd be neat.
Admin
GalacticCmdr: The event fires no matter what triggered it. If something changes the value in the field, then the _Change() event kicks off.
And I know someone else beat me to this, but I totally believe the reason this was done is that they didn't want to repeat the validation code in every text box. If only VB would let you write your OWN functions...
PS- tsp = tablespoon. In this case though, I think it means "tabstrip", which is the name of the control with all the tabs on it that affects which screen you're looking at.
Admin
You know, this whole thing can be cured with a few easy steps, and by downloading the free cygwin unix tools from the web.
Steps to fix the problem:
Problem solved! Now, wasn't that easy?
Admin
That's nice. They give the user 3 seconds to change their mind if they click the wrong item.
Very thoughtful.
Hey Alex: I picked up a copy of your book. Pretty cool!
Admin
One small correction to the original post. The timer event fires 3 times every second, not 1 time every 3 seconds. This means that users probably aren't going to notice having to wait a few seconds for things on the form to change, but it's silly nonetheless
To point out another problem, notice the cases in which SelectedItem is set to true. It is only set to true if the correct listbox's ListIndex is greater than 0. This means that several controls that should be enabled/disabled when the user selects an item in the listbox aren't changed when the user selects the first item in the list. And yes, the first item in each list is a valid item that the users should be able to update.
Admin
Maybe the programmer wanted to program to behave like an AJAX application.
Admin
Not really certain, but I think there are 3 of them in a tbsCourseInfo
Admin
David Markle: That's way too many steps. The original programmer should just pull out the hard drive and beat it with a hammer. Then use the hammer on his own fingers to assure he will never ever write code again.
And I hadn't noticed the ListIndex > 0 part. The first item in the list truly will not enable any of the controls. Maybe this guy put something like "==Select from this list==" as the first ListItem, because he didn't know how to handle an empty ListBox. Or maybe he just doesn't know that the index is 0-based. A lot of things in VB aren't, but some things are. It's just Microsoft's way of keeping you on your toes.
Admin
bash: CD: command not found
By the way, parameterless "cd" in bash changes the working directory to ~, not /
</payback>
Admin
One of the little utilities at my first job involved a phony 4-second progress bar when activating/deactivating it, to go along with the user's perspective that we were patching functionality in pretty much every program in the system. (Actually, we were only adding/removing a single program in front of another single program.) And yes, we eventually "improved performance" by removing the delay.
Admin
Did someone drop it?
Admin
tsp = teaspoon
tbsp = tablespoon
maybe Alex meant "tps"?
Admin
This is exactly why everything I cook ends up tasking like tree bark. You damn Brits and your metric system, I'll never get used to it.
Admin
Ya know, if you simply call ControlTimer_Timer from every event that actually should update the UI state, this would work pretty well... I've seen more bizarrely coded "ManageUIState()" type procs before.
And you can burn bonus cycles three times a second just in case you screw up!
Extra bonus reliability points if you can make it take a half second to process each event!
Admin
At least they use source code control.
Admin
I wrote a monitoring program for dealing with Windows services across a network. The listbox was updated every so often as services came on-line or were no longer available. The user could select a service and start or stop it. The "blink" when the list was updated was a bit of a bother, but this was a very low use app.
Sincerely,
Gene Wirchenko
Admin
huh? I don't...oh wait...I got it!
It's like to "pick up" can have 2 different meanings! Or maybe I met the book at a bar and had sex with it! That's 3 meanings!
Oh, that's rich.
Admin
Well, let's see, at step 8, if you run cmd.exe, then proceed to step 9 you will do nothing more than leave yourself in the directory you were in anyway ("CD" == "echo the directory I'm currently in"). Since the default is to put you into %USER_PROFILE% when you initially fire off the dos prompt, when you perform step 10 (assuming the cygwin "rm" command is able to be found from the cmd prompt, which iirc it isn't in a default install of cygwin unless someone alters their environment variables manually) you've just succeeded in removing most or all of your windows profile, including "my documents" etc. However, the OS is fine with that, and will simply go merrily along laughing at you (they're all gonna laugh at you ... )
If at step 8 you run cygwin, CD doesn't work, leaving you in the default directory (which is ~ under the cygwin install directory) and rm will remove the contents of your cygwin home directory, which is even less of a bother to the OS than going the other route...
Oh, wait. it was a joke ...
</payback>
Admin
Heh -- actually, I was a contributor to it. Although I encourage you to buy the book, O'Reilley has the Hack I wrote avaiable as a sample: http://www.oreilly.com/catalog/visualstudiohks/ (see Hack#7).
Admin
Actually, I have had to resort to this method when using controls which lacked the needed events (which is a WTF in itself, but not mine), but then I set it to check five times a second or so, often enough to not be percieved as slow.
I have not done it often and only as a last resort, and I am not proud of it, but sometimes you just have to go with whatever works.
Actually a very common VB practice, with a very practical reason. Variables are defined in the same method, close to where you are working. There may be an occasional variable with a larger scope, but these are few and easily remembered (unless you are doing something very wrong).
Controls, however, are often not defined in the viewable code. In fact, you have to go to the property window to get a closer look at them. In this case, it makes sense to be a bit more clear about it. It also makes it easy to keep track of GUI components when quickly looking through the code. Most GUI parts is usually along the lines of either
control data=data from dataset/object
or
dataset/object data=control data
usually coupled with some validation code and some occasional derived values. Being able to quickly sort out what's part of the GUI makes a lot of sense in these cases.
Actually, most likely the form has probably removed the icon (since it has a close button), but VB still displays it in design mode, where this screenshot is taken. It doesn't make sense to make the executable bigger because of an icon that is never shown.
Admin
He could improve the efficiency of the timer routine by having it check a flag to see if anything has changed. If the flag isn't set the routine just exits. Otherwise, it does its thing and then unsets the flag.
Then, he just needs to make sure the flag is set whenever something changes.
Yes, I'm kidding (we're always kidding!). But doesn't this seem like the next step this person would take on the road (hopefully) to the correct solution?
Admin
amazing if i say sdo myself keep it up i mean wow im a hacker and have been for 3 years but i have never seen anything like that its amazing welldone
Admin
+1 to that.
-dave-
Admin
The URL in the PDF file doesn't work [:'(] I get a directory listing denied error.. Did you forget to tell IIS what your index document is?
Drak
Admin
Brits and metric system?
stop creating wtfs
Admin
i wouldn't difamate my ass like that...
Admin
No comment on the body of code, but conceptualy I think the developer was aiming at an independant state machine. Not a bad idea at all - no need to trap the events of every possible user input, and more easily extensible. Perhaps the developer should be directed towards something like an ApplicationOnIdle event.
Admin
If VB didn't suck rocks for event driven programming code like this wouldn't be needed. Updating the GUI consistently from a timer is better than the absolutely mess you end up with when you have mutually dependant widgets..
The root cause is that OnChange should be called only when the user changes it. If I change it with code don't tell me it changed; I know it changed, I just changed it.
For a demostrative example, try implementing Windows' Calc with VB (or any other modern widget kit other than MFC; despite all the criticism this is straight-forward in MFC because GUI updates are made atomic via UpdateData).
Admin
Trust me, this isn't needed and it is not better than using typical event driven programming in VB. This is wonky, overly complex for what the situation needs, and allows a chance, albeit ever so slight, for the user to use controls when they should be disabled.
Admin
Well actually he IS handling an event: ControlTimer_Timer() ...
Admin
Good point, and VB's not the only language with this problem.
Edit1.OnChange := nil;
try
....
finally
Edit1.OnChange := Edit1Change;
end;
is a common delphi situation. An OnGUIChange event could be useful, but more often than not you want your state to always reflect the current GUI situation regardles of where the change was made. So, i would still go with an independant state machine.