"She just did it again!"
"What?! How'd she do it?"
"I have no idea!"
This is roughly how a conversation went between a team lead and one of the other developers. They were on a screen share/call with a client who was somehow breaking their software. Not a bad break, but broken nonetheless. When things don't behave the way that the developer or the client expects, it's broken.
The application in question was an older Windows Form application, written in .Net. The user was entering data on one of the main forms, and one of the drop down list boxes wasn't getting populated as it should have.
"Let me try that!" said the team lead. He took control of the client's machine, and was able click on the drop down list box, and it populated properly, as everyone would have expected. The client then took the controls and broke it again. It failed to populate its drop down options.
There had to be some explanation. At least in .Net, drop down list boxes don't have vindictive behaviour depending on what user is using them. Or clicking on them. Or alt-tabbing into them.
That was the key.
The user wasn't clicking into the drop down list box. She was hitting the tab key to switch between various inputs on the form. It took a few minutes to sort it out, but was eventually discovered. The drop down list box control was listening to the on_click event. It would only respond when it was clicked on. If the control was activated in any other way, like being entered into via tabbing from another control, the on_click event handler
wouldn't fire.
Moral of the story:
- It's broken if it doesn't behave like the people using it think it should behave.
- Listen to the right event.
Top comments (0)