A customer reported that under certain conditions,
their custom-drawn trackbar does not generate a
NM_
message.
We have found that the trackbar control in the shell common controls library does not generate a
NM_
message when the position changes from 1 to 0 and the trackbar's range is sufficiently high.CUSTOMDRAW We start with the trackbar position at 1.
−1000 +1000 ![]()
| | | Current value: 1 And then we send the
TBM_
message to set the trackbar position to zero. The result is this:SETPOS
−1000 +1000 ![]()
| | | Current value: 1 Observe that the "Current value" is reported as 1, even though we changed the value to 0. On the other hand, if we start with the position at −1:
−1000 +1000 ![]()
| | | Current value: −1 then when we send the
TBM_
message to change the position to zero, we do get aSETPOS NM_
message, and the "Current value" updates.CUSTOMDRAW
−1000 +1000 ![]()
| | | Current value: 0 We have been able to reproduce this problem on every version of the trackbar as far back as we tested.
Everything is working as it should.
The
NM_
notification lets you customize how the common
control draws itself.
If there is nothing that needs to be redrawn,
then there is no WM_
message and consequently no
NM_
notification.
When the trackbar range is large, then multiple positions have the same visual appearance. This is a natural consequence of the pigeonhole principle: There are 500 (say) pixel positions that the thumb could be drawn, but there are 2001 possible positions, so around four thumb positions all correspond to the same visual appearance.
What appears to be happening is that positions 0 and 1 share
the same visual appearance,
so when the thumb position changes between 0 and 1,
there is no visual change and therefore no
NM_
message.
On the other hand, it appears that positions −1
and 0 have different visual apperances,
which is why you get a
NM_
message
when the position changes from −1 to 0.
It sounds like the application is using the
NM_CUSTOMDRAW
notification to detect
when the trackbar position has changed.
That's not what it's for.
The
NM_CUSTOMDRAW
notification
is for letting you customize the way the trackbar is drawn.
If you want to know when the trackbar position changes,
listen for the
WM_
message.
Note, however, that
the WM_
message
is not generated if the program itself changes the
position via the
TBM_
message,
on the theory that since the program itself changed
the value,
it can update its own state right there.
No need to tell the program what it already knows.
Bonus chatter: Not generating a notification for program-generated position changes also helps avoid infinite loops. After the program changes the trackbar position, it receives the change notification, and in response to the notification, the program tries to update some state. But the state update fails, so the program tries to undo the change and set the position back. This reset generates its own change notification, and the program responds to the notification by trying to update that same state (to the old value), which still fails, so the program tries to undo the change and set the position back, which generates yet another change notification, and so on.
The theory here is that the code that is listening for
the WM_
or
WM_
message is also the code
that is sending the
TBM_
message,
so there's no point in telling the program something
it already knows.
Exercise: Suppose you have a trackbar,
and you want to let anybody send it a
TBM_
message to change
the trackbar position,
but you also want to be notified when that happens.
How would you do that?