View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000057 | Ecere SDK | ide | public | 2008-05-03 17:35 | 2016-04-19 05:19 |
| Reporter | rnsanchez | Assigned To | |||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Platform | Linux | OS | Slackware | OS Version | 12.0 |
| Target Version | 0.46 eC II | ||||
| Summary | 0000057: mouse scroll in File > Open working only after click | ||||
| Description | After clicking on File > Open, to open a project, the mouse scroll (wheel) inside file browser only worked after clicking in that window. Seems like z-buttons events going somewhere else, or focus not set to that window? | ||||
| Steps To Reproduce | 1- Open Ecere SDK 2- Open a file/project (File > Open) 3- Use mouse wheel over Open Dialog (should not work) 4- Click on the Open Dialog (anywhere) 5- Mouse wheel should work now. | ||||
| Additional Information | KDE-3.5.7 | ||||
| Tags | No tags attached. | ||||
|
|
This behavior is also happening pretty much on every window opened. I've just opened the Help (F1), and mouse wheel only worked after clicking. It _may_ be something specific to KDE (I was using XFCE a few moments ago), but ensuring (mouse) focus to new windows would be great. |
|
|
Windows with 2 scrolls (like the API Documentation Browser), I need to click on the frame I'd like to scroll with mouse before mouse wheel works on that particular frame. |
|
|
At first I thought you were talking about an activation issue, but this is actually the standard behavior in Ecere that the mouse wheel doesn't follow the mouse position, but the rather the active control, just like keyboard keys. In fact, the mouse scrolling is processed exactly like a keyboard hit in the OnKeyHit window event. I realize this is contrary to the established behavior in other GUIs, but what I like about it is that even if your mouse goes slightly off the window you were scrolling in, you can still keep scrolling. If you think about it, this is more permissive in that you only need to have the window "active" (not point the mouse to it, it could already be active or activated through other means) whereas requiring to have the mouse "over" is just a click away from actual activation through clicking. This would need to be debated further. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-05-03 17:35 | rnsanchez | New Issue | |
| 2008-05-03 17:39 | rnsanchez | Note Added: 0000021 | |
| 2008-05-03 17:44 | rnsanchez | Note Added: 0000022 | |
| 2008-05-04 06:26 | jerome | Status | new => assigned |
| 2008-05-04 06:26 | jerome | Assigned To | => jerome |
| 2008-05-05 19:44 | jerome | Priority | normal => high |
| 2008-05-05 19:58 | jerome | Note Added: 0000029 | |
| 2008-05-05 19:58 | jerome | Status | assigned => acknowledged |
| 2008-05-05 19:59 | jerome | Priority | high => low |
| 2008-05-06 07:15 | jerome | Assigned To | jerome => |
| 2012-03-08 16:52 | redj | Target Version | => 0.45 Ginkakuji |
| 2012-03-29 07:52 | redj | Category | => ide |
| 2012-03-29 07:52 | redj | Project | @3@ => Ecere SDK |
| 2014-07-11 18:24 | jerome | Target Version | 0.45 Ginkakuji => 0.46.1 |
| 2016-04-19 05:19 | jerome | Target Version | 0.46.1 => 0.46 eC II |
