aehimself

What you see is how a specific operating system is handling unresponsive windows. It's not only your program, it's all which are freezing the main thread (therefore blocks message processing). If you don't mind getting your hand dirty by writing REALLY BAD code you can get away with periodically calling Application.ProcessMessages during your long operation: Procedure StartLongOperaton; Begin Operation1; Application.ProcessMessages; Operation2; Application.ProcessMessages; End; or Procedure WorkWithDataSet(inDataSet: TDataSet); Begin inDataSet.First; While Not inDataSet.Eof Do Begin DoSomethingWithRecord; inDataSet.Next; Application.ProcessMessages; End; End; ...but if you don't know what you are doing, you'll quickly face more issues than just a frozen window. PeekMessage works, because it is forcing the processing of windows messages, therefore your form will APPEAR not frozen. Application.ProcessMessages does the same, it's basically a better wrapper for it. The real solution is... well, you guessed it: threads. There is no such thing as a method is "not possible to put in a thread".

When I reached a point like this in the past I always went for a full refactor. It's painful, it's slow, adding no new features at all (maybe even removing some...?) but you always can reuse chunks of code to help to finish faster. In the end it worths the effort, trust me. I had an application I was maintaining for 10 years (7 threads plus VCL logic written in Unit1.pas, with names like Button1 or Thread1) when I decided that it was too messy. It took about 3 months to rewrite the whole thing from scratch but implementing proper class inheritance and separation of data access, business logic and UI. Adding a new feature in the past took days or weeks, now it is a matter of hours. As an addition, I cannot tell how many bugs were fixed just by cleaning the code up. It's a tremendous and scary job. But knowing the result I'd definitely do it again.

Hello, In Delphi 10.3.3 I have a DBGrid component with the following handler: procedure TForm1.DBGrid1DrawDataCell(Sender: TObject; const Rect: TRect; Field: TField; State: TGridDrawState); Var r: TRect; begin If ZQuery1.RecNo Mod 2 = 0 Then Begin r := Rect; InflateRect(r, -1, -1); DBGrid1.Canvas.Lock; Try DBGrid1.Canvas.Pen.Color := clRed; DBGrid1.Canvas.Pen.Width := 2; DBGrid1.Canvas.MoveTo(r.Left, r.Top); DBGrid1.Canvas.LineTo(r.Right, r.Top); FInally DBGrid1.Canvas.Unlock; End; End; end; Everything works fine: Until the moment when I enable VCL Styles. At first, it appears okay: But if you start to click (especially try to drag and drop column headers) things start to fall apart: This does not seem to happen when there are no Styles enabled. Anyone has an idea on what is this and how to fix it? Thanks!

Soooo... the bad thing is that without major changes the original project started to work correctly and I don't know why!!! Especially since the raw DBGrid seems to have this issue and I don't remember fixing anything in my descendant...

Yes, original code was without .Lock and .Unlock but since it started to glitch out I decided to include it (and it remained). As for the Mod 2 it is no mystery, only my mistake: took the shots before changing the value - was experimenting with a lot of things before asking. Invalidating after a column drag will not be the solution - as this is only the sample code, and this is how I could recreate the issue. In the original project some lines are drawn correctly, some are in black (no matter that the color is set to red), some does not appear at all even without dragging involved.

Completely agree with @David Heffernan here. From what I imagine your app is like, you would have easier (and more user friendly) results looking into writing a Word plugin instead.

Forget about dism and SFC, those commands never fixed any issues since I'm working with computers 🙂 The command you are looking for is wsreset, I think I had to use it a couple of times on my Insider PC. https://www.thewindowsclub.com/reset-windows-store-cache

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

Don't rely on the registry, it easily can be overwritten! Even if it's temporary, it can confuse your application. I found this code in the Internet, which I extended to generate an MD5 hash with DCPCrypt. Remove it if you don't need / have it and use it if you want. HWID.7z

Please tell me that Oracle VirtualBox is not using incremental/differential snapshots (like VMware does)! If yes, creating a snapshot and continuing to use the VM will eat up your disk space quicker than you could say "upgrade"!

I personally never used FireDAC, and it shouldn't be an issue at all, but here we go. Maybe the driver waits for commiting the transaction? Also you can try not to clear, but simply say qry.SQL.Text := 'DROP TABLE USERS'. It will also trigger the change in the TStrings (which I guess the SQL property is) but it worths a try...

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!

Yes, 6.1.11 is the latest I could find (and therefore have). I was hoping someone knows where to find a recent version. I honestly think Oracle discontinued it; my hopes are more on unofficial builds (like oss.netfarm.it was for ClamAV).

Yes, the installer has a 32 bit version, but it only offers the 64 bit server for installation 😞

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.

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.

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!

The existence of sqlite3_interrupt suggests that yes indeed, they do 🙂

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.

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 🙂

I'd add a scrollbox in the groupboxes first, and add insert the controls on the scrollboxes. Just to be sure that they'll be all visible. Edit: Also, I'd add recursivity in the GetAllCheckboxes method, but that's only my taste.

https://i.imgur.com/sqZE6sS.jpg I hope some will get it 🙂

It does. But we all know the phrase - you cook with what you have 😞

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.

As far as I remember (I am not allowed to use CE anymore, unfortunately) you can request a new license for CE somewhere on the website after logging in.