Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

patch: fix minor 'goto' button bug #311

Closed
DorpsGek opened this issue Aug 29, 2006 · 4 comments
Closed

patch: fix minor 'goto' button bug #311

DorpsGek opened this issue Aug 29, 2006 · 4 comments
Labels
component: interface This is an interface issue flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay

Comments

@DorpsGek
Copy link
Member

GrimRC opened the ticket and wrote:

The 'goto' button, in a vehicle's order window, remains pressed after being clicked, and the mouse cursor changes. The buggy behaviour is that clicking other order-related buttons, such as 'skip', 'full load' and 'delete', depresses the 'goto' button, although the mouse cursor is still in 'goto' mode. 'goto' mode still works properly, allowing you to select a station to add to the vehicle's orders, but clicking on the now depressed 'goto' button does not unset the 'goto' mouse cursor. The only ways to unset it are to press ESC, close the vehicle's orders window or select a station destination with the mouse cursor. The patch removes the WDF_UNCLICK_BUTTONS flag from the vehicle orders window, and handles button unclicking in WE_TIMEOUT (not unclicking the 'goto' button, naturally).

Thanks to 'Frostregen' & 'Belugas_Gone' for help.

Attachments

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/311
@DorpsGek
Copy link
Member Author

GrimRC wrote:

Here's a screenshot showing the 'goto' mouse cursor with the 'goto' button depressed.

If you're bored and looking for another patch to apply, check out this one: http://bugs.openttd.org/task/306

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/311#comment476

@DorpsGek
Copy link
Member Author

GrimRC wrote:

I've compiled openttd version 0.4.8 and confirmed this display bug is present their too.

This comment was imported from FlySpray: https://bugs.openttd.org/task/311#comment480

@DorpsGek
Copy link
Member Author

GrimRC wrote:

An improved patch is attached. I misused the word 'depressed' in my description of the bug, above. By a button being 'depressed', I actually meant 'unpressed'. My description is generally a little confusing. As can be seen in the image in my comment above, the mouse cursor is a 'goto' mouse cursor (difficult to spot, but it is there I assure you), and you can also see that the 'goto' order button has been raised/unpressed. This is the buggy state. Clicking on the 'goto' button will not cancel the 'goto' mouse cursor in this state. This isn't serious though, as there are other ways to cancel the 'goto' mouse cursor.

Thanks to Rubidium for improving the patch!

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/311#comment482

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 3, 2006

Darkvater closed the ticket.

Reason for closing: Implemented

r7046

This comment was imported from FlySpray: https://bugs.openttd.org/task/311

@DorpsGek DorpsGek closed this as completed Nov 3, 2006
@DorpsGek DorpsGek added component: interface This is an interface issue flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay labels Apr 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component: interface This is an interface issue flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@DorpsGek