ThinkGeo.com    |     Documentation    |     Premium Support

Application locks up adding async layers to MapPrinterLayer

#1

In recent testing I noticed that if I had a WmtsAsyncLayer in the MapView and tried to switch to the Print Preview mode, the application would lock up. We have recently started using Claude ai to help in our debugging and Claude determined the cause to be a conflict between synchronous and asynchronous methods used to draw the layers. I have since determined that the problem occurs when using any of the asynchronous layers (ArcGisServerRestAsyncLayer, Core.BingMapsAsyncLayer, OpenStreetMapAsyncLayer, WmsAsyncLayer, etc). I have attached a sample project to demonstrate. The sample simply creates a page layout view and adds some shapefiles and an OpenStreetMapAsyncLayer, which causes the application to lock up. Claude generated a bug report based on observations from our main application, which I also attached in case it helps at all.

Thanks!

Steve
Sync-Async Demo Proj.zip (2.0 MB) ThinkGeo_Support_Ticket.txt (11.6 KB)

#2

Hi Steve,

This is fixed in the latest build, 15.0.0-beta095.

  1. Just update your ThinkGeo NuGet packages to 15.0.0-beta095 — no code changes are required on your side, it works as-is. You’ll only see some build warnings noting that the old PrinterLayer classes are now deprecated.

  2. You can clear those warnings by switching from the PrinterLayer classes to the new LayoutAsyncLayer classes, as the deprecation message suggests (e.g. DataGridPrinterLayer -> DataGridLayoutAsyncLayer). This does take a few code changes on your side to use the new classes and their async methods (OpenAsync / DrawAsync), but once switched everything works and the printed output is the same as before.

  3. This version also adds a new way to produce a PDF, via PdfGeoCanvas:
    a. It lives in ThinkGeo.Core (not the ThinkGeo.Printers extension), so it’s cross-platform.
    b. The exported PDF matches the on-screen preview. (The old printing route can differ slightly from the preview in a few places.)
    Both options are fully supported — feel free to use the new PDF export (#3) or stay with the existing printing route.

  4. Pull the latest “How Do I” sample and open the “Print or Export the Map to PDF” demo — you’ll see two buttons: “Export to PDF” (new, using PdfGeoCanvas) and “Print Map” (the existing route via the ThinkGeo.Printers extension). Here is the source and below is the screenshot

image
image2142×1431 507 KB

Thanks,
Ben

#3

Ben,

Thanks for the quick response. Is there any way to get this into a pre 15.0 build (14.5.4?)? We are getting close to our release date and don’t want to touch any code unless absolutely necessary.

Thanks for your help!

Steve

#4

Steve,

Yes, we can add the bug fix (without any api changes) to 14.5.4 which will be released by the end of this month.

Thanks,
Ben

#5

Hi Ben,

My previous response was before I actually tested my sample app and it still does not work, still locks up. I did have to upgrade the ProjectionConverter to the GdalProjectionConverter, but the sample project locks up with the following error message:

Managed Debugging Assistant 'FatalExecutionEngineError' Message=Managed Debugging Assistant 'FatalExecutionEngineError' : 'The runtime has encountered a fatal error. The address of the error was at 0x736e4e37, on thread 0x44c0. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.'

Can you help me out with this?

Thanks!

Steve

#6

Hi Steve,

It was reproduced and it’s fixed in 15.0.0-beta098.

This was separate from the earlier deadlock: switching to GdalProjectionConverter (the standard ProjectionConverter only reprojects vector data, not raster tiles) exposed a bug in its native interop that corrupts memory in 32-bit processes, which is exactly the 0xc0000005 error you saw.

The fix will also be in 14.5.4 at the end of the month.

Thanks,
Ben