Jump to content

aehimself

Members
  • Content Count

    1030
  • Joined

  • Last visited

  • Days Won

    22

Posts posted by aehimself


  1. 3 hours ago, Mark- said:

    Am I wrong to think that some values, while using WMI to fetch the values, WMI retrieves the values from the registry?

    To be honest I am not 100% sure about it, but I think no. WMI is storing information in it's own database, which is a piece of junk. Back in the days when I was a sysadmin we had to rebuild countless corrupted WMI databases 🙂

    Wikipedia also seems to confirm that it's separate from Registry: "Windows Management Instrumentation (WMI) consists of a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification."

     

    https://en.wikipedia.org/wiki/Windows_Management_Instrumentation

     


  2. Happens a lot to some of us at work, using 10.0. Sometimes a reinstall helps, sometimes it comes back... I suspect it has to do something with the size of the codebase / amount of components and addons installed, but was never able to confirm this.

    Also keep in mind that in the release notes of 10.3.3 they mentioned a bugfix of a sudden IDE crash.

     

    P.s.: turn off code insight. It's unusable anyway and can cause havoc in the IDE!

    • Thanks 1

  3. In the prehistoric times, you could download the MySQL C library from their website. Then they changed to the installer-type (download installer, select Connector-C, install 32 bit, copy file, uninstall 32 bit, install 64 bit copy file, uninstall everything).

    Now it's even worse.

     

    The installer now offers only 6.1.11, but you still can have the latest by downloading MySQL server and copying the file from the Lib folder. My 64 bit Delphi apps are using it happily; but that's only 64 bit, and there's no 32 bit version of MySQL anymore.

    The question is: is there a way to get the latest (currently 8.0.18) libmysql.dll in 32 bits?

     

    P.s.: I know that libmariadb is a drop-in replacement but I'd prefer the original if possible somehow / somewhere.


  4. Agreeing with @David Heffernan here. If the only solution is to kill and restart you are facing an endless loop, a never firing event, critical section deadlock, incorrect CoInitialize context, an unhandled exception rendering the rest of your code unusable, or thousands of other reasons, what moving to a UWP will most likely not solve.

     

    Litter your code with debugging log messages and you'll find out quickly what the culprit is.

     


  5. Indeed the question is a little bit broad. Are you looking for visual or functional updates? The "How can I modernize my app" can mean implementing cloud-based data storage and/or processing with extensive APIs or just eye candy to make end users more comfortable using it.


  6. Maybe related...?

    I'd also experiment with .BringToFront and .RestoreTopMosts but I'm almost certain that this will push it behind a modal dialog. Keep in mind that this is by design though - if there's an open modal dialog behind your visible form, no actions will be processed and your program will seem to be frozen!

     

    If you really need to achieve this, you could make your own dialog as a simple form and handle the .Enabled and .Visible properties from code. It might sound messy, but results will always be more reliable than playing around with owner and poup handles imo.

     


  7. 1 hour ago, ertank said:

    Maybe you can run two threads?

    Something like your thread-1 does the loop. Upon a variable trigger or a procedure call, thread-1 runs the possibly never ending code in thread-2.

    After that thread-1 checks if that thread-2 terminates in a given time limits.

    If there is a timeout, your main app can provide a feedback to user and maybe an option to re-start the app or something.

    This seems to be over-complication for me. Basically, this is somewhat what happens, only with thread 1 being the main (VCL) thread.

     

    Based on the comments above it seems on Linux there's a high chance (almost certain?) that the app will quit. On Windows it leaks memory and there's a slight chance of further misbehavior - although I could not induce a case like this myself. At the end of the day, if the app is most likely to stop it's better to try to kill the thread first imo. With the 25 prior confirmations, of course 🙂


  8. 15 minutes ago, Joseph MItzen said:

    Is now a good time to bring up that threads are evil? 😈

    I strongly, strongly disagree. They introduce more problems that they solve in some implementations, true; but with correct usage they can make a sluggish UI fluent, a long running calculation finish in a fraction, or simply making the application do several calculations in parallel instead of serial. One word for all: they make a better experience and happier end-users.

     

    Threads are dangerous. Not evil.

    • Like 1

  9.  

    1 hour ago, Anders Melander said:

     

    
    procedure TMyThread.Execute;
    begin
      while (not Terminated) do
      begin
        CallStuffThatMightBlockForever;
        
        if (FNotInterestedAnymore) then
          break;
      end;
    end;

     

    There is no cycle and - as I mentioned earlier - CallStuffThatMightBlockForever might never return, therefore the break will never trigger.

     

    26 minutes ago, Anders Melander said:

    Then the thread will be killed when the application terminates.

    The point is that it's better to forget about the thread, report a timeout and continue as if the thread had been forcefully terminated.

     

    Of course if the thread has allocated or is blocking resources then that solution might not work.

    If the application terminates I'm perfectly fine with that. Before reaching this point there will be 25 thousand nagging confirmation messages. If the user says yes, and accepts that the program might quit or become unstable, I did what I could.

     

    Unfortunately it does block resources. However leaving it to run also can be a solution. If it's needed again I can launch an other instance, this will only cause problems during shutdown. Unless I can detach them from the process...

     


  10. There's no cycle, no serial commands in my thread. It calls one method in a blackbox library (blackbox = not written by me, closed source) which can freeze or take way too long to execute. My code will not regain control for hours to be able to quit, or won't regain it at all.

    This leaves me no options but to expect leaks and misbehavior and kill it with fire.


  11. Hello,

     

    I know it's not good and should be used as a last resort or not at all. But I still need a true, cross-platform solution to instantly kill the execution of a thread, no matter what. Since I only have Windows experience, this is what I have until now:

    Uses [...]{$IF defined(MSWINDOWS)}, WinApi.Windows{$ENDIF}
    
    [...]
    
    {$IF defined(MSWINDOWS)}
     If Self.IsRunning Then TerminateThread(Self.Handle, 1);
    {$ENDIF}

    How this should be implemented on Linux and more?

     

    Thanks!


  12. 13 hours ago, Fr0sT.Brutal said:

    Yeeah, when you move from English-only to multi-language, these 100 lines will turn into 100 files xD

    Well, I'd say one language = one set of of rules = one helper unit. You'll not reach 100 files, but can get close if you are ambitious enough 🙂

     

    Plus, you need a fluent speaker of that language to help you out. I personally do not speak French, but I hear they have quite messed up way of saying numbers (like 92 is "76 and 16" or something).

    • Confused 1
×