Jump to content

Sherlock

Moderators
  • Content Count

    1291
  • Joined

  • Last visited

  • Days Won

    28

Posts posted by Sherlock


  1. 23 hours ago, Tom F said:

    Let us know how it goes.

    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.

     

    • Like 1

  2. 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.

    • Like 1

  3. 2 minutes ago, dummzeuch said:

    Unfortunately not even good and reliable descriptions on how to reproduce the bug and even suggestions on how to fix them don't always get it fixed. I sometimes wonder whether they use some random number algorithm to select the bugs to be fixed.

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

    • Like 1

  4. 21 hours ago, GPRSNerd said:

    So that it is also ignored as all the other high voted bug reports, that will probably never be fixed?

    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. :classic_ninja:

    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...

    • Like 1

  5. 1 hour ago, Incus J said:

    Threads:

    This scares me.  Everything I've read on Delphi tasks and threads in forum post suggests they can lead to really hard to find program failures, and the library perhaps not yet robust.  I've developed commercial software in Delphi for 20 years, but I don't feel ready for threads (or maybe the threading library isn't ready for me?).

    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.


  6. 3 hours ago, Ian Branch said:

    I could use an NTP service I suppose providing it was going to return the Local DTG including DST. 

    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.


  7. 19 minutes ago, Sherlock said:

    I am pretty sure some client/server packages wont appreciate this behavior.

    +

    10 minutes ago, Ian Branch said:

    it is due to a multinational's online software requiring them to be in the same TZ as their server.

    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:

    10 minutes ago, Ian Branch said:

    I had considered UTC but the Users are not the brightest.

    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.


  8. 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.


  9. 36 minutes ago, A.M. Hoornweg said:

    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.

    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.

    • Thanks 1
×