Scroll with mouse key on gamearea

[Laserlicht]

With this you can move the section on the gamearea with the right mouse button.

Facilitates the operation on the Steam Deck immensely.

Unfortunately, I'm not that much of a C++ expert at the moment and my knowledge of the codebase is also limited.

Done ~~Could still need some support here for:~~

• ~~Clean integration (not so hacky)~~
• ~~Faster refresh when scrolling, currently it's a bit laggy~~
• ~~quickinfos outside the gamearea should not hide the menu after moving the mouse while pressing the right mouse button~~
• ~~ignore scrolling at the edge of the screen while pressing the right mouse button~~

[LeHerosInconnu]

Hello @Laserlicht,

Is this feature similar to this one: https://github.com/ihhub/fheroes2/issues/1860?

I think that using the left click and hold would be better, because with the right click and hold an information window is displayed. Using the left mouse button is also more natural and convenient because it is the most used button by the user. And many other video games use the left click and hold for this functionality. :)

In fheroes2: (Information window with right click and hold.)

[Laserlicht]

Hello @LeHerosInconnu

Thank you very much for your advice. 🙂

Yes, this is similar to your issue.

I decided to use the right mouse button, because the HoMM3 HD patch also introduced this feature this way a few months ago. It would be so that the information window is displayed and if you move the mouse while holding the button, it disappears again and you can scroll.

For the Steam Deck, the right mouse button would probably also be better, so that you do not immediately move the screen section with imprecise clicks.

But sure, that's debatable. 🙂

[zenseii]

Good evening @LeHerosInconnu and @Laserlicht 😊

Both of your points are very good and I would just like to add that what button to use could simply be made user-configurarable in what is currently the list of "hotkeys".

Also, thanks for implementing this @Laserlicht!

[LeHerosInconnu]

Hello @Laserlicht and @zenseii,

Both of your points are very good and I would just like to add that what button to use could simply be made user-configurarable in what is currently the list of "hotkeys", since that is basically the first steps of key configuration.

Indeed, it would be even better if the user could choose the mouse button that best suits him to perform the action.

Also, thanks for implementing this @Laserlicht!

As @zenseii said, thanks @Laserlicht! :)

[Laserlicht]

I have implemented it now with the right mouse button. An option for the left mouse button could be added in a 2nd expansion step.

Here you can see how it behaves. With the right mouse button still and moving. The animation is not as smooth as the original due to the GIF format.

[LeHerosInconnu]

Hello @Laserlicht,

So I tested this in several resolutions. It works well, good job. :)

But, in my case, the use of the left mouse button would be preferable, because I find that the right-click information window, appearing even surreptitiously, is annoying.

https://user-images.githubusercontent.com/43583994/169689234-4d0e6bde-9956-4f68-b19e-dab61690f002.mp4

So you can implement the 2nd expansion step for the use of the left mouse button. :)

Also, would it be possible to prevent the mouse cursor from blinking when the user releases the mouse button on one of the screen edges, where the arrow cursor of the screen edge should appear?

https://user-images.githubusercontent.com/43583994/169689292-528d671f-6bd4-48ca-92ea-61e1d8cb6267.mp4

[Laserlicht]

Hi @LeHerosInconnu The bug with the flickering cursor should be gone.

I have optimized the whole thing a bit. For a left mouse button now only four lines or so would have to be adjusted (only in interface_gamearea.cpp). I have already tested this local. Also works well so far.

However, I currently do not know how the settings system of fheroes2 works... The best would be a tristate setting. Off, left and right mouse button...

[LeHerosInconnu]

Hello @Laserlicht,

Hi @LeHerosInconnu The bug with the flickering cursor should be gone.

I have optimized the whole thing a bit. For a left mouse button now only four lines or so would have to be adjusted (only in interface_gamearea.cpp). I have already tested this local. Also works well so far.

Okay, I'll take a look at it tomorrow. :)

However, I currently do not know how the settings system of fheroes2 works...

Maybe @zenseii could advise you about it.

The best would be a tristate setting. Off, left and right mouse button...

Good idea for the three-state setting. :)

[Eldorias-Piano-Covers]

Great, thanks ! Could it be possible to make this work with the middle click (click on the wheel) ? Like Starcraft 2 style ?

[LeHerosInconnu]

Hello @Laserlicht,

Hello @Laserlicht,

Hi @LeHerosInconnu The bug with the flickering cursor should be gone. I have optimized the whole thing a bit. For a left mouse button now only four lines or so would have to be adjusted (only in interface_gamearea.cpp). I have already tested this local. Also works well so far.

Okay, I'll take a look at it tomorrow. :)

I did a test in several resolutions, both in full screen and in windowed mode, and the cursor flickering problem is gone. Nice. :)

However, I noticed a small problem. :) When the user releases the mouse button on the right edge of the screen and moves the mouse over the area where the main interface is located (the area with the minimap, heroes and castles lists, command buttons, etc.) and tries to scroll the adventure map area by moving the mouse cursor to the edge of the screen (where the mouse cursor should then turn into an arrow before scrolling the screen) it does not work. The user must first move the mouse cursor to the adventure map display area before moving the mouse cursor to the edge of the screen to activate the arrow cursor which then scrolls the screen. The same goes for the small portion of the main interface area at the top and bottom right for scrolling up and down the screen.

In fheroes2:

https://user-images.githubusercontent.com/43583994/169756333-024d0aa8-7a94-4ae6-a990-969b2a48c975.mp4

[zenseii]

However, I currently do not know how the settings system of fheroes2 works...

Maybe @zenseii could advise you about it.

I've honestly not looked at this part of the code so I wouldn't be able to help much I'm afraid. Sorry :P

[felix642]

Hey @LeHerosInconnu, @Laserlicht

I was taking a look at the setting for this new feature and I was wondering where you wanted to add the option ? With what we currently have it's not trivial to add the new setting since we need to support a tri-state button and the only menu that support this kind of feature is this one :

As you can see, this menu doesn't have space for a new button unless we decide to change the layout. We would also need to add a new Icon which would require a moderate amount of work.

So before going further I would like to know where we should add the setting for this new feature ?

[Laserlicht]

Great, thanks ! Could it be possible to make this work with the middle click (click on the wheel) ? Like Starcraft 2 style ?

Could be pssible by extending localevent.cpp with some functions for the middle button.

[Laserlicht]

@LeHerosInconnu

However, I noticed a small problem. :)

Should be gone. :)

[Laserlicht]

Hi @felix642

As you can see, this menu doesn't have space for a new button unless we decide to change the layout. We would also need to add a new Icon which would require a moderate amount of work.

That's a general question about how you want to deal with it in the future. Maybe a second page? But yes, that is not a little effort to change.

We could also take the experimental submenu. But there it doesn't quite fit and there only binary settings are supported.

Hmm...

[LeHerosInconnu]

Hello @felix642 and @Laserlicht,

Hi @felix642

As you can see, this menu doesn't have space for a new button unless we decide to change the layout. We would also need to add a new Icon which would require a moderate amount of work.

That's a general question about how you want to deal with it in the future. Maybe a second page? But yes, that is not a little effort to change.

We could also take the experimental submenu. But there it doesn't quite fit and there only binary settings are supported.

Hmm...

Could it be set in the fheroes2.cfg file for now?

"# scroll the adventure map with the mouse button: 0 - 3 mouse button = 1"

0: disabled 1: left mouse button 2: right mouse button 3: middle mouse button

Can be set to "0" (same operation as the original game) or to "1" (to avoid "spurious appearance" of right click windows) by default.

[LeHerosInconnu]

@Laserlicht.

@LeHerosInconnu

However, I noticed a small problem. :)

Should be gone. :)

Tested, and yes it's gone. Nice. :)

[Laserlicht]

Could it be set in the fheroes2.cfg file for now?

"# scroll the adventure map with the mouse button: 0 - 3 mouse button = 1"

0: disabled 1: left mouse button 2: right mouse button 3: middle mouse button

Can be set to "0" (same operation as the original game) or to "1" (to avoid "spurious appearance" of right click windows) by default.

I am currently not familiar with the cfg file. And therefore I can only badly judge whether this is the right way.

But yes, the 4 options looks good. :)

[Laserlicht]

Could it be set in the fheroes2.cfg file for now? "# scroll the adventure map with the mouse button: 0 - 3 mouse button = 1" 0: disabled 1: left mouse button 2: right mouse button 3: middle mouse button Can be set to "0" (same operation as the original game) or to "1" (to avoid "spurious appearance" of right click windows) by default.

I am currently not familiar with the cfg file. And therefore I can only badly judge whether this is the right way.

But yes, the 4 options looks good. :)

I have added an option for testing: Everything is possible. 😀 It's active right now, too.

Now we just need a solution to get the variable here from somewhere else... int key = 4;

And we should introduce an enum...

[LeHerosInconnu]

Hello @Laserlicht,

I have added an option for testing: Everything is possible. grinning It's active right now, too.

I did a test, and everything works fine with any of the three mouse buttons. :)

After use, I noticed a small inconvenient. :) Would it be possible to avoid that when the user makes a not very precise click (he clicks on a place and moves the mouse cursor slightly before releasing the mouse button) the area of the adventure map is not modified? For example, make the area of the adventure map change only if the mouse cursor moves out of the square (of the adventure map) where the click was made. Or adding an adjustable delay parameter before the mouse cursor movement is taken into account.

In fheroes2 (not very precise click, voluntarily amplified for the demonstration):

https://user-images.githubusercontent.com/43583994/170224651-e41bd049-c01c-4237-8bdc-05ecbb0cb16b.mp4

[Branikolog]

Hello, everyone! My 5 cents about this enhancement. I definitely agree with @LeHerosInconnu : left click feels more natural, since we mostly use left click to create a path for our hero or creature. At the same time we use single short left clicks throughout the game, so adding scroll on holding left click takes its relevant place as a unique mechanic. While right click is mostly for info. And we mostly hold right click continuously, so we will often come into the situation, when we want to check info, hold right mouse button and accidentally move mouse a bit, what makes screen move. That's why in my personal point of view, right click shouldn't be used for screen scrolling at all, as it creates a mess for players. Yes, I know, that many games have exactly right click implementation of screen scrolling, but for Heroes 2 left click looks much, much more suitable. (Also, central button seems more like a more possible solution, comparing to the right click). So I don't even think it's worth making the right click scrolling available for user, as it feels not good enough. Returning to the current implementation... I think, after scrolling was initiated by holding mouse button, the cursor should be fixed on the same place on the screen, while we make some scrolling activity. So we we won't be restricted by a small area of the adventure map and can scroll the entire map (limited only by our mouse pad). Ideally, this fixed cursor should change its form, so player can recognize that scrolling is initiated. For cursor options we have already implemented color/monochrome adjustment. So we an convert that item in menu into a separate submenu, where cursor color, scrolling manner and even cursor speed could be customized.

[Laserlicht]

Hello all,

yes, I must honestly say that the left mouse button does not feel bad.

Just find it unattractive that H3 HD uses the right one. Then the operations would be different...

That you accidentally close the quick menu is unlikely. There is an offset that scrolls only after x pixels, which should prevent exactly that.

Yes, the previous implementation has the disadvantage that you can move maximum the section size on a time. But it has the advantage that you can adapt it directly to touch devices (maybe this works out of the box? - don't have a windows touch device...).

@LeHerosInconnu That's something I can't really influence at all. SDL decides whether it is a click or a press-and-hold.

Sure, you can introduce a minimal mouse movement (as with the right button). But that's a bit of a tradeoff between clean scrolling and usibility.

[LeHerosInconnu]

Hello @Laserlicht,

@LeHerosInconnu That's something I can't really influence at all. SDL decides whether it is a click or a press-and-hold.

Sure, you can introduce a minimal mouse movement (as with the right button). But that's a bit of a tradeoff between clean scrolling and usibility.

We could leave it as it is for now until we find a solution or get rid of SDL. :)

[Laserlicht]

There is now a setting option via the cfg file.

[Laserlicht]

@LeHerosInconnu Can you test the changes?

[LeHerosInconnu]

Hello @Laserlicht,

@LeHerosInconnu Can you test the changes?

I have some bugs to report and I'll take a look at it later today or tomorrow. :)

[LeHerosInconnu]

Hello @Laserlicht,

Hello @Laserlicht,

@LeHerosInconnu Can you test the changes?

I have some bugs to report and I'll take a look at it later today or tomorrow. :)

I did some testing and this is what I noticed.

With the "left" and "middle" settings, when the right mouse button is pressed and held, and the left (or middle, depending on the setting) mouse button is clicked, the adventure map view changes.

https://user-images.githubusercontent.com/43583994/172378361-0df4adec-cdf0-461d-91ee-83bfcf682699.mp4

With the "left" setting, when the left mouse button is pressed and held from the adventure map area, and then released over the minimap area, it behaves as if a click was made on the minimap and the adventure map view is changed. This problem is not specific to the "drag scroll" mode and is already reported here: https://github.com/ihhub/fheroes2/issues/2332.

https://user-images.githubusercontent.com/43583994/172378468-11165ea4-8e79-4634-b7ed-5f9648a082bc.mp4

[LeHerosInconnu]

Hello @Laserlicht,

Thinking about the problems encountered, I have some suggestions. :)

To solve the problem presented with "drag scroll" (for example with the minimap area), wouldn't it be possible to make it so that when the mouse button is pressed and held from the area of the adventure map (in the example the red frame) the mouse cursor cannot leave the area of the red frame (so, as long as the mouse button is not released)?

Also for the problem of the not very precise click of the user (he clicks on a place and moves the mouse cursor slightly before releasing the mouse button), would it be possible to make the adventure map area start scrolling only when the mouse button is clicked and held AND the mouse cursor has moved at least 10 pixels (or another value)?

[Branikolog]

Hi, @Laserlicht . I believe, current implementation of drag-scrolling could be quite comfortable for devices with touch screen. But at PC we don't have a restriction regarding scrolling area (I mean physical screen size), so it would be much more effective to lock cursor at single place and initiate infinite screen scrolling while moving mouse into single direction.

[LeHerosInconnu]

Hello @Branikolog,

Hi, @Laserlicht . I believe, current implementation of drag-scrolling could be quite comfortable for devices with touch screen. But at PC we don't have a restriction regarding scrolling area (I mean physical screen size), so it would be much more effective to lock cursor at single place and initiate infinite screen scrolling while moving mouse into single direction.

What exactly do you mean by "lock cursor at single place and initiate infinite screen scrolling while moving mouse into single direction."? It looks like the same scrolling of the adventure map as with the edges of the screen but from a point defined with the mouse cursor, right?

The advantage of "drag scroll" is that it is much more precise and convenient to use than a function that would be similar to scrolling like with the screen edges.

[Branikolog]

Hello, @LeHerosInconnu Sorry for my thought being explained not clear. :)

Current implementation has a limitation: we press mouse button, move mouse, but the scrolling will stop, when the cursor reaches the edges of the adventure map screen. In a case we press mouse button, while cursor is close to the left edge, for instance, and start moving it to the left side of the screen, we can move the visible area just on a little distance.

lock cursor at single place and initiate infinite screen scrolling while moving mouse into single direction

By this, I mean the next behaviour: We press mouse button and start moving mouse. On the screen we will see, that cursor stays at the same place regarding the edges of the monitor, but scrolling will be possible to any direction until we stop moving mouse.

My idea is to lock the cursor on the same place of the screen and proceed scrolling without the limitation of the adventure map frames.

[LeHerosInconnu]

Hello @Branikolog,

Hello, @LeHerosInconnu Sorry for my thought being explained not clear. :)

No worries. :)

Current implementation has a limitation: we press mouse button, move mouse, but the scrolling will stop, when the cursor reaches the edges of the adventure map screen. In a case we press mouse button, while cursor is close to the left edge, for instance, and start moving it to the left side of the screen, we can move the visible area just on a little distance.

lock cursor at single place and initiate infinite screen scrolling while moving mouse into single direction

By this, I mean the next behaviour: We press mouse button and start moving mouse. On the screen we will see, that cursor stays at the same place regarding the edges of the monitor, but scrolling will be possible to any direction until we stop moving mouse.

My idea is to lock the cursor on the same place of the screen and proceed scrolling without the limitation of the adventure map frames.

Okay, I see. It works exactly the same way, but it is no longer the position of the mouse cursor that drives this, but the movement pulses sent by the mouse as a device. Not sure if this is really necessary. And what about from a programming point of view?

The "drag scroll" is convenient to observe the surroundings close to the hero or the surroundings a little further away:

https://user-images.githubusercontent.com/43583994/172885774-22a91c18-8e3d-4b7c-962a-69710d896fe9.mp4

Or, for example, observe the adventure map according to the path a hero will follow:

https://user-images.githubusercontent.com/43583994/172886130-c3ed16e9-e21d-44a9-a72d-30f08925069d.mp4

To view larger parts of the adventure map, using the minimap's "drag scroll" is much more convenient:

https://user-images.githubusercontent.com/43583994/172886333-2b899c03-b24e-4fd5-87c9-e38a0e3cd55e.mp4

[Laserlicht]

Many thanks to you!

@LeHerosInconnu All your bugs should be gone. For the left click I think I also found a solution based on your idea. 😄 I had to remove the 'all' option only because of this. It was too much work for me to implement it cleanly. But that should not be a problem (except for testing). Can you test all the options? 😊

@Branikolog I understand how you mean that. But I don't think it's that easy to implement from program point of view. You would have to go deep into the event system (to reset or hold the cursor, for example -> same problem as restricting mouse to "red" area, @LeHerosInconnu). That's why I'm not going to implement it that way. If there is a need, this can still be implemented as a selectable option in future.

I think the current variant is better. It is also simply more familiar. From smartphones/tablets and other software such as Google Maps, for example. Sure, in a small window, the variant would have great advantages. But I think most play full screen or maximized. There, the advantage is almost limited to the neccessary pressing/releasing the button when you lift the mouse.

[LeHerosInconnu]

Hello @Laserlicht,

Many thanks to you!

You are welcome. :)

@LeHerosInconnu All your bugs should be gone. For the left click I think I also found a solution based on your idea. smile

Nicely done. :)

I had to remove the 'all' option only because of this. It was too much work for me to implement it cleanly. But that should not be a problem (except for testing).

It's all right for me.

Can you test all the options? blush

Here are my observations after some tests.

With the "left" setting.

If the left mouse button is pressed and held from the adventure map area and the mouse cursor is moved over the minimap area and the mouse button is released, the left mouse click over the minimap area to change the minimap view is not taken into account, the right mouse click over the minimap area is correctly taken into account. You have to go back to the adventure map area and then back to the minimap area for everything to work as expected.

https://user-images.githubusercontent.com/43583994/173229121-78f139c8-2f70-4774-a561-7cddc8d802e6.mp4

The "drag scroll" can be initiated if the left mouse button is pressed and held from the interface area on the right side of the adventure map (minimap, heroes and castles lists, command buttons area, status window on the bottom right of the screen).

https://user-images.githubusercontent.com/43583994/173229175-1a4d8c06-ae4c-4c17-9101-b68a9372ec50.mp4

The condition of moving the mouse cursor (for the problem of the not very precise click of the user (he clicks on a place and moves the mouse cursor slightly before releasing the mouse button)) to trigger the "drag scroll" works perfectly. Good job! :)

With the "right" setting.

If the right mouse button is pressed and held from the adventure map area and the mouse cursor is moved over the minimap area and the mouse button is released, the left mouse click over the minimap area to change the minimap view is not taken into account, the right mouse click over the minimap area is correctly taken into account. You have to go back to the adventure map area and then back to the minimap area for everything to work as expected. (Same as with the "left" setting.)

The "drag scroll" can be initiated if the right mouse button is pressed and held from some parts of the interface area on the right side of the adventure map (except minimap, heroes and castles lists, command buttons area, status window on the bottom right of the screen). (Partially the same as with the "left" setting.)

https://user-images.githubusercontent.com/43583994/173229798-5d2a0fd7-983b-4f70-b9e7-89c5a874d0b2.mp4

The condition of moving the mouse cursor (for the problem of the not very precise click of the user (he clicks on a place and moves the mouse cursor slightly before releasing the mouse button)) to trigger the "drag scroll" does not seem to be applied with the "right" setting.

With the "middle" setting.

If the middle mouse button is pressed and held from the adventure map area and the mouse cursor is moved over the minimap area and the mouse button is released, the left mouse click over the minimap area to change the minimap view is not taken into account, the right mouse click over the minimap area is correctly taken into account. You have to go back to the adventure map area and then back to the minimap area for everything to work as expected. (Same as with the "left" and "right" settings.)

The "drag scroll" can be initiated if the middle mouse button is pressed and held from the interface area on the right side of the adventure map (minimap, heroes and castles lists, command buttons area, status window on the bottom right of the screen). (Same as with the "left" setting.)

The condition of moving the mouse cursor (for the problem of the not very precise click of the user (he clicks on a place and moves the mouse cursor slightly before releasing the mouse button)) to trigger the "drag scroll" does not seem to be applied with the "middle" setting.

This bug is still present:

With the "left" and "middle" settings, when the right mouse button is pressed and held, and the left (or middle, depending on the setting) mouse button is clicked, the adventure map view changes.

https://user-images.githubusercontent.com/43583994/172378361-0df4adec-cdf0-461d-91ee-83bfcf682699.mp4

This problem is back:

However, I noticed a small problem. :) When the user releases the mouse button on the right edge of the screen and moves the mouse over the area where the main interface is located (the area with the minimap, heroes and castles lists, command buttons, etc.) and tries to scroll the adventure map area by moving the mouse cursor to the edge of the screen (where the mouse cursor should then turn into an arrow before scrolling the screen) it does not work. The user must first move the mouse cursor to the adventure map display area before moving the mouse cursor to the edge of the screen to activate the arrow cursor which then scrolls the screen. The same goes for the small portion of the main interface area at the top and bottom right for scrolling up and down the screen.

In fheroes2:

https://user-images.githubusercontent.com/43583994/169756333-024d0aa8-7a94-4ae6-a990-969b2a48c975.mp4

This is not too annoying for the left, the top and the bottom of the screen (in fact I prefer this mode of operation as the user is not "surprised" by the two modes working "at the same time"), the problem comes from the right side of the screen because the user has to make a big back and forth with the mouse cursor to be able to activate again the mode of operation with the edge of the screen.

[Laserlicht]

Thank you for your support!

If the left mouse button is pressed and held from the adventure map area and the mouse cursor is moved over the minimap area and the mouse button is released, the left mouse click over the minimap area to change the minimap view is not taken into account, the right mouse click over the minimap area is correctly taken into account. You have to go back to the adventure map area and then back to the minimap area for everything to work as expected. Hmm...

I have removed the radar fix. Otherwise it will bring new problems.

I now think that we should not deal with this bug here. Since it actually has nothing to do with the drag scroll.

Theoretically the bug would be easy to fix. But the input layer of fheroes2 is there... not so good...

Currently there are the functions:

• MouseClick - One cycle active - when a click is done (mouse press and release).
• MousePress - Permanently active - when button is pressed
• MouseRelease - One cycle active - when button is released

one is missing:

• "MouseOnPress" - One cycle active - when button is pressed.

As an electrician, one would say that the rising edge is missing. 😄

But then you should rename the others too, otherwise it's not really nice. This is then a bigger change.

But with the MouseOnPress one could determine whether the button was pressed first on the radar/minimap and not already somewhere else.

The "drag scroll" can be initiated if the left mouse button is pressed and held from the interface area on the right side of the adventure map (minimap, heroes and castles lists, command buttons area, status window on the bottom right of the screen).

Same problem as with the radar. But does not really bother. I think.

If the right mouse button is pressed and held from the adventure map area and the mouse cursor is moved over the minimap area and the mouse button is released, the left mouse click over the minimap area to change the minimap view is not taken into account, the right mouse click over the minimap area is correctly taken into account. You have to go back to the adventure map area and then back to the minimap area for everything to work as expected. (Same as with the "left" setting.)

Should be gone by removing the fix.

The condition of moving the mouse cursor (for the problem of the not very precise click of the user (he clicks on a place and moves the mouse cursor slightly before releasing the mouse button)) to trigger the "drag scroll" does not seem to be applied with the "right" setting.

It should. However, as long as the quickinfo is still open. It only closes when there is a "larger" movement.

The condition of moving the mouse cursor (for the problem of the not very precise click of the user (he clicks on a place and moves the mouse cursor slightly before releasing the mouse button)) to trigger the "drag scroll" does not seem to be applied with the "middle" setting.

That's right. Didn't really make sense to me. Because you only press the middle button when you want to do the drag scroll. 😉

This bug is still present:

Is now gone.

This problem is back:

It's gone again. Could take it out again with the removal of the radar fix.

[LeHerosInconnu]

Hello @Laserlicht,

Thank you for your support!

If the left mouse button is pressed and held from the adventure map area and the mouse cursor is moved over the minimap area and the mouse button is released, the left mouse click over the minimap area to change the minimap view is not taken into account, the right mouse click over the minimap area is correctly taken into account. You have to go back to the adventure map area and then back to the minimap area for everything to work as expected. Hmm...

I have removed the radar fix. Otherwise it will bring new problems.

I now think that we should not deal with this bug here. Since it actually has nothing to do with the drag scroll.

Theoretically the bug would be easy to fix. But the input layer of fheroes2 is there... not so good...

Currently there are the functions:

• MouseClick - One cycle active - when a click is done (mouse press and release).
• MousePress - Permanently active - when button is pressed
• MouseRelease - One cycle active - when button is released

one is missing:

• "MouseOnPress" - One cycle active - when button is pressed.

As an electrician, one would say that the rising edge is missing. smile

But then you should rename the others too, otherwise it's not really nice. This is then a bigger change.

But with the MouseOnPress one could determine whether the button was pressed first on the radar/minimap and not already somewhere else.

Okay, I got it. :)

The "drag scroll" can be initiated if the left mouse button is pressed and held from the interface area on the right side of the adventure map (minimap, heroes and castles lists, command buttons area, status window on the bottom right of the screen).

Same problem as with the radar. But does not really bother. I think.

It's not too annoying because it doesn't interfere with other actions, it was just to approach "perfection" and "peace of mind". :)

If the right mouse button is pressed and held from the adventure map area and the mouse cursor is moved over the minimap area and the mouse button is released, the left mouse click over the minimap area to change the minimap view is not taken into account, the right mouse click over the minimap area is correctly taken into account. You have to go back to the adventure map area and then back to the minimap area for everything to work as expected. (Same as with the "left" setting.)

Should be gone by removing the fix.

Yes, it's gone.

The condition of moving the mouse cursor (for the problem of the not very precise click of the user (he clicks on a place and moves the mouse cursor slightly before releasing the mouse button)) to trigger the "drag scroll" does not seem to be applied with the "right" setting.

It should. However, as long as the quickinfo is still open. It only closes when there is a "larger" movement.

With the "right" setting, the right-click information window no longer works on the adventure map area.

https://user-images.githubusercontent.com/43583994/173310523-5ff3f03c-1067-42f3-995c-099cf83dbdc0.mp4

The condition of moving the mouse cursor (for the problem of the not very precise click of the user (he clicks on a place and moves the mouse cursor slightly before releasing the mouse button)) to trigger the "drag scroll" does not seem to be applied with the "middle" setting.

That's right. Didn't really make sense to me. Because you only press the middle button when you want to do the drag scroll. wink

Yes, you are right, the middle mouse button is not currently used on the adventure map (if I don't forget anything :) ), it will always be possible to complete it later if necessary.

This bug is still present:

Is now gone.

Yes, it's fixed.

This problem is back:

It's gone again. Could take it out again with the removal of the radar fix.

Okay.

[Laserlicht]

right should work again

[LeHerosInconnu]

Hello @Laserlicht,

With the "right" setting, the right-click information window no longer works on the adventure map area.

right should work again

Yes, everything works fine.

The condition of moving the mouse cursor (for the problem of the not very precise click of the user (he clicks on a place and moves the mouse cursor slightly before releasing the mouse button)) to trigger the "drag scroll" does not seem to be applied with the "right" setting.

It should. However, as long as the quickinfo is still open. It only closes when there is a "larger" movement.

Compared to the "left" setting, the "right" setting does not seem to take into account a distance covered by the mouse cursor before performing the "drag scroll" of the adventure map.

In fheroes2:

https://user-images.githubusercontent.com/43583994/174318875-75a1da53-8a63-45c2-b15a-7e0ec412eb92.mp4

[Laserlicht]

@LeHerosInconnu

Compared to the "left" setting, the "right" setting does not seem to take into account a distance covered by the mouse cursor before performing the "drag scroll" of the adventure map.

The right mouse button also has this function. However, it works a little differently. The offset is taken into account when quickinfo is open. So if you have moved at least 4 pixels, the window closes.

Of course, the 4 pixels are less than the 10 with the left mouse button. But I think that the quickinfo window then disturbs less.

https://github.com/ihhub/fheroes2/blob/2738da6f03b08ca409284f51c91b894ec5ccf3ac/src/fheroes2/dialog/dialog_quickinfo.cpp#L71

[LeHerosInconnu]

Hello @Laserlicht,

@LeHerosInconnu

Compared to the "left" setting, the "right" setting does not seem to take into account a distance covered by the mouse cursor before performing the "drag scroll" of the adventure map.

The right mouse button also has this function. However, it works a little differently. The offset is taken into account when quickinfo is open. So if you have moved at least 4 pixels, the window closes.

Of course, the 4 pixels are less than the 10 with the left mouse button. But I think that the quickinfo window then disturbs less.

https://github.com/ihhub/fheroes2/blob/2738da6f03b08ca409284f51c91b894ec5ccf3ac/src/fheroes2/dialog/dialog_quickinfo.cpp#L71

Okay then. Let's leave it like that for now and see if there is any feedback from the players.

[zenseii]

Hi @Laserlicht! What is the status of this PR? Is it ready for review?

[Laserlicht]

Hi @Laserlicht! What is the status of this PR? Is it ready for review?

Yes ready for review, I briefly set the default to the middle mouse button, since it is not used elsewhere in the game.