|     Documentation    |     Premium Support

Upgrade from v10.3 to v12.2 Issues

We have found the following issues upgrading our WPF desktop app from v10.3 to v12.2:

Resizing the window when periodically refreshing a map can cause the shapes to be “squashed”. This primarily happens when making the window shorter or more narrow. When this issue happens if we try to pan the map it behaves as if a pinch zoom on a mobile device is occurring. Sometimes the issue will correct itself, but zooming the map always returns the shapes to their normal appearance. I have included 2 sample projects to demonstrate the v10.3 behavior vs the v12.2 behavior. Note that I did try the 13.0 beta with the same results as v12.2. There are 2 screenshots in the v12.2 project that show the normal appearance (ResizingNormal.png) and the “squashed” appearance (ResizingError.png). Simply build and run the solutions, click the Start button in the upper left corner and then resize the window. The sample projects are:
ThinkGeoPerformanceApp - v10.3 -
ThinkGeoPerformanceApp - v12.2 -

The label text size is visibly smaller in v12.2 vs v10.3 when using the exact same font configuration. I have included 2 sample projects to demonstrate this issue. The sample projects are:
ThinkGeoPerformance - v10.3 - LabelLocation and
ThinkGeoPerformance - v12.2 - LabelLocation and

The label locations appear to be mirror opposites for point features vs shape features in v12.2. For example, if I set the label location to be Lower the point feature label displays below the feature, but the label is displayed above the shape feature. This occurs for all label locations. This issue is demonstrated in the same sample projects as the label text size. I have included the exact code we use for displaying feature labels in the sample projects. See, MainWindow.xaml.cs - MyBaseFeature.SetLabelStyle(). We use this same style for all of our different feature-types. I also tried the v13.0 beta with the same results as v12.2.

The sample projects were created using v10.3 and then upgraded to v12.2. The v12.2 projects are x86 using .Net 4.8.

ThinkGeoPerformance - v10.3 - LabelLocation and (43.0 KB) ThinkGeoPerformance - v12.2 - LabelLocation and (42.1 KB) ThinkGeoPerformanceApp - v10.3 - (47.3 KB) ThinkGeoPerformanceApp - v12.2 - (150.9 KB)

Some more environment information:

The v10.3 projects were created on Windows Server 2012 Standard and Visual Studio 2015 Update 3.

The v10.3 projects were upgraded to v12.2 on Windows Server 2016 Standard Version 1607 and Visual Studio 2019 Version 16.5.0.

Both of these environments are virtual machines running on Windows 10 Version 1909 using a 4K monitor.

Thanks Rick,
We have fixed these issues. Could you try with the latest beta wpf version which is 13.0.0-beta169.



Thanks for the update!

The text size seems to be correct now.

The label location for a shape feature is still not showing up in the correct location - as returned by MapUtil.ToScreenCoordinate(). It looks like an assumption is being made that the minimum Y screen coordinate for the MapView is 0 which it is not - it should be the control’s relative offset from the Window’s 0,0 origin. It looks like the X screen coordinate handles this situation properly. I have attached the same “LabelLocation and TextSize” project upgraded to 13.0-beta171. I changed the pentagon to a rectangle to make it easier to “view” the center point of the feature. I am also writing the rectangle’s screen coordinate bounding box and center point to the Visual Studio Output tab (via Console.WriteLine()). The output message looks like this:

***** Rectangle bounding box in SC - MinX: 856 MaxY: 413 MaxX: 1050 MinY: 316 Center Point - X: 953 Y: 364

I added the screen coordinates of the mouse pointer to the bottom of the WpfView. I also added a black border around the MapView. Change the label location from Lower to Center and then position the mouse pointer on the upper left or lower right corner of the rectangle. You will see that the Y screen coordinate is off by about 31 “pixels” when compared to the output in the Visual Studio Output tab. You can verify this by putting the mouse pointer in the upper left corner of the MapView (the Y coordinate should be about 31).

The resizing is definitely better. I still see the squished shapes but it corrects itself on the next overlay refresh. This is fine if we are periodically “blinking” features by changing their opacity and the WpfView size changes. The map is also refreshed if the state of a feature changes. This can occur with or without the periodic feature “blinking”. So, the map can sit statically showing the current feature status with no periodic refreshing. If a feature happens to change state at the same time the WpfView is being resized then the map can be “stuck” in this squished state - at least until the next Refresh(). There are 3 things potentially happening at the same time here - our application is calling Refresh() on an overlay, the WpfView size is changing and the ThinkGeo is updating the WpfView with the new map state image. When we are “blinking” features we are calling Refresh on our feature overlay every 750ms. Could it be that there needs to be some coordination of these 3 actions to ensure they do not “step over each other” or overlap? For example, our application should not call Refresh() on an overlay if that overlay is already in the process of being refreshed? Same thing with WpfView size changing?

A general Refresh() question - Does calling Refresh() for an overlay(s) or the MapView block the caller until the MapView is updated with the new image?

ThinkGeoPerformance - v13.0 - LabelLocation and (42.4 KB)

Thanks Rick,

  1. For the font size. I talked with the developer team. In the mapsuite 12 we use a different standard. So it looks smaller than before. I have to rollback the changes.

  2. I have fixed this issue.You can get the latest V12 beta nugget package and try again. Now it is consistent with the V10. So we need adjust the sample code in V12 to consistent with the V10. I attached you code.
    ThinkGeoPerformance - v13.0 - LabelLocation and (40.8 KB)

  3. For the refresh process. We are using dispatcher.Invoke to do the refresh/redraw. It is safe cross threading calling.