Scrolled lists are broken

[Dwachs]

Scrolled lists are broken: if the list cannot be displayed completely, then the mouse pointer does not select the item under the cursor but some entries above in the list. I do not know how and where to fix this :/

[kierongreen]

Any lists in particular? Lines seem to work fine here?

[Dwachs]

Line management window if more lines are available than can be displayed at once.

[captain crunch]

I noticed something new in revision 6743. It is a bit annoying in the depot window also.

[prissi]

Thank you, that should be fixed in -r 6753. But the lists are still under renovation, so other errors may appear too.

[whoami]

Using rev6760: selecting an existing line for a convoy in a depot (tested: trains, trucks) will always give me a *random* line from the list (of ~ 500 lines). Also, clicking the arrows to scroll sideways through the lines will show random sorting (and this is really random: navigating one entry forth and then one back shows a different one than before).
I have not narrowed this down to a certain revision - from the comments it originates perhaps from 6753, 6743, but most probably 6740.

Update: I compared the behaviour in previous nightly builds and it seems like rev.6740 introduced all the problems that I mentioned, but I could only compare against rev.6729. Additional problem: the line that is shown as selected for the convoy in the depot is not the line shown in the schedule dialogue, but its neighbour in the (sorted) list.

[prissi]

Yes this is still in transition. r6765 may cure some problems.

[whoami]

With two different developed maps (-> many lines), rev. 6765 reliably crashes on opening a depot.

[prissi]

It does not for me, sorry. I have tried several games and depots.

[Max-Max]

Using rev6760: selecting an existing line for a convoy in a depot (tested: trains, trucks) will always give me a *random* line from the list...

I can confirm this problem in rev6767. But I have figured out the "random" pattern...
If I want to select the line on row #4 counted from the top, I have to click on row #4 counted from the bottom. It seems like the list is responding in reverse...

[Dwachs]

With two different developed maps (-> many lines), rev. 6765 reliably crashes on opening a depot.

Should work with r6769 again.

[Vladki]

I confirm this bug in r6767, it does not depend if the list will fit into the window or not. It is broken even if the list has only two items. Especially nasty when I want to reassign a vehicle from one line to another.

[whoami]

So rev. 6770 does not crash, so I can test again: In the depot, the line selected from the drop-down box is still not the one that is assigned. But the assigned is now the same as shown in the schedule dialog.

If I want to select the line on row #4 counted from the top, I have to click on row #4 counted from the bottom. It seems like the list is responding in reverse...

With rev. 6770, my observation is that a constant offset (perhaps constant only for a given depot type and game) is added when selecting a line, and that offset may be the half of the list's length.

[Dwachs]

Surprisingly, this bug appears to trigger only if there is a convoy in the depot. There seems to be always an offset of -4 involved, even navigating with arrow keys does not work.

If there is no convoy, then the selection is fine.

Edit: Please retest with r 6772.

[whoami]

OK, waiting for the nightly build.
EDIT: the offset varies between different depots (if the most recent line is set, the list is different) and game states, and wrap-arounds seem to occur, whatever that means in terms of data consistency.

Side note: selecting a line without a convoy is not useful, because assembling a convoy after that clears the line selection. (I have not checked whether that has changed.)

[Dwachs]

Selection does not work properly still ?

[whoami]

I referred to the state before your commit, because I still haven't tested.

[whoami]

Testing rev. 6781 line list in the depot: It looks like the scrolled list works properly now.

EDIT: Functionality that was lost due to changes after 6729: when jumping into line management window from the convoy dialog or station details window, the line list (panel) is not adjusted to enforce the line to be shown there (as it was in 6729), i.e. the list is not scrolled to the selected entry.

[whoami]

With rev.6781, I just have discovered that line selection in the convoy schedule dialogue is broken in the same way as it was for the depot window: the wrong line is taken when another line is selected from the list (offset -7 for the tested case) and navigating in the list using the horizontal arrows gives a random pattern.

[whoami]

line selection in the convoy schedule dialogue is broken in the same way as it was for the depot window

This problem can be observed in rev.6875 (nightly) as well, same symptoms. It is quite an impediment for playing.
Was rev.6788 meant to be a fix?

Here is a savegame from me: http://simutrans-germany.com/files/upload/Wernieman_STIF20120722_X198_M231c_V112.x-6875_SJ2019_bzip2.sve (pak64)
Update: I have observed this with trams, trains, busses (but the latter with exceptions). Also strange: even if the correct line is chosen (by using the offset) and shown, the schedule may belong to the wrong line. Check e.g. tram 721 in the savegame: open vehicle dialogue, open schedule, try to assign the same line and also a different line.

Functionality that was lost due to changes after 6729: when jumping into line management window from the convoy dialog or station details window, the line list (panel) is not adjusted to enforce the line to be shown there (as it was in 6729), i.e. the list is not scrolled to the selected entry.

This prevails, too. Restoring this feature would be helpful.

[prissi]

Should be fixed in revision 6878 (an obsolete double bookkeepign was the cause).

[whoami]

Thank you.
The only problem that remains is the missing adjustment (auto-scroll to the selected entry) of the displayed line list when jumping into line management, e.g. from station details window.

[Train-catcher]

See attachement.
When I press button 1 then line management window appears. But the window 2 wont scrolls to the selected line (#31)
This seemed to be bug rather that feature. It didn't appear in earlier builds.

[Dwachs]

should be fixed in r6903.

[whoami]

Thanks for the fix. I may have to supply more screenshots to support my bug reports. (Alas, no screenshot here:)
Another bug (or maybe several ones) with scrollbars in line management, found with r6906 Win-SDL nightly, please use savegame http://simutrans-germany.com/files/upload/PC184G3_31.sve (2 MB) with Pak128.Britain nightly rev.1315 (or compatible):

1st problem:
- open line management
- select tab for road vehicles
- scroll down to the last road vehicle line (optional: select the line)
- switch to the tab for the trains (standard gauge)
result: this tab is shown as empty, which is wrong. Same for trams tab (line 69 should be shown). But some line (usually one for road vehicles) may be shown (different from the one under the road vehicle tab).
The display can be enforced by scrolling down in the trains tab, but this is not possible in the trams tab (too few lines).

2nd problem
- the scrollbar position in the upper left pane of the line management window may not reflect the visible part of the list. This happens if the tab head is clicked on for a second time: it moves to the top. There may be other triggers for this (perhaps the addition or deletion of a line).

Also note: the behaviour may change after some tries, e.g. the train tab may appear normally. Reloading the savegame need not revert the behaviour to the one described, but restarting ST will do so. This and the sometimes random choice of the line in the lower left pane (in case of the display errors described above) makes me guess that there are uninitialized variables (pointer/reference), e.g. the pointer(s) into the respective tab's list. (Once a train line has been selected in the tab, the list in the trains tab will always be shown. But still the trams tab will usually remain empty.)

(A lot of words, but using screenshots would mean much more work for me.)

[whoami]

Rev. 6982: the scrolled lists still have these two bugs (mentioned in my previous post). Especially the scroll bar in the line management (upon opening it) is misplaced so often that there are most likely uninitialized variables following every instantiation (overwritten memory would also explain both, but the program remains stable). You need a savegame with many lines (like the one supplied by me) to see either problem.

[prissi]

Try r6991 please

[whoami]

(Tested with e.g. r7005:) The line management window seems to behave normally again, thanks a lot.
I guess that the line selector in the depot window needs the same fix for the scroll bar placement, as it mis-indicates in the same way (but repeatedly in an open window, not just its first use): Select a line for an existing convoy, open the drop-down box again: the bar is then often at the lower end, so touching it (or the vertical arrows) to scroll makes the contents jump.
(I was going to say the same about the line selector in the convoy schedule dialogue, but I cannot reproduce that glitch at the moment.)

[prissi]

Sorry, I could not reproduce this. The scroll bar was always where it should be. Please describe the situation more detailed, or indicate a certain savegame.

[whoami]

Oh, I forgot to link the savegame, here it is:
http://simutrans-germany.com/files/upload/PC184G3_132_ST-r7005_SJ1930-05_Pak128.Britain-r1382.sve
But I think that you only need a savegame with hundreds of lines of one type.
How to reproduce it in my savegame:
- open road depot at (160,205) (any other road depot should do as well)
- assemble a convoy
- assign line No. 200 (from the middle of the list)
- click on the line selector again: the scroll bar is near the end, not in the middle
- click on the lower arrow: the list jumps to the end instead of scrolling forward (or backwards for the upper arrow)
If the effect vanishes: it can be repeated if you assign a line from the beginning or end of the list in the meantime.
I could only test with r7005.

[Ters]

I can reproduce this. It only happens after selecting a schedule (even the already selected). If you select a schedule, close the depot window and open it again, then the drop down list behaves right. If you get a misbehaving drop down and close it (the drop down, not the entire depot window), the list is still wrong if it is opened again. But if you scroll before closing it, it us centered right on the selected schedule when it is opened again, even if you don't scroll to the right place before closing.

[Dwachs]

Strange enough, this does not happen in network mode ....

Edit: fixed in r7072.