Date: 4/1/2005
| There has been a couple of peculiar bugs in Scribe for so long now I can't remember when they were first reported (guessing: 2000-2001?). And of course every 3 months or so someone, frothing at the mouth, tells me breathlessly that "there is a bug in Scribe!". And my standard response basically boiled down to:
"So? You'll live."
Because I'd spent several weeks in engineering hours trying to fix it and well, just got no where fast.
Then some, ok many, years later I was bored and for some reason started thinking about the bugs again and dusted off the debugger and had another look at it. Well basically the first bug was sometimes when you move the mouse over a Lgi window that was behind the active top level window it would pop to the top of the z-order but not take focus. The user would be mousing around, not clicking on anything and bam, the z-order changes. Another similar issue that people love to tell me about is after compacting the folders in Scribe the main window pushed itself to the back of the z-order for no apparent reason.
These things in of themselves are annoying but not showstoppers. People learn to work around them and just get on with life (a useful skill btw). And I even stopped noticing they happened at all.
Until today.
So I decided, that maybe the bug had something to do with the mouse move message handler. Makes sense right? The mouse is moving across the window and then it happens. Well sure enough, after commenting out the WM_MOUSEMOVE handler the bug stops happening. But of course the app isn't very useful anymore. So I start the standard procedure of slowly commenting out less and less of the code until the bug reappears. But the problem with that was there was no garrenteed way of making the bug happen. But by repeating the best known method, move the mouse quickly over the title bars of several Lgi windows, many times I could build up a statistical likely hood of the bug being present in the currently running code.
After a little while I isolated the call to the current windows OnMouseEnter function. Hmmmm... what could be in that to cause the z-order change? Well I did a code base wide search of all the implementations of OnMouseEnter and the GToolBar.cpp file had 2 implementations. One for the button and one for the toolbar itself. I commented out GToolButton::OnMouseEnter... still happens. What about GToolBar::OnMouseEnter?
No bug.
Yes! Nice one. Ok, so what was the code? 3 lines that create the toolbar's tooltips. Open up the tooltip code. Hmmm, I wonder what would happen if I changed some of the flags on the tooltip's CreateWindow? Bug still happens. Oh!?! The tooltip window is parented to the toolbar... maybe... thats it? Change the tooltip parent to NULL. (Good 'ol Windows being a pain again)
No bug: Good.
Tooltips still work: Good.
Compact doesn't push window to the back of the z-order: Very Good.
w00t! Back away from the code slowly... don't touch a thing! ;) Now I'll run that for a week or so and if nothing nasty starts happening and the bug doesn't show up again then I'll release test3. Sans the oldest bug in Scribe.
Oh btw Happy New Year!
|
