Constructor/destructor of TTMSFNCMapsOpenLayers

I have a TTMSFNCMap, set at design time to use the msOpenLayers Service, on a modal form. This form is created when required. After its been used, the form is disposed using FreeAnNil.

Every time that the form is created, I see that the TTMSFNCMapsOpenLayers constructor is called twice (from TTMSFNCMapsOpenLayersService.DoCreateMaps). The destructor is, however, not called when freeing the form. It is called repeatedly (twice the number of form openings) when the application is closed.

I have a problem where the destructor inherited sometimes causes an access violation on application closing. This leaves the application active in Task Manager.

I have traced the cause for this to one a particular REST operation, of the many which I call, in a totally separate modal form. Simply assigning the JSONValue property from the TCustomRESTRequest.Response to a local variable (after having opened and closed the map form) will result in the above destructor failing.

The map form and the second form appear to work perfectly when used individually.

I am at a loss as to why this might happen, and may not understand you create/destroy policy correctly. But, it appears to me that objects created when a form is created should be destroyed when it is destroyed, and not persist until application termination.

Any comments/advice would be appreciated as this is a serious problem.

Thank you


I don't see an immediate reason for the destructor to no be called. When we drop 2 instances on the form, the destructors are called for both instances. Please provide a sample or code snippet with which we can reproduce this and investigate the cause for this issue.

Hi Pieter - thanks for getting back to me.

The destructor TTMSFNCMapsOpenLayers.Destroy function is called. Its just that when it executes the single inherited line, an AV error is obtained.

I have been able to reduce the code down to the example, which crashes after clicking buttons 1 (wait for the map), 2 (wait for the response) and 3 (gets an AV).

Could you possibly see if you can identify the reason for the error? (28.4 KB)


I have not been able to reproduce an issue with the sample code you provided.

Can you please provide the following information so I can further investigate this?

  • Are you using the latest version of TMS FNC Maps?
  • Which version of Delphi are you using?
  • Which version of Edge Chromium do you have installed?
  • Can the issue be reproduced while only using the TTMSFNCMapsOpenLayers (with the REST components)?

Hi Bart

Thanks for investigating.

I have tested this, and received the same AV error when closing the program on 3 separate PCs
Tests were carried out with TMS FNC Maps V1.5.0.0, in Debug mode of Delphi 10.3 Update 2, with Edge Chrome 91.0.864.37

I'm not sure exactly what you mean in your 4th question.

I'm not sure if this is important, but I find it odd that there is any "tidying up" of FNCMap-related objects when the application is closed. I thought that since the map is only used in a dynamically-created modal form, which is freed once it has been used, all child components of that form should be released at the same time.

Is it correct that two new TTMSFNCMapsOpenLayers objects are created every single time that the FMCMap form is opened (breakpoint in VCL.TMSFNCMaps.OpenLayers line 137), and these are only destroyed when the application is closed (breakpoint in VCL.TMSFNCMaps.OpenLayers line 142)?

I have been able to recreate the problem using no REST operations at all.

The attached code dynamically creates a modal form, which contains a TTMSFNCMaps component. This form is created and destroyed a number of times (5 in my example). Then when the program is closed, an AV results.

It appears that two instances of a TTMSFNCMapsOpenLayers object are created each time that the form is created, but these objects are only destroyed when the entire program is closed. This does not sound correct. (24.8 KB)

Correction : Two of the PCs are using Delphi 10.4.2 and one is using Delphi 10.4.


We are able to reproduce this issue and will investigate this here as soon as possible.


We have applied a fix, the next version will address this. Thank you for reporting!

Thank you very much.

Do you have a proposed release date for the fix/next version. I need to get this out to my clients as soon as possible.

We are currently working on a new version so it's unclear when the next version will be available. If it is urgent, please contact us by email to request an incremental source update.