GetClosestShape Is Driving me Crazy

[dusko23]

I have been struggling for two days to find a cure for a weird problem.
I would be grateful if someone could give me a hint.

Scenario:
SFmap object named mapSAROSmain contains 80 small Shape Files.

There are two functions to serve different purposes.
The thing is that the body of each function contains GetClosestShape method call.

I iterate through all Shape Files (80 there are) calling GetClosestShape method.
Here are two calls, one per each function.

myPOINTd is mouse cursor.
myCheckDistance is equal in both functions.
mapSAROSmain has raster map drawn.

Time to complete 80 iterations:

• 53 milliseconds function 1
• 1714 milliseconds function 2

I have stripped all of the code that might cause an issue. But problem persists.

I have also find one interesting detail in function 2 (the slow one).
If mouse cursor is close enough to a shape (record actually) the time to complete single GetClosestShape is ZERO ticks.
If mouse cursor is out of myCheckDistance the time to complete single GetClosestShape vary from 0.02 seconds to 1 second.
Any hint is highly appretiated.

[dusko23]

I found a cure for the problem.
Commented code is causing a problem while the other one works like a breeze.

It appears that checking isEquivalent puts the SFmap object into a weird state and consequently method GetClosestShape takes "ages" to complete.
isEquivalent completes "immediately".

[wfletcher]

Can you add which version of the library you are using

[dusko23]

I have checked DLLs,
All are of the same version.

[wfletcher]

Please add a break point at the first line in your second screenshot and post the value of myCheckDISTANCE and the I’d of mapcoordinatereferencesystem

[dusko23]

I have upgraded my code and it works lightning fast now.
Now, here is no need to use SFmap object mapcoordinatereferencesystem in the GetClosestShape method.
The thing is that I calculate SFmap cursor EPSG to validated SHP EPSG on mouse move.
There is a list of conversions created in runtime. If a new SHP file is loaded a new conversion entry is added to a list if not there already.
First I calculate longitude distance in arc degrees.

Then I perform GetClosestShape.

This is a function to calculate myCheckDistancewgs84 in arc degrees (provided by gpt3.4)

During full-throttle testing (moving coordinates around the globe) I found a "bug" in this code.

The code transforms SFmap mouse coordinates (projected ones like OSGB 27700) to WGS84.
Coordinates Tranformation can return a poitnD where X and Y are infinite. For EPSG 2770 this happens at about Longitude = 82.99 E
On the second thought, this is not a bug but a regular value for nonsense, (Like converting EPSF = 27700 at 82.99 longitude to WGS84. I do not limit panning SFmap object outside the valid definition of projected EPSG coverage, though.

This is a function where I limit displaying coordinates on mouse move.

However, SMmap object can still be panned. Only the coordinate display is frozen.
Coordinates Display Window.