Sherlock

So...I don't know what happened. But from yesterday to now, it suddenly looks good. White font over dark gray background. I'll append my call. Weird. I actually just installed the new version of IDEFixPack...I'll try to get the older one to reproduce...

Well, now reality has arrived: https://www.heise.de/developer/meldung/Folge-der-Uebernahme-Idera-entlaesst-offenbar-viele-Travis-Mitarbeiter-4315673.html Or a taste of it in English: https://twitter.com/hashtag/TravisAlums?src=hash

This!

Ooooh, in that case: Rio is getting there. Seriously!

😄 Nah, AEG ceased to be AEG a long time ago.

Everything worked out fine. Took more than an hour, because after upgrading to 10.14, macOS discovered there is something called 10.14.3 available, and installing that took some time again. Delphi-wise I still can't use the 64Bit iOS-Simulators, but apart from that, everything is A-OK.

Please clarify: is this a VCL or FMX issue, or both? Because I can not reproduce for FMX.

I didn't go back far enough...sorry about that.

Sorry for the dumb question, but where should this path be changed? Searching the registry for Parnassus yielded icy shivers down my spine (the bookmarks are actually stored in the registry), but no path that looked anything like yours @Uwe Raabe Never mind, I got it. Thanks for the simple solution.

Can't reproduce with 10.3.1 for FMX.

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.