Printable View
This one is with scrollbars and scroll arrows in ZQ and ZC listers.
When there are multiple allegro threads, whatever variable that allegro uses to track scroll speed is losing its mind. This is the cause of support ticket 113:
https://github.com/ArmageddonGames/Z...sic/issues/113
While I had both Grabber, and FontEd open, the listers in ZQuest instantly jumped from the top of the list, to the bottom, or the reverse, when using the arrow buttons.
That seems exceedingly unlikely... Is this consistently reproducible? The list scroll variable isn't used by multiple threads, and there's no reason it should be visible to other processes. If it were being corrupted by another process somehow, I'd expect it to affect a lot of other things, and the program would probably crash before you observed any other effects.
Have you tried watching the variable in a debugger? Or just adding some traces to _handle_jwin_scrollable_scroll_click? The click handling uses a while(gui_mouse_b()) loop (jwin.cpp line 1852). Maybe that's not timed properly for some reason. If it's running as fast as it can, it'll register a lot of clicks at once, which would make it jump like that.
Hard to say if it's related, but I see this line in _handle_jwin_listbox_click:
That first argument to rest_callback is the wait time in milliseconds. Why would the list height and some font size have anything to do with that? That's not even the list font; it's a global one used for other things. That has to be a mistake, but I don't know what the intention might have been.Code:rest_callback(MID(10, text_height(font)*16-d->h, 100), idle_cb);
I cannot reproduce the issue using multiple ZQuest windows or ZQuest+Zelda. Echoing Saffith's question: does this always happen for you when you have two Allegro applications running simultaneously?
Quote:
Originally Posted by DarkDragon
I will run some tests, but this did not have the highest priority. It may only surface when running older allegro programmes (e.g. under ag 4.2, 4.1, 4.0).