News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

r6801 Minimap: right mouse button drag doesn't scroll view position

Started by z9999+, October 12, 2013, 11:26:10 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

z9999+

r6801 nightly GDI Windows

On minimap window, view position doesn't scroll during dragging with right mouse button pressed.
It will jump to the new position when right mouse button is released.

Dwachs

Could not reproduce this with r6806 and linux with SDL. Maybe this is system dependent?
Parsley, sage, rosemary, and maggikraut.

z9999+

Yes. Windows SDL version doesn't have this problem.
It's only GDI version.

z9999+

r6791 works
r6797 doesn't work

So, I think this is caused by new siminteraction code in r6794.

Markohs

I'll have it a look,  didin't had time to do it this weekend

Markohs

Coudn't reproduce this, z9999+, I'm using the r6801 gdi build on nightly pages, it scrolls here, and moves. Can you explain me better how to reproduce it?


z9999+

I don't know why you cannot reproduce it.
I tested on both Windows 8 PC and Windows XP SP3 PC.

Sarlock

I get the same result with the GDI version (6801 & 6813).  It doesn't happen with the SDL or regular versions.

When you scroll the map with the right mouse button, the mouse pointer disappears and it doesn't do anything until you release the mouse button, then the map moves to the new location.

Using Windows 7.  pak128 and pak64.
Current projects: Pak128 Trees, blender graphics

Markohs

I'm quite sure it's me  misunderstanding your explanation, when you mean "scroll the map" you mean the world or the mini-map

Testing again, to see if I can see what you mean.

Markohs

Okay, dowloaded sdl 6791 and now I know what you mean. It's a bug, yes, I'll fix it, thank you and excuse me for the misunderstanding. :)

On my computer 6801 SDL version has the bug too, that's what got me confused.

EDIT: I see, while dragging the mouse the system generates continually EVENT_DRAG events, so the routine keeps processing them until the mouse is released, let's see how can I fix it

Markohs

I think I know where does the bug come from, but I'm not really sure on how to fix it.

map_frane.cc, line:458:


      scrolly.set_scroll_position(  max(0, x),  max(0, y) );
...
      // Hajo: re-center mouse pointer
      display_move_pointer(screenpos.x+ev->cx, screenpos.y+ev->cy);
      return true;


The thing is display_move_pointer ends creating ANOTHER WM_MOUSEMOVE event in simsys_w.cc, that will lead us to the same point, creating in fact a infinite message loop, until we release the right mouse button. Avoiding the mouse re-centering is not a viable option.

What I don't understand is *why* the SDL doesn't suffer from the same problem, according to http://sdl.beuc.net/sdl.wiki/SDL_WarpMouse, it will end creating a SDL_MouseMotionEvent, but it fact, looks like it doesn't.

Well, if anyone has any idea, just tell me, I'll investigate more tomorrow.

Dwachs

Why is the mouse pointer moved explicitly by this method? Just asking, cannot test.
Parsley, sage, rosemary, and maggikraut.

Markohs

while dragging, the cursor is hidden and when we get a mouse movement we measure the distance of the cursor from the original click location, to generate the drag event. The mouse is then moved to the original click notation, so the mouse doesn't end outside our window area while dragging,  or we'd lose focus.

This is specific to gdi as you said, sdl manages this ok.

prissi

This does originate from the merging of event ... so maybe leave the merging off again for now. Or have it off for GDI be #defines?

Markohs

Well, solved this @6814 .

Nah, it was not from the merging of events, that's not been implemented yet, and I don't think I will implement it, it's not worth it, I think, too much complication for little earnings.

The issue was unconditionally moving the mouse pointer back to starting location on drag. SDL seems to detect when you ask to move the mouse pointer to the same position it is already and ignores the order (SDL likes to ignore us often, looks like :) ), GDI generates the event again, even if the mouse did not efectively move, so:


      // Hajo: re-center mouse pointer
      display_move_pointer(screenpos.x+ev->cx, screenpos.y+ev->cy);
      return true;


Turns:



      // Move the mouse pointer back to starting location
      // To prevent a infinite mouse event loop, we just do it when needed.
      if ((ev->mx - ev->cx)!=0  ||  (ev->my-ev->cy)!=0) {
         display_move_pointer(screenpos.x + ev->cx, screenpos.y+ev->cy);
      }


I'm not very happy with this solution, because a GUI class should not care of this system intrinsic issues, we should solve the dragging mechanism elsewere, on siminteraction, simevent, simsys or simgraph, but not here. But I'll just be like it's now, or I can enter another of my refactoring frenzies, and who knows where I'll stop refactoring. So this stays as I did imho. ;)

It might cause a bug on BeOS, since I see on siminteraction.cc this is solver differently:


      // move the mouse pointer back to starting location => infinite mouse movement
      if ((ev.mx - ev.cx)!=0  ||  (ev.my-ev.cy)!=0) {
#ifdef __BEOS__
         change_drag_start(ev.mx - ev.cx, ev.my - ev.cy);
#else
         display_move_pointer(ev.cx, ev.cy);
#endif
      }


But since I can't really test on that OS, I'll just figure I didn't read that. ;)

Tested on W32 GDI and SDL, both work, and should work on rest of backends.