I recently had a thread titled “Relative movement between layers when zooming”, but my early investigation left me misinterpreting what I was seeing so much so that I closed the thread and started over.
The gist of the problem was, after certain events occurred, many of our map objects mysteriously moved relative to all other objects. The part that left me confused for a while is that we style a lot of our “Point Objects” (in both Shape File Layer and In Memory Feature Layer) to use symbol fonts. And a lot of these font symbols look a lot like simple circle symbols. Anyway, in spite of the similarity of some font symbols looking like circles making it unclear that what was happening, I eventually realized that only the font styled points were moving relative to all others.
But to further complicate things, it presented on only one map of many, and only after a very limited (once I understood it) set of our own core procedures had run. Ultimately I traced it to our use (and reconfiguration) of StringFormat.GenericDefault. This is persistent property in by the BCL that provides a centralized point for sharing string settings throughout a process. Once our code ran that needed/initialized(modified) this property, the font points in the map were adopting these changes. But since your map control has it’s own coordinate based location and rendering settings, it should NOT be using StringFormat.GenericDefault to render those font points. For consistency, your code should be creating a configuring it’s own StringFormat instance without regard for StringFormat.GenericDefault.
I still have not figured out why it manifested only on that one map, but I suspect it has to do with very high resolution shape files using units that appear to be in inches. This does not present a problem for our application as we use a customer configured scale adjustment to make sure measurements are accurate, but the coordinate values tend to have much larger relative values than our other maps, and that may be somehow providing a multiplier to the effect observed.
This burned quite a bit of time sorting it out. Please pass this along to your developers and ask them to correct this as soon as possible. In the meantime, I have modified our code to avoid use of StringFormat.GenericDefault so as not to cause issues for the current ThinkGeo map implementation.
As always, thank you for your help, and I apologize for my earlier misrepresentation of the situation.
Problems with offset point styles using Fonts
Even after removing our dependency that was triggering the offset, we are still seeing it happen with font styled points when we swap out styles based on user selected (interactive) configurations. So something is still causing font styled points to jump around on the map. Please submit to your dev team, hopefully my earlier suggestions provide a universal fix that address all these issues with font styled points.
On a side note, if I watch carefully I can note that this also affects labels, so it would seem to be a generalized problem with the way you render fonts. Also note, this is a change from V8 to V9. None of the indicated problem behavior occurs on V8.
Hi Russ,
Thanks for let us know that, I will let our developer knows this problem and update if I get any news.
Regards,
Don
Please apply whatever pressure you can to get this resolved. Updating your product has been a very difficult process for us, and this appears to be the final ship-blocker for our map rewrite update. As far as I can see, there is nothing I can do about this final font rendered point offset issue, and we simply cannot release our now late product while it remains.
Hi Russ,
Please try the attached map suite core dll to have a test(please do a backup on the old dll before the replacing). This dll is a temporary modified version that we are guessing where the issue might be based on your description. If it does fix your issue, then we will consider to apply to the official release packages. But if still not, then I think we have to find a way to recreate your issue at first.
Besides, you mentioned the v8 is correct, could you please let us know the version detail?
Thanks,
Troy
It looks like this won’t work as an isolated DLL replacement.
For one thing, I can’t just drop it in to the build output because it fails (as expected) due to strong naming.
But I also can’t even rebuild to redeploy because apparently there is no virtual DrawCore to overload from TrackInteractiveOverlay in this updated version.
And I can’t even tell what version the new assembly is because the file detail just shows 9.0.0.0, as does the assembly metadata.
Our current installed map library version (for our latest failed attempt at an RC) is 9.0.0.66.
I believe that the previous version that we had to update because of repeated OOM Exceptions within your Refresh method was version 8.0.0.211. On this build we never detected or received a Beta site report on font styled point movement.
Hi Russ,
This version is a special test version, if you need a strong named version, we will build for you tomorrow.
And could you please upload a video (You can capture screen by Jing) to shows what’s the issue? We cannot reproduce that, it’s very hard to solve it.
Regards,
Don
Even without the strong name issues, that DLL will not work when dropped into the version we use. But yes, the best/easiest way is a strong named complete set that does not change the public interface with more breaking changes (like the DrawCore change).
As for the problem, as my initial post explains, you should search for and remove all references to StringFormat.GenericDefault. It’s not intended to be used for something like font symbols used to depict points at specific locations on maps. It’s for common shared format/layout for things like buttons, combos, etc. Some of the custom controls in our code were using it as intended, and it then directly affected your map components drawing of points, which should not have happened. My initial fix was simply to divorce our code from that shared formatting, which really wasn’t hard to do, and that fixed the known reproducible problem.
We’ve had a couple of reports since I made that change, however, I/we have not been able to verify the subsequent repro at all at this point. I’ve begun to suspect that something happened to cause the site in question to revert to the previous version (without my work-around) but that was corrected before I got a chance to look at it. The description was remarkably like the initial repro, so at this point I no longer believe that there is an additional problem.
If you can’t use what I described, I can probably get authorization to provide a repro of the initial problem described. But it only shows up on the map with the super high resolution shape files (the original units appear to actually be inches rather than feet), so to avoid spending a lot of additional time trying to get other shape files that will provide the repro, I’ll have to submit it privately with a sample of that map static data. But it will still likely be an involved task to provide a repro. Given that we have a work-around on our side, it may take a while to get time to put it together.
Hi Russ,
Please don’t worry about the detail version, our special version is all for 9.0.0.0.
Attached is the strong named special version Full Edition MapSuiteCore.dll.
Regards,
Don
Again, it seems your integrated build is going to be important. When I drop this one MapSuiteCore.dll into our build output, replacing the one from our release version, I get the following “method not found” exception when trying to run.
Method not found: ‘ThinkGeo.MapSuite.Core.GeoColor ThinkGeo.MapSuite.Core.GeoColor.FromArgb(Int32, Int32, Int32, Int32)’.
at ThinkGeo.MapSuite.DesktopEdition.TrackInteractiveOverlay.CRQ=()
at ThinkGeo.MapSuite.DesktopEdition.TrackInteractiveOverlay…ctor()
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap…ctor()
at Toro.Client.Shared.Map.Core.StaticMap.InitializeComponent() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\Core\StaticMap.Designer.cs:line 33
at Toro.Client.Shared.Map.Core.StaticMap…ctor() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\Core\StaticMap.cs:line 43
at Toro.Client.Shared.Map.Core.LynxMap…ctor() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\Core\LynxMap.cs:line 36
at Toro.Client.Shared.Map.LynxMapControl.InitializeComponent() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\LynxMapControl.Designer.cs:line 74
at Toro.Client.Shared.Map.LynxMapControl…ctor() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\LynxMapControl.cs:line 39
at Toro.Client.Shared.Map.LynxMapControl.get_Instance() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\LynxMapControl.cs:line 82
at Toro.Client.Shared.Map.MapInterface.get_Control() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\MapInterface.cs:line 58
at Toro.Client.WorkspacePane.ShowEmbeddedMap() in d:\Toro\Archer\Solution\Client\ClientHost\SecondaryPanes\WorkspacePane.cs:line 255
at Toro.Client.WorkspacePane.OnLoad(EventArgs e) in d:\Toro\Archer\Solution\Client\ClientHost\SecondaryPanes\WorkspacePane.cs:line 48
at System.Windows.Forms.UserControl.OnCreateControl()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Form.WmShowWindow(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
You guys really shouldn’t be making breaking changes in public library public interfaces in minor version updates. And certainly not without a clear description of breaking changes. You pretty much expect such things in major version update, but again, only with a list of breaking changes and clear instructions how to fix those breaks.
Looks like this time you changed GeoColor from a struct to a class. This is a huge semantic difference, and breaks our serialization code.
Not hard to fix, but once I fixed that and got it to build, I then get this missing method exception. This is an internal discrepancy between your core DLLs, not something I can work around in our code.
Method not found: ‘ThinkGeo.MapSuite.Core.GeoColor ThinkGeo.MapSuite.Core.GeoColor.FromArgb(Int32, Int32, Int32, Int32)’.
at ThinkGeo.MapSuite.DesktopEdition.TrackInteractiveOverlay.CRQ=()
at ThinkGeo.MapSuite.DesktopEdition.TrackInteractiveOverlay…ctor()
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap…ctor()
at Toro.Client.Shared.Map.Core.StaticMap.InitializeComponent() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\Core\StaticMap.Designer.cs:line 33
at Toro.Client.Shared.Map.Core.StaticMap…ctor() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\Core\StaticMap.cs:line 43
at Toro.Client.Shared.Map.Core.LynxMap…ctor() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\Core\LynxMap.cs:line 36
at Toro.Client.Shared.Map.LynxMapControl.InitializeComponent() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\LynxMapControl.Designer.cs:line 74
at Toro.Client.Shared.Map.LynxMapControl…ctor() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\LynxMapControl.cs:line 39
at Toro.Client.Shared.Map.LynxMapControl.get_Instance() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\LynxMapControl.cs:line 82
at Toro.Client.Shared.Map.MapInterface.get_Control() in d:\Toro\Archer\Solution\Client\Shared\SharedMapPanel\MapInterface.cs:line 58
at Toro.Client.WorkspacePane.ShowEmbeddedMap() in d:\Toro\Archer\Solution\Client\ClientHost\SecondaryPanes\WorkspacePane.cs:line 255
at Toro.Client.WorkspacePane.OnLoad(EventArgs e) in d:\Toro\Archer\Solution\Client\ClientHost\SecondaryPanes\WorkspacePane.cs:line 48
at System.Windows.Forms.UserControl.OnCreateControl()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Form.WmShowWindow(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
It’s not a video, but here is a clip of a screen capture showing the problem on our customer’s computer. Note that there are black dots and blue/green dots. The black dots are actually font styled points in a static layer. The colored dots are actually (simple) circle styled points in an IMFL. The image “NotOffset” shows how things should look, and how they do look before we trigger the font layout offset repro. The image “OffsetFont” shows how it looks afterward. Note that the numbers are actualy shape files, not drawn text or labels of any sort. And that the Simple Circle styled points are still at the same location relative to those numbers. But the black dot font styled points jumped vertically upward out of position. It’s not shown on this image, but the same thing happens with relative offsets of font styled points in IMFL. Its your rendering layout of font styled points that is the problem, not the specific type of layer. None of our other features, shape or otherwise move relative to other shapes, it’s just the font styled points. Which all makes sense with the information I gave you in the first post.
Hi Russ,
I am sorry that’s my fault, I hadn’t thought about this issue so the dll is built based on our development branch, I will built another release version to you later.
Regards,
Don