Sherlock

Move to Rio for Mojave, it just behaves better. And concerning the 64Bit macOS Apps, just wait a little bit longer. I just did the jump to Rio yesterday, iOS Apps and macOS work just fine, at first and second glance. Mojave is up next for me today...wish me luck.

This is what mine looks like, but it is a fresh install (I kind of avoid the first major release...)

Those bugs still have a way better chance at getting fixed than "It's broke, fix it!" or no bug report at all.

That is actually the best way to get the problem ignored...ignoring it on the user side. I wonder which demi gods promoted their bug reports because there seems to be quite some fixing done. Keep in mind, that concise instructions to reproduce an issue may work wonders. They are our peers and great minds think alike. Good bug reports yield fixes. Yada yada yada...

Don't be scared. Actually this is a prime example use case for threads. Just follow the tutorials to get a feeling (http://docwiki.embarcadero.com/RADStudio/Rio/en/Using_the_Parallel_Programming_Library) and then dive right in. You may also want to check out the answers to this SO question: https://stackoverflow.com/questions/44080089/how-to-stop-a-running-ttask-thread-safe For a slightly different approach consider the classic http://docwiki.embarcadero.com/Libraries/Rio/en/System.Classes.TThread. And then of course there is always the OmniThread library, which I have not yet played with so far, but I hear only good things.

Stored Procedures? The work involved is the same. The DB can't guess what default value you prefer.

When was the last time you actually witnessed that?

Yeah, my comment was rather tongue in cheek. I do sense an overall trend there 😉

My understanding is: It wont. You have to add your timezone information to the resulting UTC. So don't bother with your own ntp-client implementation. Just store the timezone offset between local time and client time.

Well, as long as you didn't change your code, it's a strong hint towards deteriorating compiler quality (it could also be that iOS is getting worse, there seem to be some indicators towards that). Otherwise...well 😉

+ Nice! Just as I predicted only with a twist 👿. Pretty shitty software, considering it is supposed to be multinational, if I may say so. But back to the problems we can solve: So the users have to evaluate log files? How about you create a log reader, that will make the timezone calculations for them? Or you could store the correct timezone information in your own settings and use them when writing logs - remember however to calculate correct daylight savings time in both cases.

There is an established protocol for this called NTP. However, it is based on UTC and clients must add their timezone information. So to achieve your goal, you could either implement an NTP client, with the possibility to configure his own private timezone, or just deduct the timezone differences. Or you could give those fellows who set their PCs to different timezones a good whack on the back of their heads. If they need to see a different time, either they or the special software they use, should do aforementioned basic math, I am pretty sure some client/server packages wont appreciate this behavior. A neat trick that involves only minor changes is to log UTC time. Just remember to add your timezone when evaluating the logs.

Me neither!

@Eli M. The discussion concerning usability of LiveBindings in production on G+ was quite biased towards unusable. What is your typical data volume i.e. how many tables/fields/rows are bound to how many controls?

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.

Did it help?

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

The problem there might be, that FMX-Buttons are not Windows Buttons, and therefore don't rely on Windows messages. At least, that's what I remember about FMX.

Only safe if it works...and just to make sure, this is still Delphi we are talking about, correct? So this feature might work reliably two versions after the introduction, if it gets used enough for a decent flow of error tickets from the get go. At the current rate for RIO, people (including me) seem to be holding off the upgrade until RIO.1 is out - the more people do that, the less likely that .1 will make sense. Sorry for that OT interjection there...carry on.

That still has users? I loved it back in the day (around, oh...8 years ago), and actually miss it some times. I have the occasional merge conflict, that a pascal enabled merge tool wouldn't even think about, but have to keep dreaming of a language aware merge...

I would only accept numbers in a well defined format known to me. https://en.wikipedia.org/wiki/Decimal_separator#Digit_grouping gives me the creeps. 😱 tl;dr: digit grouping (thousand separators) may also occur to the right side of the decimal separator. BTW: I've seen something like this 1'000'000 quite often.

@Dalija Prasnikar Yay! for dogfooding!

Just to be clear, Uwe Schuster is the one who wrote that expert. Not Uwe Raabe.

Oh, yes you are right. It is not built in. But it works with Rio! What I posted however is a screenshot with Tokyo. You can get the plugin here: https://github.com/MJSt/DelphiVersionInsight Compile it and activate the add-in DLL via a tool like GExperts Expert Manager.

On a totally unrelated matter I would like to direct your attention to a completely underrated feature of Delphi: LiveBlame - in the IDE! This however works with hg,git and Subversion. But I just love this! I love to put blame on others, and then find out it was my fault after all! 😄