Am I correct in assuming that Borland's TUpDown cotrol is limited to a 16-bit range?
James O'Brien
The Min, Max, and Position properties of the TUpDown control are defined as
"short", yet the Increment property is defined as "int".
What gives? Microsoft had 32-bit support for UpDown control since IE 4.0
(comctl32.dll version 4.71).
The ranges I need to work with are potentially in the millions. Anybody run
into this problem? Anybody have a fix or work-around?
I suppose I could always just use the TScrollBar control, but it doesn't
quite look right. Plus I'd have to write gobs of code to know when user has
stopped pressing the scroll bar buttons, since TScrollBar doesn't have an
event handler for OnMouseUp event.
James O'Brien
Remy Lebeau (TeamB)
"James O'Brien" <obr...@niscnet.com> wrote in message
news:42fbbdee$1...@newsgroups.borland.com...
> The Min, Max, and Position properties of the TUpDown control
> are defined as "short", yet the Increment property is defined as "int".
Correct.
> What gives? Microsoft had 32-bit support for UpDown
> control since IE 4.0 (comctl32.dll version 4.71).
To emable 32-bit support, Borland would have to re-write TUpDown to use the
newer 32-bit UDM_SETRANGE32 and UDM_SETPOS32 messages. The Min, Max, and
Position properties currently still use the 16-bit UDM_SETRANGE and
UDM_SETPOS messages instead.
The Increment property, on the other hand, uses the UDM_SETACCEL message,
which has always allowed a 32-bit value.
> The ranges I need to work with are potentially in the millions. Anybody
> run into this problem? Anybody have a fix or work-around?
You will have to work with the newer 32-bit messages manually.
Gambit
James O'Brien
strictly a number, so I plan to update the edit box myself.
I've done some additional reading of MSD documentation. I should be able to
just ignore the TUpDown properties (Min, Max, Position). I'll use the WIN32
Messages (UDM_SETRANGE32, UDM_SETRANGE32, UDM_GETPOS32 & UDM_SETPOS32) to
set/retrieve the 32-bit values. I haven't tried this yet, but it should
work since there is the TUpDown->Handle property which is the HWND handle
needed for the SendMessage() WIN32 API call.
For anyone who might be interested in the outcome, I'll update this thread
with my success (or failure).
James O'Brien
"Mike Collins" <i...@TheBottomOfMy.Posts> wrote in message
news:42fb...@newsgroups.borland.com...
> Yep, that appears to be the case.
>
> I only found one work around for this but it depends on your setup and
> implimentation. If you have the usual setup where you have the TUpDown
> associated with a TEdit box (which display the actual value), then I
> simply
> removed the association and then hard coded the incrment / decrement using
> the OnChangingEx event checking the value of Direction
>
>
Remy Lebeau (TeamB)
> Microsoft had 32-bit support for UpDown control since IE 4.0
> (comctl32.dll version 4.71).
Actually, only for Ranges. 32-bit support for Position was added in
comctrl32.dll version 5.80 ;-)
The issue has been reported as QC #15105.
Gambit
James O'Brien
> For anyone who might be interested in the outcome, I'll update this thread
> with my success (or failure).
>
I decided not to use TUpDown VCL control for the following reasons.
1. The OnChangingEx event handler uses a 16-bit 'NewPos' variable. Need to
write additional code in event handler to try to determine what the 32-bit
new value would be. This gets complicated when you try to use the UDACCEL
structure for controlling the acceleration rate of the control.
2. I wasn't planning on using the 'Buddy' control feature since I need to
write a formatted string and not just a number (or number with commas). So
this feature was useless to me.
3. Didn't like the behavior of the accelaration feature (UDM_SETACCEL).
Too slow; and the one second inverval for acceleration changes is too long.
I ended up using a TScrollBar(sbVertical) control. I only needed to write
an OnScroll event handler that updated the current position when the
following ocurred (scLineUp, scLineDown, scEndScroll). I was able to write
an acceleration mechanism which was based on the number of scroll events (as
opposed to 1 sec. intervals for TUpDown control)
James O'Brien
Vladimir Stefanovic
James O'Brien wrote:
> I decided not to use TUpDown VCL control for the
> following reasons.
>
> 1. [...]
> 2. [...]
> 3. [...]
>
4. If you have TUpDown 'Associate'-d to some TEdit and placed
on some TTabSheet of TPageControl, the TEdit::OnChange event
is automatically fired the FIRST time you visit (select) that 'TabSheet'.
Ok, this is not the reason not to use TUpDown, because
some workarround is possible ;)
Best Regards,
Vladimir Stefanovic
Remy Lebeau (TeamB)
> 1. The OnChangingEx event handler uses a 16-bit 'NewPos' variable.
The OnChanging and OnChangingEx events are responding to the UDN_DELTAPOS
notification message, which already contains 32-bit values. TUpDown casts
them to 16-bit when triggering the events. You will have to subclass the
component in order to intercept the UDN_DELTAPOS notification directly if
you want to work with the full 32-bit values.
Gambit
James O'Brien
> The OnChanging and OnChangingEx events are responding to the UDN_DELTAPOS
> notification message, which already contains 32-bit values. TUpDown casts
> them to 16-bit when triggering the events. You will have to subclass the
> component in order to intercept the UDN_DELTAPOS notification directly if
> you want to work with the full 32-bit values.
I only considered using the TUpDown control because it was available at
design-time. It's too much work to get it to do what I need, and even then
the response is a bit sluggish. The solution I came up with using standard
scroll-bar is more responsive and was less work.
Thanks anyway.