So a bug report came in last night that pertains to the default button never being set properly when using tab panels. That sounded an awful lot like a bug I fixed with regards to default buttons not getting set properly when displaying a new window for the first time. So I started checking into it (about 8pm).
I took the user's sample project and was able to demonstrate the bug exists with a TabPanel. Great. For giggles, I changed the super over to be a PagePanel. I had a hunch the problem was there as well since the two controls share a lot of code. Yup, problem is there. Bug #1.
So I solved that issue (we needed to recheck for the new default button whenever the tab or page changed). In the process of solving that issue, I stumbled on a new bug. When you change the visibility of a control, it's default value doesn't get updated. So if I had a default button that was invisible, and I toggled it to being visible, it wouldn't become the default button. Bug #2.
Well, as you hopefully know, on Windows, the default button is either 1) the button which currently has focus, or 2) if no button has focus, the button you marked as default. So in order to test the button visibility fix, I tossed a CheckBox onto a window and said PushButton1.Visible = me.Value in its Action event. I figured I could toggle the visibility and make sure that the default pane was being marked properly. But I noticed that my fix wasn't working for some reason. Which was strange, because I could have sworn it was an easy fix. So I started stepping thru the code in the debugger, and I stumbled upon the issue -- the code was like this:
if ((controlStyle & BS_PUSHBUTTON) == BS_PUSHBUTTON) {
That's pretty normal bitflag testing code -- but the problem was, the controlStyle I was checking was for the checkbox, not a push button! So a little header diving, and I learned that the control styles for buttons are *not* masks, they're part mask and part ids. You tell a button that it's a pushbutton, checkbox, radiobutton, etc, which is in the low-order nibble of the style. The rest of the style is mask data. Arg! Bug #3. So I mask off the low-order nibble and changed the test to this:
if ((controlStyle & BS_TYPEMASK) == BS_PUSHBUTTON) {
and now my default button visibility toggling issue was solved, yay! Except, I happened to notice a different problem now. I noticed that when I hit the keyboard mnemonic for the checkbox, it wasn't changing the focus to the checkbox. So I popped open VB6 and VC++ and grabbed my interface guidelines book. Oops, Bug #4. So that was easy enough to fix -- when the mnemonic is fired, the focus is now set properly.
Phew, I think that's enough bug fixing for one night. I managed to solve 4 bugs coming from a single project. While it's certainly a nice feeling to get all those fixed in such short order (especially since I think they're fairly large bugs), it sure sucks to run into that many bugs that quickly. It's both a nice feeling, and a humbling one at the same time.
Oh, and in case you're wondering, I finished fixing the bugs about 9:15pm
Will will be happy.
Actually, Will's bug was fixed a few weeks ago. His was with default buttons not being picked properly when you displayed a new window.
That's called "Yak shaving". I tend to do that at least once a week ;-)
Yeah! Bug #2 sounds exactly like the bug I was talking about in the comments to the post about the default button on Rb Gazette. So it sounds like it's fixed all around. Thanks.
Woops. Should have read the comments before posting :) Yes, the bulk of the problems I was seeing no doubt the bug Aaron fixed a few weeks ago. But I have one one project with a default button that fits bug #2's description exactly.
4 bugs squished in an hour and 15 minutes.... GOOD JOB! :)