[SVN] r9285

[Allan Odgaard]

On 3 Apr 2008, at 23:48, Hans-Jörg Bibiko wrote:

> On 03.04.2008, at 23:21, Ciarán Walsh wrote:
>> On 3 Apr 2008, at 19:00, Joachim Mårtensson wrote:
>>
>>> Fixed hang when using the mouse wheel, thanks to Hans for  
>>> providing the fix
>> What hang was this causing? I’ve certainly never had a hang with  
>> this, and I changed it to use -deviceDeltaY because -deltaY works  
>> very intermittently and causes odd behaviour when scrolling using  
>> my MacBook Pro’s touchpad (I have not tried it with a scrollwheel).
>>
> Do you are running Leopard? On Tiger the popup window remain while  
> you can use TM as usual, and you cannot close it.
>
> I do not know '-deviceDeltaY'.

Some info here: http://lists.apple.com/archives/carbon-dev/2005/Nov/msg01070.html

Note they talk of a “Tiger linked app”, so maybe this behavior is  
different depending on whether or not Dialog 2 gets compiled on Tiger  
or Leopard. Did the problem start after you recompiled Dialog 2 with  
Leopard as minimum target?

This btw underlines the importance of:

  • linking (in the source) to info when using undocumented  
functionality!!!
  • writing useful commit messages. That is; write WHY you are making  
a change, not just that you are making it (something I find myself  
repeating a lot). And when the reason is a fix for something, include  
enough information to actually reproduce the problem.

We have (going from deltaY → (undocumented) deviceDeltaY):

     r8510 | ciaran | 2007-11-24 00:54:23 +0100 (Sat, 24 Nov 2007) | 2  
lines
     (Extended PopUp) Much smoother scrolling when using the mouse wheel

And then (going back to deltaY):

     r9285 | joachimm | 2008-04-03 20:00:22 +0200 (Thu, 03 Apr 2008) |  
1 line
     Fixed hang when using the mouse wheel, thanks to Hans for  
providing the fix

So PLEASE work on your commit messages guys! These allow you to write  
a small essay about all the thoughts that went through your head when  
you did the change, have it tied to the lines changed, and still not  
clutter the source when casually browsing it — and when you have to  
write down this in the commit log, it also has a tendency to improve  
the commit quality, since having to “argue” for why you make a  
change, might lead to the realization that it could be done better /  
is not the ideal way to solve the problem.