aehimself

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.

There is no cycle and - as I mentioned earlier - CallStuffThatMightBlockForever might never return, therefore the break will never trigger. 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...

Edited to library 🙂 Sorry for not using the correct terminology, since this is my first multi-platform solution I'm not familiar on how these modules are called elsewhere. The original question is still valid, though.

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.

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

However I have 0 experience in cross-platform, this sounds perfectly reasonable. My 2 cents are that if any object (TMyThread) need to live and be accessible throughout a method, define it's variable in the parent (TForm1), worst-case-scenario unit global. It makes sense to me like this and it seems the garbage collector thinks the same way. @David Heffernan My guess is that there is a reason for suspended creation, it is just not included in the example code above. What I try to say is, I always create TThreads suspended myself but mostly because I want to do stuff with them before the actual execution (e.g. .NameThreadForDebugging, etc.).

...and this is from an era when I was already using Try ... Finally blocks! Seriously, most of my first codes make me want to give up development and be a baker instead.

Code is from D7-era. Maybe it worked different back then...? In 10.2 .LoadFromFile effectively does the same (only without the .BeginUpdate and .EndUpdate). But I remember that I had to change due to insanely long loading times.

Memo.Lines.LoadFromFile suffers from performance issues if the file is n x 10 MB, especially if it is on a network location. I changed most of my sensitive methods to use Streams instead: fs := TFileStream.Create('filename.txt', fmOpenRead + fmShareDenyNone); Try Memo.Lines.BeginUpdate; Memo.Lines.LoadFromStream(fs); Finally FreeAndNil(fs); Memo.Lines.EndUpdate; End;

Afaik ShellExecute returns nothing, it does not even confirm if the command line was executed or not. By sticking to it you have no other options but command line parameters, best case scenario is to encrypt the password and decrypt it from the second app. You can check the running processes after ShellExecute and grab it's handle for data transfer but this introduces a lot of unnecessary checks, like timeout (don't wait for the second process until you can find it, what if it did not even launch), did it already initialize and ready to accept data? If you use CreateProcess and map the stdin and stdout, you can make your first application to "type in" the user name and password to the second one and read back the output to verify if authentication was successful. However if both applications are written and managed by you, move the worker method to a .DLL and make the first and the second application to load and use it. You also have to validate the legitimacy of the library, though. Or to a helper unit, and do not even include a secondary file. However, external files will always pose a major security risk, especially if they need to share sensitive information. It's really easy to put a malicious .EXE file in place of yours (even if it's running) just to steal the credentials.

You don't need a component for this. I'd proceed this way: - have a strict private DateTime variable. Upon form creation, set it to zero. - OnKeyDown / OnKeyPress handler of the ComboBox. If the key was pressed, and it's not a comma, set the above DateTime to zero. If it is, check if the value of the DateTime variable: - If the value equals zero, set it to Now - If it's not, check the seconds passed between that and Now (DateUtils.SecondsBetween): - If the difference is greater than 1 or 2, set the variable to Now - If the difference is less, execute your custom action. If you need more help let me know, I can make a quick demo, but my theory would be this.

This is a really important piece of information. Thank you!