FPiette

In which space are your points? The formula and code I gave is for computing the distance between two points of given by their geographic coordinates (On a sphere which is the earth in my code). The distance is computed on a great-circle. The formula for two points located on a plane is different and simpler.

What is the relation with your initial question and my answer ?

If you are talking about geographic coordinates, look at the haversine formula. function HaversineDist( Lat1 : Extended; // Latitude of point 1 in degrees Lng1 : Extended; // Longitude of point 1 in degrees Lat2 : Extended; // Latitude of point 2 in degrees Lng2 : Extended) // Longitude of point 2 in degrees : Extended; // Distance in meters var Dx, Dy, Dz : Extended; const Diameter = 2 * 6372.8 * 1000; // Meters begin Lng1 := DegToRad(Lng1 - Lng2); Lat1 := DegToRad(Lat1); Lat2 := DegToRad(Lat2); Dz := Sin(Lat1) - Sin(Lat2); Dx := Cos(Lng1) * Cos(Lat1) - Cos(Lat2); Dy := Sin(Lng1) * Cos(Lat1); Result := ArcSin(Sqrt(sqr(Dx) + Sqr(Dy) + Sqr(Dz)) / 2) * Diameter; end;

Works now.

Still down for me.

It is enough to store the request count per 5 sec interval. The other intervals can be computed form the 5 sec interval. To count for the 5 sec interval, you can increment a counter (in memory or in SQL table), rounding the timestamp to the nearest 5 sec and using that rounded value plus the user ID to locate the record to update (or insert if not already existent). At regular interval, you can delete all counters older than the desired retention time. For performance reason, you may buffer the counter in memory for one or more 5 sec intervals and then flush the memory to the database to secure the data. With that scheme; you have at most 12 * 60 * 24 = 17280 counter per day per active user. 2 bytes (short int) is enough if no use has more than 65535 requests per day. If they can do more, then you need more bytes per counter.

Look at this report : https://quality.embarcadero.com/browse/RSP-33766 This is probably a similar issue. You should create a new report with the issue you see.

Yes, it should. I always code like that and when taking code from elsewhere, I rewrite it like that.

I like to use FreeAndNil for the same reason David explained for the rest : One day you make your procedure more complex, adding some code lines after the FreeAndNil and yet use the freed variable. Calling FreeAndNil instead of Free will make you quickly discover (AV° the error you made. The price is very low for this security.

You are partially right. This recommendation is for destructing a form in the context of an event handler of that form. In that case you need to call Release which defers the actual destruction after the event is terminated. This doesn't apply in this case.

You should stay with the original version for the reasons David gave. Additionally, pay attention to code indentation like this: procedure TMainForm.ButtonClick(Sender: Object) var myForm: TMyForm; begin MyForm := TMyForm.Create(nil); try MyForm.ShowModal; finally FreeAndNil(MyForm); end; end;

Yes I do.

You said: " In Delphi a string is essentially a 1 based array of char". No matter how you try to say it is it doesn't make it happens. A Delphi string is NOT an array of elements of type char. If the were, they would be interchangeable and you admitted they are not.

They key word is "Viewing". That's what I said: compiler magic makes that happens a string is not an array but sometimes looks like an array of char because of the [ ] that is usable. The two types string and array of char are not interchangeable. You will confuse the OP pretending they are the same.

In Delphi a string is essentially a 1 based array of char Not really and I know you know it. It looks much like a 1 based array of char but it isn't at all compiler magic happens here. A string is a record with data used by the compiler a pointer to the actual characters, a count of characters (length), a reference count and more.

Not at all !

The new version I started to develop take 90% of existing ICS code. The new code is developed with Delphi 11 and no effort is done to support older compilers. Since I keep Delphi always up-to-date, it is likely that at the time of release, the next ICS version AKA V9 will officially and initially only support the latest Delphi at that time.

Like said, same app, since I heavily modularized I have not seen such issues any more.  One frequent bug which becomes visible when changing OS is using a freed pointer or freed object or initialized local variable : the address point to somewhere not hurting in one OS but point to something useful in the other OS. I don't think the existed. But rearranging the code by moving some part of one unit in a new unit will cause the code to be linked in different places and the effect of the bug I mention above may be gone. Only the effect will magically disappear but not the bug, it will reappear later when code is again changed and the dangling pointer point again to something significant. As said in my first answer to the OP, that is how it should be done. But do not fall into the opposite trap and make lots of tiny units.

That is not a question of unit size nor number. Something else is wrong in your iOS or Android application.

Small units if better than one large. It helps separate things and it helps to program in a more object oriented way.

You can use Delphi Remote debugger. You probably can run ReactOS in a virtual machine hosted on your Windows computer. I don't know ReactOS. It is not Windows and it is still at an early stage. You may be faced to incompatibilities between Windows and ReactOS. Did you try to run your program under Windows ?

Run your application under the debugger in order to get the exact source line.

You should tell us which source code line EXACTLY is causing the exception. madExcept could also help you find errors in code which doesn't immediately cause an exception.

I'm not sure at all that the old Delphi compilers ICS still support have an option 3rd argument.

This would probably break a lot of code!