Anders Melander

Yes it is. The code you have posted will leak the TFDQuery instance and not return anything.

TBH I'm sure that I have suffered from this back when I was a rookie, but fortunately I quickly learned that it's not my problem. IME one of the primary causes of stress is the inability to understand this. People take responsibility for things that are beyond their control. There is no spoon. The cake is a lie. Etc.

No it's not that I haven't encountered it. I just don't consider it a problem. If a PHB decides to ignore my estimate based on his own opinion then that's his problem. Sure it might be demotivating developing something that you know will be late or unfinished because of that, but again; It's not my problem. It only becomes my problem if I revise my estimate based on pressure or try to meet an unrealistic deadline.

Never had that problem. The customer/manager might have their own opinion about the size/cost of a task but that doesn't really matter. What matters is the time/cost estimate I give them. Their opinion will not affect the outcome.

Plenty. You are trying to solve a problem you've created yourself by insisting on doing the mockup in Delphi. The solution should be obvious...

No disrespect but the same is true of many of those that have below average expertise - The Dunning–Kruger effect. I disagree but it doesn't really matter; The principles are the same regardless of the platform. Under any circumstances, at this point, your (and our) time would be better spent if you tried to locate the source of the problem instead of having everybody guess. Don't blame Windows for that. If you don't understand it then maybe leave threading to those that do. As far as I can see the majority of this thread is people restarting discussion about issues that have already been covered, people suggestion things to try and you trying it with no idea if or why it might or might not work.

Please read the whole thread before commenting. I already answered that and posted the relevant section from the SendMessage documentation. How would that help when: The cause of the problem isn't known. The original author of the code doesn't have good understanding of threading issues. The current maintainer doesn't either.

You are using static strings so there's no string allocation involved thus no corruption. The PChar will point to a constant string that never changes. Create the string with Format or IntToStr, as in my example, and you will get corrupted strings immediately. Also; Why WM_USER+1? Is WM_USER cursed?

You are off course correct: You are correct if the string resource is protected, but I'm not seeing any evidence of that. The string copy you're referring to happens in the message handler when the PChar is converted to a string, but before (or while) that happens the tread can have modified or free'd the source string. It's a race condition. Let's say the relevant code looks like this: // Thread procedure TMyThread.Execute; var Buffer: string; begin while (not Terminated) do begin Buffer := IntToStr(GetTickCount); PostMessage(MainWindowHandle, WM_STATUSOUT, WParam(PChar(Buffer)), 0); Buffer := 'Lorem Ipsum Dolor'; end; end; // Main thread procedure TMyForm.WmStatusOut(var Msg: TMessage); var Buffer: string; begin Buffer := PChar(Msg.wParam); OutputDebugString(PChar(Buffer)); // Or simply: // OutputDebugString(PChar(Msg.wParam)); end; I can guarantee you that you will see corrupted output.

Okay. I'll try again then. There are multiple problems in the original code. Like I said, Application.ProcessMessages in itself isn't a problem. The problem is that when you use SendMessage then the WMStatusOut method will run in the context of the thread which means that Application.ProcessMessage will also be executed in the context of the thread and that will definitely end badly at some point. Replacing SendMessage with PostMessage will take care of that (and get rid of ProcessMessages while you're at it. It's the mark of an amateur). Once the above is fixed, the more serious problem will surface: You're passing a pointer to a string owned by the thread to the main thread. You haven't posted the thread code, but I'm betting that there's nothing in your code to prevent the thread from modifying, or even freeing, this string once StatusOut has been called. I'm sure one of the usual suspects will be happy to provide you with an alternative solution.

While Application.ProcessMessages is evil it isn't the cause of the problem here. Use PostMessage instead of SendMessage. SendMessage calls the message handler directly and doesn't use the message queue at all. https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-sendmessage

Whatever function you come up with it will be susceptible to race conditions; After you have determined that the file isn't in use, but before you can open and lock it, another process can come in and open it - or vice versa. Working from Remy's example you need to keep the file open after FileCreate. As soon as the file is closed the test result is stale.

It matches the indention style though

The threading library doesn't matter if you don't understand how to solve the problem and you won't learn by having other people solve it for you. It's a fairly simple problem and there's a gazzilion different ways to solve it. Why not give it a go on your own?

Imagine if your browser worked that way. Page slow to load? Sorry - You'll have to wait until it loads until you can try something else.

Okay, here's what I would do: First of all I would use TThread instead of tasks as that will give you better control of thread lifetime and resources (the bitmap). Let the thread own the bitmap. Remember to lock the thread canvas when you start and unlock it when you're finished. This prevents the VCL handle cache (controlled by the main thread) from messing with the bitmap while you're working on it. The thread also owns a windows event object. The thread signals this event when the render has completed. This allows the outside to wait or poll for for render completion. When the event has been signaled the render is complete and it's safe to access the bitmap. The tricky part is deciding when to destroy the thread. Since the thread owns the bitmap you can't have the thread destroy itself when it's done. On the other hand if you "forget" about any existing thread when a new thread is started then these old threads cannot be destroyed when they're done. If you have a good understanding of race conditions and synchronization objects then this can be solved fairly easy (but it's more complex than I have time to explain now). Otherwise I suggest you just keep a list of threads. Add new threads to the list and remove from the list and free when a thread has signaled completion. At some point you will have to go through the list and remove and free the old threads.

That doesn't really address the problem.

It depends. Sometimes indexed access is faster.

You could just create a new task and ignore the old one (including its output). If the rendering can't be interrupted then there isn't much else you can do. The actual implementation is trivial and will depend on the surrounding code so there's not much point in giving examples.

The standard windows List-View control, wrapped by the Delphi TListView component does this. The Tile View style is probably what fits your requirements best but unfortunately that isn't directly supported by TListView. Google Delphi LV_VIEW_TILE to find solutions around that.

I notice you didn't answer the question, but no; It makes the code harder to read as you have to think about what Pred does. With "Count-1" there's no doubt. Don't use a feature just because it's new or you've just discovered it.

Why is that "cool"?

Welcome to software development. You may find that things become easier (or even clear) for you if you: Read the help. Learn about classes and inheritance. Specifically the VCL class hierarchy is important. Examine the VCL source code. See what others do. See what works and what doesn't and learn from your experience.. Good luck.

It sounds like you really just need protection against casual discovery of the information. In that case just obfuscate it. E.g. with a simple ROT13 or even base64 encode. If someone already has access to the physical machine, and is willing to do the work required, the battle is lost any way. There are a million ways to circumvent any local encryption scheme so forget about that.

If everything was as you believed then there wouldn't be a problem. The debugger behavior you describe is the same for all versions and is as expected. If you don't want the OS to switch threads during single step then you need to suspend the other threads in the debugger. But you don't really need to single step to locate the problem. Just repeatedly pause the application when it exhibit the behavior you describe and examine the call stacks of the different threads. Sooner or later you will get a snapshop that reveals the cause of the problem. This simple approach almost always work for me.