Leaderboard

It also assumes that neither of them may be anything but a period or a comma. In Europe alone this will lead to errors. Switzerland for example allows for this to be correct: 1'000. Other countries allow this 1 000 000 or even more ludicrous 1/000/000. As an academic exercise, this project is great. But not suitable for production. I strongly advise against guessing games.

function GuessDecimalSeparator(const Value: string): Char; var i,commacount,dotcount,lastsep:integer; c:char; Const DefaultDecimalSeparator='.'; begin commacount:=0; dotcount:=0; lastsep:=0; for i:=1 to length(value) do begin c:=value[i]; if c = '.' then begin inc(dotcount); lastsep:=i; end; if c = ',' then begin inc(commacount); lastsep:=i; end; end; Case (dotcount + commacount) of 0: result:=DefaultDecimalSeparator; //Default 1: Result:=Value[lastsep]; //accept the one separator ELSE //If a separator occurs more than once, it must be the thousand separator Begin if (commacount > dotcount) then result:='.' //multiple commas else if (dotcount > commacount) then result:=',' //multiple dots else //equal amounts, take last separator result:= Value[lastsep]; End; end; end; This function uses the simple assumption that a decimal separator should occur at most one time in the string, but thousand separators may occur multiple times.

Yes, indeed.

You may have to CoInitialize and CoUninitialize when multi threading and using COM objects.

There is a different approach. I like the approach of DUnit running on Windows under VCL. How can you get the Green Light paradigm working on FMX? Well, Roger Connell has done the port to FMX. See http://docs.innovasolutions.com.au/Docs/ADUGDelphi/ADUGDecember2014.html This approach was presented to ADUG in December 2014. I have used it successfully on Android under FMX. It works very well.

Did you know that 86.64% of all statistics are made up? The remaining 53.42% have been tampered with. Seriously, is there any sense behind this number?

It is impossible to decide for 100%. But possible to guess taking into account ThousandSeparator and DecimalSeparator. It will work in 95.38% of the cases. All other - up to the user.

I moved from JEDI VCS (don't laugh) to Git about a year ago and I don't regret it one bit. Git provides me with functionality that's invaluable especially if used with Git Flow. I use SourceTree as recommended above for most of the work (dark theming coming soon to Windows) but it cannot do all the full Git Flow so I've created some Custom Actions for the missing bits or just drop to the command line. If you want to learn more there is a PDF called Git Pro (https://git-scm.com/book/en/v2) which is definitely worth a read.

When you eat something, you need to prepare it (maybe cook it, or order it, or unwrap it), then you need to clean up afterwards. When you get in your car to go somewhere, you need to start it up; when you arrive at your destination, you need to shut it off. When you walk into a room, you may need to open the door and perhaps turn on a light; when you leave, you may need to shut the light off and close the door. Most things in life require some kind of setup, then you do something, then you clean up after yourself. Tell me it really bothers you having to deal with this constantly in your life ... or if you're like most people, you don't ever give any of it a second thought. Objects work the same way. The fallacy in your logic (and people who claim to dislike creating and freeing things) is that just because there's nothing named "constructor" or "destructor" that you're not initializing things first and cleaning up afterwards. Variables often need to be initialized and cleaned-up, regardless of their scope. By default, the compiler clears out globals automatically for you by setting them to zero, but it's risky to depend on default behaviours like that from your environment. Constructors are simply methods used for INITIALIZING an object's state. They're usually just a bunch of assignment statements. They may also create other objects required inside of the object. Simple objects that don't inherit from a parent class with a constructor that needs to be called don't need constructors. Destructors are for cleaning up when you're finished using the object. For simple classes, they're often not necessary. But if you allocate anything from the heap within the class, then they're required if you want to avoid memory leaks. However, it's a good practice to always have constructors and destructors defined, even if they're empty. And if they ARE empty, the compiler optimizes them out. The nice thing about them is they're called automatically, unlike your existing code that needs to be called explicitly. So don't tell me you dislike creating things! Classes with constructors and destructors require less code than what you're doing now ... guaranteed. Even if you're working with a bunch global variables, any nontrivial application has code that initializes groups of related variables, and breaks them down when you're finished. One of the biggest hurdles functional programmers need to overcome when learning OOP is that all of those global variables need to be collected into closely-related groups, and those groups are called "classes". Then you move the code that's already there that's used to initialize those variables into the class' constructor, and any code that's already there for cleaning up into the class' destructor. Then you want to hide the variables themselves ("encapsulation") by defining properties so if the underlying implementations change, you don't have to change every single place they're referenced. Trust me ... after you've been using OOP principles correctly for a while, it becomes second-nature, and you'll wonder how you managed to keep your sanity dealing with everything splattered all over the place with no organization whatsoever.