View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0031868 | Lazarus | LCL | public | 2017-05-18 12:20 | 2018-07-17 00:05 |
| Reporter | Assigned To | Bart Broersma | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 1.6.4 | ||||
| Summary | 0031868: TEdit + TUpDown + Mouse Wheels | ||||
| Description | TEdit + TUpDown + Arrows (up/down) will increment/decrement value in TEdit instance when focused component is the Tedit instance, however using Mouse Wheels it will not. As well, on Linux, the component should not need to be focused at all to increment/decrement value - only mouse to point on the component. | ||||
| Tags | No tags attached. | ||||
| Fixed in Revision | r55113, r55114 | ||||
| LazTarget | - | ||||
| Widgetset | |||||
| Attached Files |
| ||||
|
|
Yes, in Delphi, a mousewheel increase/decrease the value, in Lazarus (Lazarus 1.9.0 r54960 FPC 3.0.0 i386-win32-win32/win64) it doesn't work. |
|
|
Fixed the mousewheel issue. Please open another report about the focus issue. |
|
|
@Bart: Sorry, I have to reopen this issue. In Delphi the behaviour is the other way around. Over TUpDown a mouse wheel action has no effect. Over TEdit a mouse wheel action increase/decrease the value. |
|
|
> In Delphi the behaviour is the other way around. > Over TUpDown a mouse wheel action has no effect. It's a bit unlogical to me. It might be considered an improvement over delphi, but I reverted r54974. |
|
|
Sorry again Bart, my focus was on Delphi compatibility of TEdit not TUpDown. Maybe I was unclear by reopening the issue. > It's a bit unlogical to me. Yes, for me too. I think a mouse wheel scroll should work over the edit window and the updown. > It might be considered an improvement over delphi, Yes, this was a first step. But imho scrolling with mouse wheel over the edit window is also a nice to have (and imho important for enduser). > but I reverted r54974. Too bad. |
|
|
We would either need a TControl.AddHandlerOnMouseWheel, or in TControl.DoMouseWheelUp/Down iterate all controls that have the same parent, see if that is a TUpDown and TUpDown.Associate = this TControl and then perform the increment/decrement? Note that Associate is not restricted to TCustomEdit. |
|
|
This is how TSpinEdit (found on Misc tab) works currently in Lazarus (I don't know about Delphi). Mouse wheel works same there, no matter whether you are positioned on up-down buttons or on "edit part" of the control. |
|
|
That is probably done on the WS side. |
|
|
As a workaround: it should work with TSpinEdit and TSpinEditEx (the latter one uses a TUpDown). |
|
|
> Did you ever look on the "Samples" palette? @wp: D7 PE does not have a Samples tab, and no SpinEdit. I "upgraded" from D3 pro to D7 PE and lost those components. Probably sasa has the PE version of D7 as well? Back to topic: is it worth it to add a AddHandlerOnMouseWheel or the like? (By that I mean: it is needed for one control only (ATM)) Does Delphi have this mechanism? If so, extending it may break Delphi compatibility. The only other way I see is to check in TWinControl.DoMouseWheelUp/Down (not in TControl) if the control is an associate of a TUpDown. To me that would seem rather inefficient? |
|
|
If I look into the LCL TSpinEdit source text, I see that the edit and updown are bound with UDM_SETBUDDY. There is also the TWin32WindowInfo.UpDown field for the associate. This is the way to go. IIRC from the time I improved TSpinEdit, the mouse wheel is handled automatically once you set the buddy. Please don't do any inefficient searches etc. Also, public properties (AddHandlerXYZ and other events) shouldn't be used inside the LCL for its features. I have no idea about other WidgetSets but win32. |
|
|
TUpDown is a custom made control, entirely drawn by LCL. I don't think the situation for TSpinEdit applies here? > Also, public properties (AddHandlerXYZ and other events) shouldn't be used > inside the LCL for its features. TUpdown alread does this: just look at the implementation of TCustomUpDown.SetAssociate. |
|
|
> TUpDown is a custom made control, entirely drawn by LCL. I don't think the situation for TSpinEdit applies here? It is a TWinControl descendant so at least it has a handle. > TUpdown alread does this: just look at the implementation of TCustomUpDown.SetAssociate. I see. I was wrong - checking the event handlers code, the programmer can hardly interfere with the LCL-only event handlers (AssociateKeyDown, OnAssociateChangeBounds, etc). So you are right, a new AddHandlerOnMouseWheel is absolutely OK and the best approach! |
|
|
Please test and close if OK. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-05-18 12:20 |
|
New Issue | |
| 2017-05-18 12:48 | Michl | LazTarget | => - |
| 2017-05-18 12:48 | Michl | Note Added: 0100430 | |
| 2017-05-18 12:48 | Michl | Status | new => confirmed |
| 2017-05-18 18:59 | Bart Broersma | Assigned To | => Bart Broersma |
| 2017-05-18 18:59 | Bart Broersma | Status | confirmed => assigned |
| 2017-05-18 19:03 | Bart Broersma | Fixed in Revision | => r54974 |
| 2017-05-18 19:03 | Bart Broersma | Note Added: 0100447 | |
| 2017-05-18 19:03 | Bart Broersma | Status | assigned => resolved |
| 2017-05-18 19:03 | Bart Broersma | Resolution | open => fixed |
| 2017-05-18 19:03 | Bart Broersma | Target Version | => 1.8 |
| 2017-05-18 20:45 | Michl | Note Added: 0100456 | |
| 2017-05-18 20:45 | Michl | Status | resolved => assigned |
| 2017-05-18 20:45 | Michl | Resolution | fixed => reopened |
| 2017-05-18 20:45 | Michl | Note Edited: 0100456 | View Revisions |
| 2017-05-19 18:28 | Bart Broersma | Assigned To | Bart Broersma => |
| 2017-05-19 18:28 | Bart Broersma | Status | assigned => new |
| 2017-05-19 18:39 | Bart Broersma | Note Added: 0100500 | |
| 2017-05-19 22:50 | Michl | Note Added: 0100516 | |
| 2017-05-20 00:06 | Bart Broersma | Note Added: 0100518 | |
| 2017-05-20 00:09 | Bart Broersma | Fixed in Revision | r54974 => |
| 2017-05-20 00:09 | Bart Broersma | Target Version | 1.8 => |
| 2017-05-20 00:11 | Bart Broersma | Note Edited: 0100518 | View Revisions |
| 2017-05-20 00:16 | Zoran Vučenović | Note Added: 0100520 | |
| 2017-05-20 12:27 | Bart Broersma | Note Added: 0100538 | |
| 2017-05-20 14:19 | Bart Broersma | Note Added: 0100541 | |
| 2017-05-22 21:46 | Bart Broersma | Note Added: 0100611 | |
| 2017-05-24 23:21 | Bart Broersma | Note Edited: 0100611 | View Revisions |
| 2017-05-24 23:22 | Bart Broersma | Note Edited: 0100611 | View Revisions |
| 2017-05-25 00:13 | Ondrej Pokorny | Note Added: 0100667 | |
| 2017-05-25 00:13 | Ondrej Pokorny | Note Edited: 0100667 | View Revisions |
| 2017-05-25 23:13 | Bart Broersma | Note Added: 0100685 | |
| 2017-05-26 08:04 | Ondrej Pokorny | Note Added: 0100693 | |
| 2017-05-27 00:00 | Bart Broersma | Note Edited: 0100500 | View Revisions |
| 2017-05-27 15:06 | Bart Broersma | Assigned To | => Bart Broersma |
| 2017-05-27 15:06 | Bart Broersma | Status | new => assigned |
| 2017-05-28 12:17 | Bart Broersma | Fixed in Revision | => r55113 |
| 2017-05-28 12:31 | Bart Broersma | Fixed in Revision | r55113 => r55113, r55114 |
| 2017-05-28 12:31 | Bart Broersma | Note Added: 0100724 | |
| 2017-05-28 12:31 | Bart Broersma | Status | assigned => resolved |
| 2017-05-28 12:31 | Bart Broersma | Resolution | reopened => fixed |
