What causes the MapPoint Control to stop scrolling?

It's been a while since my last MapPoint programming, so please bear with me. Using MP 2006 just now.

Probably something well known and obvious, but I couldn't find an answer to my issue searching these forums and the rest of the web.

I created a simple form and tacked a MapPoint control on it.
(my first steps, obviously...)
It essentially works fine, but every now and then, scrolling will just come to a halt even when I keep the mouse key pressed.
(The MouseUp event doesn't fire)
The problem gets worse the more I zoom in, and if I'm on city level scrolling will usually just make a tiny bump before it stops, forcing me to reinitiate scrolling by releasing the mousekey and pressing again, at which point it will again make a little movement and come to another halt ... etc.
What causes this issue? Any obvious way around this?
I figure I could disable "official" behavior and code my own movement handling, but I wonder if that issue shouldn't be easy to fix, somehow...
Any ideas?

Thanks in advance
MarcoK

Interesting; good question. I'm going to take a wild guess and say it is a cross
between allocation of memory and window/mouse messages interfering with
each other. Notice what happens without the mouse:
MapPoint Spinning Globe Sample (http://msdn2.microsoft.com/en-us/library/ms980058.aspx)

Mike Mattys

Hi,

I agree with Mike. However as far as I recall, the windows message queue has room for 10240 messages. I don't know how many messages are posted per second when pressing and holding the mouse button down (hmm interesting to know however).

What is CPU load at that moment and eventually other programs running ?

That Spinning Globe example fails to run in VS.NET 2005.
I'll try to implement my own keyboard based scrolling and I expect it to run, but that wouldn't really solve the issue.

As for CPU load, it's pretty high, between 95% and 100%, most of the time the latter.

However, upon experimenting at maximum zoomout I noticed some weird patterns.
For example, the control will NEVER (thied ample times) hang when I stay far north so that basically the pole is rotated and I always have a lot of land on screen.
However, the control will ALWAYS hang when running into the pacific and atlantic if I try to focus on the southern hemisphere.
I can usually scroll across South America or Africa in one go (not always though), but then it'll hang again when faced with the next ocean.

No such "luck" when being zoomed in, though. Then the hangs seem pretty random and happen at a very annoying pace everywhere.

Edit: Is there a way to tell which arrow pointer the control is displaying? I tried with "MousePointer", but it always returns the default one, so is not a big help.

_______
MarcoK

Hi,

I did a test, and yes I see exactly same problem. With the control, but also with the the standalone executable. MP2006 but did try also MP2004 and it has same problem. Problem is probably due to detail. Above the see their is no detail, same count for Africa. Probably same problem in east Europe (did not try). That is also the reason that the problem persist when zoomed in.

Hi,

About the mouse pointer. Yes you pick right property but it will probably not work when you are on the borders of the map.

However there are always workarounds. If you put on the borders 8 transparent panels, then you can display the pointer of your choice when mouse is hoovered over these panels.

Well, if details (or lack thereof) were the problem, the control shouldn't hang at all when zoomed in and there's lots and lots of stuff to display.
In fact it's actually worse when zoomed in, though...

Also, could you please elaborate a bit on the MousePointer issue?
If I picked the right property, how do I tell which arrow it is displaying if all I ever get as a return value is "Default"?

Edit: Oh, and about transparent panels, I guess it would be hard to make them match the arrow displayed at all times, so I would prefer checking the cursor instead.
Or do you mean putting them beyond the control's borders to ensure scrolling still occurs when the user has lost the control boundaries?

Thanks for taking the time to reply.
______
MarcoK

Hi,

In fact it's actually worse when zoomed in, though

Yes. But the lack of details is my only logical explanation for it...

If I picked the right property, how do I tell which arrow it is displaying if all I ever get as a return value is "Default"?

well I think that the cursor in the corners (so for scrolling) cannot change.

about transparent panels, I guess it would be hard to make them match the arrow displayed at all times

No. Each window (form, panel, whatever) can you give a cursor for its own (it's a property).

Or do you mean putting them beyond the control's borders to ensure scrolling still occurs when the user has lost the control boundaries?

No I mean "On" top of the map, all aligned to the borders of the map that so if user resize map they stay on correct position. As soon as the mouse hoover over the panel, cursor will change to your selected one for each of the panels.

Doesn't the fact that it doesn't actually happen that way when zoomed in make the theory less logical, though? :bluewink:

About the mouse cursor issue ... I'm afraid I somehow don't get what you mean. At least not completely.
As it is now (unmodified), the control changes the mouse cursor to various arrows depending on where the mouse is located and whether or not the mouse is being clicked.
If I overlay the control with transparent panels with custom cursors onmouseover, I take it that would override the default behavior, but wouldn't that also basically FORCE me to write a completely custom handling?
I realize I might have to do this eventually, but I'd prefer if I could keep out-of-the-box behavior intact as much as possible.

What I was inquiring about was: How do I determine which cursor is currently displayed? The cursors ARE changing already, my preferred workaround would thus be to simply check which cursor is displayed and act accordingly.

Naturally, I guess transparent panels would work, but it would involve a lot more custom handling to imitate behavior the control already includes.
______
MarcoK

Hi,

MousePointer property seems not to change when the bitmap changes to the Pan arrow. As for the custom code it is not too hard. Only some code to change mousepointer depending where it is on the panel, and on mouse key down creation of a timer that excutes a Pan method every few milliseconds. Destroy timer in onMouseUp.

MousePointer property seems not to change when the bitmap changes to the Pan arrow. As for the custom code it is not too hard. Only some code to change mousepointer depending where it is on the panel, and on mouse key down creation of a timer that excutes a Pan method every few milliseconds. Destroy timer in onMouseUp.

I managed to detect the cursor changed by using API hooking.
However, properly reacting isn't exactly easy, either.
It's similar to an entirely custom handling like the one you describe.
Sure, I can do that. However, the actual behavior of the control is much more complex. The map moves faster the closer I draw to the edges.
And slower again if I move back to the center.
I can actually "fly" across the map by just keeping the mousekey down and moving the cursor around.
Replicating this isn't as trivial as making a simple pan.

Which is why I was hoping to resolve the stuttering in the control itself, but appearently, it's not possible.
At least nobody here seems to know how to pull it off. :sad:
______
MarcoK

Hi,

You have to make code that calculate where you are. For example if you go near top or bottom on the left or right you have to change already from eg E to NE (and same for the others. Using a transparant panel it is very easy. So you also could change the incrementing of the pan in 2 or 3 steps.

Well, like I wrote, it IS possible, just not really THAT simple.
As you appearently have done this before ... any idea how I can pass a mouseclick event through to the control?
Or, alternatively, how I can disable the stock arrows (so they don't appear under any cicrumstances)?

Thanks for your help.
______
MarcoK

Hi,

I think I not made it clear, sorry for that. I try again :)

As soon as you have dropped a (transparant) panel (4 of them, top, left, bottom, right) on the control (and anchored it), then from the moment the mouse hoover over it the Mappoint control will not receive OnMouseMove messages. Because it is not received the cursor is not changing, but the default cursor of the panel will display. This means that the arrows will never display and you can do your own arrows and also handling of the pan.

You panels will now receive all the mouse events, not MP control anymore. So you give each panel 3 cursors (eventually a copy of the original captured with a print_screen and put in a bitmap. In OnMouseMove of the panel you check where the pointer is and display the right cursor.

In OnMouseDown you start pan the map, but not with passing mouse events trough it, but using the Pan method and a Timer. Direction of the pan is depending the mouse position, eventually the increment also.

In OnMouseUp you disable the timer.

Is this more make sense ?

Heh, no worries Wilfried, I DID understand it like that and have already implemented the foundation of this behavior, down to the timer. :yellowsmile:
I actually used a single custom transparent panel (a standard panel with bgcolor set to transparent didn't work, it wouldn't actually be transparent for some reason) and changed the mouse cursor depending on the position. Works like a charm. I still have to implement some of the advanced stuff (moving faster when closer to the edge etc.), but it already works in a basic fashion.

My question was aimed at the fact that I wouldn't like to replicate all the rest of MapPoints behavior, nor would I want to entirely forsake it.
I found that you can disable the stock arrows by setting AllowEdgePan to false.
This allowed me to have another "mode" in the map for dragging the map along with a hand-cursor - in this case the MP control never "hangs".
For this purpose I just remove the panel from the container, reAdding it when I go into arrow-mode again.

Now the only thing I dislike is that, for some odd reason, disabling AllowEdgePan also disabled the ability to draw rectangles for zooming into them. But maybe there's another property controlling this I have overlooked so far.

Other than that, my map basically now works as I intended.
I still feel it would've been much easier and better if the control didn't cause this stuttering in the first place (shame on you Microsoft), but I'll get along with what I have.

Thanks for your help and input. :yellowsmile:
_______
MarcoK

Hi,

Just tryed to disable AllowEdgePan. But I have still the ability to draw rectangles for zooming into them. So something else must wrong. I don't know what but a combination of properties maybe ? Try to experiment a little with it. I disabled it after opening a map.