I found a bug ... in the Win32 API (trackbar style TBS_DOWNISLEFT)

[NoCforMe]

Imagine that, something wrong in Windoze; who woulda thunk it? But really, I did find a small but annoying problem that apparently is a bug in the code for trackbar controls. Actually, it seems to be an unimplemented flag bit. When setting styles for a trackbar control, one of the choices is TBS_DOWNISLEFT. According to MSDN,

By default, the trackbar control uses down equal to right and up equal to left. Use the TBS_DOWNISLEFT style to reverse the default, making down equal left and up equal right.

Which is just what I wanted, since I have a vertical trackbar and I wanted it to increase in the upward direction instead of the opposite (default) behavior. Fine: I created the control with this style. It didn't do squat. I thought I was doing something wrong until I came across this page on the web, as well as others, explaining that this was Micro$oft's fault. Dang.

Fortunately, it's an easy fix. I simply reversed the range of the variable I was controlling with the trackbar by doing this:

Code Select Expand


NEG EAX
ADD EAX, $maxTBvolume

with the value I wanted to adjust in EAX, and $maxTBvolume the maximum value of the variable.

Just posting this as a heads-up.

[dedndave]

a common issue - i think they fixed it for vista or win 7

[NoCforMe]

Anyone with 7 want to test this? Didn't see anything on the web about it being fixed.

[dedndave]

maybe i'm thinking of TBS_REVERSED
been a while since i played with it

[NoCforMe]

TBS_REVERSED does nothing, and MSDN says so:

Version 5.80: This style bit is used for "reversed" trackbars, where a smaller number indicates "higher" and a larger number indicates "lower." It has no effect on the control; it is simply a label that can be checked to determine whether a trackbar is normal or reversed.

[NoCforMe]

OK, here's another bug. The following works OK:

Code Select Expand


$ampTbarScaleValue EQU 20000
$ampTbarRange EQU $ampTbarScaleValue SHL 16

INVOKE SendMessage, tbarHandle, TBM_SETRANGE, FALSE, $ampTbarRange


but  change the upper end of the range to 50,000 and it fails.

I couldn't figure out why my trackbars weren't working, so I did some snooping around, found that with the upper end @ 50,000, the range was actually getting set to 4,294,951,760. WTF?!?!? But hey, that's 0FFFFC350 in hex, and 50,000 is 0C350, so what's apparently happening is that Windoze is treating the value as signed. Now, MSDN ain't exactly crystal clear about this, but they do say in the description of the TBM_SETRANGE message that "Because this message takes two 16-bit unsigned integer values, the maximum range that this message can specify is from 0 to 65,535". Except that it's not.

The fix is trivially easy:

Code Select Expand


INVOKE SendMessage, tbarHandle, TBM_SETRANGEMIN, FALSE, 0
INVOKE SendMessage, tbarHandle, TBM_SETRANGEMAX, FALSE, $ampTbarScaleValue


This does work as advertised.

[dedndave]

i seem to recall one of the basic info pages explains that stuff

https://msdn.microsoft.com/en-us/library/windows/desktop/bb760145%28v=vs.85%29.aspx

a similar case for scroll bars

https://msdn.microsoft.com/en-us/library/windows/desktop/bb787529%28v=vs.85%29.aspx

but - i rarely assign so many steps to a control bar
no need to exceed the resolution of displayed pixels, really
i.e., if the track bar is 200 pixels long, 32767 steps is about 32500 too many   

[NoCforMe]

I need that many steps because I'm converting the trackbar value to a decimal value between 0 and 1, with a desired resolution of at least 6 decimal places. (I'm playing with sine-wave harmonics here.) I know I'm not actually getting that resolution (because of the physical pixel limitation as you pointed out), but it makes it easy to convert to the numbers I'm working with.

[dedndave]

well - ok
but, as you work through that code,
you'll see that having more resolution on the input doesn't generate more on the output
if you have 3 or 4 times the pixel width of the movable bar, you'll have all you can possibly make use of
take the position and scale it with integer math, as desired - then convert it to a float

[hutch--]

Its not uncommon to find a 32/64k limit in controls. Just for example a post Win2k listbox will accept a million items but the scrolling becomes dodgy after 64k.