Problem with Tracking layer in Print Preview

[Steven1]

Hi,

I am having a problem as I convert from TG10 to TG14. In our Page Layout (Print Preview) map I am using the Tracking Layer to draw geometrical shapes and arrows that become part of the map. This is working as expected in our current application, but after the upgrade the tracking shapes draw behind the printer layers in the PrinterInteractiveOverlay. I wanted to send a sample project to demonstrate this issue, but I am unable to reproduce this in a sample. Do you have any idea about what might be causing this? I think it must be a setting I don’t know about. The screenshot shows what I’m talking about.

Thanks!

Steve

[Ben]

Hi Steve,

I was able to reproduce the same behavior when a tracking overlay is added through InteractiveOverlays, instead of being assigned through the TrackOverlay property. If that matches your implementation, could you try setting it through mapView.TrackOverlay rather than adding it as a generic interactive overlay?

  // Do this
  var customTrackOverlay = new CustomTrackInteractiveOverlay();
  mapView.TrackOverlay = customTrackOverlay;

  // Instead of this
  mapView.InteractiveOverlays.Add("trackOverlay",  customTrackOverlay);

MapView.TrackOverlay is the reserved tracking slot, while a custom overlay added through InteractiveOverlays.Add(…) is treated as a normal interactive overlay, which may end up below PrinterInteractiveOverlay depending on how and when it is added.

Also, PrinterInteractiveOverlay now (v14.5) handles more interactions than before. In the print preview, you can drag and resize printer layers, and you can also pan and zoom the map inside the preview. If another interactive overlay is placed above it, that overlay may capture the mouse events first, which can prevent the printer overlay from handling those interactions properly. I just wanted to mention that in case it affects your workflow.

Here are a couple of screenshots showing the current print preview interactions, including dragging/resizing a map layer and panning/zooming the map with the Ctrl key held down:

BTW: v14.5 was released yesterday. I would recommend everyone upgrade to it if possible. Here is some info about it:

1. The changelog: Changelog - ThinkGeo Docs
2. A Utility to generate API changelog between any 2 versions: ThinkGeo API Compare Tool — ThinkGeo, GIS Mapping Made Easy
3. An MCP server to let your AI agent better help you with ThinkGeo projects: ThinkGeo MCP Server — ThinkGeo, GIS Mapping Made Easy
4. Some in-depth guides for the users, here is one example: ThinkGeo Core Architecture Guide - ThinkGeo Docs

Thanks,
Ben

[Steven1]

Hi Ben,

Thanks for suggestion and thanks for the heads up about the 14.5 release.

Unfortunately I am already setting up my CustomTrackingInteractiveOverlay as you suggest and I am not adding it to the InteractiveOverlays. And that is also how we do it in our application. That’s why I can’t figure out why everything works OK in my sample project but not in the actual application. I do appreciate the time you’ve spent looking into it for me. If you can think of anything else that might be causing this issue, please let me know.

Cheers!

Steve

[Ben]

Hi Steve,

Thanks for letting me know! I think I found the key reasonand fixed it in the latest beta. Please pull v15.0.0-beta002 and have another try.

Thanks,
Ben

[Steven1]

Hi Ben,

Thanks for the update. Do you know why I am unable to reproduce the problem in my sample project? Is there any kind of workaround we could use in our application until the fix becomes available in a production release?

Thanks!

Steve

[Ben]

Hi Steve,

The following code is a bit ugly, but it should work.

System.Windows.Controls.Panel.SetZIndex(Map.EditOverlay, 630);
System.Windows.Controls.Panel.SetZIndex(Map.TrackOverlay, 620);
System.Windows.Controls.Panel.SetZIndex(Map.ExtentOverlay, 610);

These overlays (along with PrinterInteractiveOverlay) were sharing the same Z-index. Since initialization order can vary between projects, one overlay may end up covering another inconsistently.

Explicitly setting the Z-index ensures a consistent rendering order.

Let me know if it doesn’t work.

Thanks,
Ben

[Steven1]

Works!

Thanks!

Steve

[Ben]

That’s Awesome!