Anders Melander

That's the spirit! I must say that given that you're a relative noob (no disrespect; We've all been there 🙂 ) I am pretty impressed with your determination and with what you've done with SuperLemmix. From what I've seen it's not the easiest of projects to work with.

It's the first in the thread list: No; You do both: Use the timer to trigger the animation. Use GetTickCount to calculate which frame to display. I would probably stop the timer at the start of the OnTimer handler and start it again at the end, in order to avoid a flood of timer messages if the handling is too slow. If you move the animation out of OnIdle, remember to change the OnIdle handler so it sets Done=True (instead of False, like now). This way the OnIdle handler will not get called continuously. Also take care to not do anything in it that will produce windows messages. If it's almost too fast to warrant a progress bar then simply introduce a tiny delay. You might make the load slightly slower but the user experience might be better. Looks good. This might be a bit too advanced for you at the moment, but I would strongly suggest that you make each element (e.g. each button) a layer. It will make the interaction and control of the elements so much easier and perform much better since it utilizes TImage32's built-in repaint optimizer to avoid the current whole-scene repaints. I have a local branch for NeoLemmix where I changed the main menu screen to use layers for the scroller/banner, logo, buttons, etc. but I had to abandon it since working on NeoLemmix was basically just procrastination.

That's nice I guess but No support for external XML documentation files. This is a complete showstopper; 1) I'm not mangling our source with doc comments, 2) Some of our source is generated. The comments would be overwritten. The layout is still hard coded to emulate the VS2012 help. I don't mind the style but without the possibility to adapt the content to an existing layout the generated help just looks bolted on.

Similarly unrelated, the MAX_PATH limitation can also be circumvented with the manifest: https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests#longPathAware

If you still have madExcept installed you can enable leak detection in it, recompile, run, exit and it will produce a nice list where you can double-click each entry and it will take you to the exact source line where the leaked resource was allocated. I just tried with Neolemmix; Run, exit, tons of leaks: This is the direct result of running the animation loop from Application.OnIdle with Done=False. Replacing it with a timer would solve that problem. That problem can probably be "solved" by simply displaying a progress bar while the files are being processed; Users are willing to tolerate quite a lot of delay as long as they know why they are waiting and can see some progress.

Okay, so you are doing something in Application.OnIdle. My guess is that you are doing too much (it's taking too long) and thus slowing everything down. Application.OnIdle is called inside the message pump loop when the the message queue is empty. If you do something in OnIdle that take a bit too long the message pump will be slow to react to new messages in the queue. It could also be that you produce a lot of new messages in OnIdle and thus flood the message queue and keep the loop busy all the time. My guess is that OnIdle is used for animation so the messages are probably mostly WM_PAINT and WM_TIMER. Anyway, have a look at what the OnIdle handler is doing. Does the problem go away if you disable that?

You must be thinking of DOS/Windows 3.x. All version of Windows since Windows 95 has supported threading. Your screenshots aren't really showing us the call stack. Make sure that after your pause that you switch to the main thread (open the thread list, double click the topmost thread). I would keep madExcept installed if I were you and occasionally enable its memory overwrite detection for your application. That is how I found and fixed some of the memory overrun bugs in NeoLemmix.

With regard to madExcept; Nothing. You just enable it for your project, check the freeze detection and run the application. If the application isn't pumping the message queue then madExcept will detect that and pop up its usual message box with a stack trace and options to terminate, restart, etc. However, you would only need to do all this if you cannot reproduce the problem in the debugger. If you can reproduce in the debugger you will get the exact same information by just pausing the application and examining the call stack of the main thread in the debugger. No. I believe it was possible to break into the debugger using F12 in Windows XP but I think that option was removed (by Microsoft). I have a registry hack somewhere that enables it again, but I don't have time to find it right now. I think it's related to this: https://learn.microsoft.com/en-us/windows/win32/debug/configuring-automatic-debugging Maybe someone else here knows the answer.

That's @Eric Grange You can send him a DM here.

...but only briefly mentions VTune 🤔. A bit of a missed opportunity there.

The amount of meme-worthy bullshit he's managed to squeeze into that site is actually quite impressive; There's layers upon layers of it. You can almost hear the feedback loop caused by believing your own marketing.

Ugh. Rewritten in C# using WPF, It's ironic that they've named the new application "Dependencies"; The old one had 1 DLL. The new has 54 DLLs.

Use GetAsyncKeyState instead of GetKeyState. GetKeyState will get you the state of the keys when a message was last read from the Windows message queue. This may or may not correspond to the current keyboard state. GetAsyncKeyState will get you the current state.

FUD much?

That's not necessary; The attach dialog doesn't allow you to attach an instance to itself:

They probably thought it was a good idea at the time (wasn't this before they fired everybody?) but unsurprisingly that didn't work out for them and now it appears to be in "maintenance mode". So, a good example of why it isn't a good idea. So because they have done something in the past, and it has mostly turned out to be a bad idea, it would make sense for them to continue to do it? Interesting viewpoint. Sure, it would be nice if the feature was built-in but I don't really think acquiring a 3rd party product (and that product in particular) is the best way for them to cover that. I think it would be better if they simply provided the framework to make it possible instead. This could be the miraculous exception to the rule, but acquiring something to plug a hole (or whatever the reason) doesn't just end once the rights has been transferred. There's also integration, branding, documentation, infrastructure, education, support, etc. And then there's the cost of maintaining it once you have made it a core part of the product. Entering straw-man territory. We don't know how the debugger does stack tracing and we don't know if or why they might have made a choice or what choice they made.

There's really no point in using a third-party logger if you are going to resolve the stack trace manually like that. It would just add overhead and complexity.

You are not really addressing the point I made; How is the fact that something is useful to the user relevant to Embarcadero if they are not going to make money acquiring it? It's not as if it's a strategic feature. Besides that, I don't see the benefit from the users standpoint. Embarcadero does not have the resources to properly maintain something like this and they would just hurt the other existing exception handlers (madExcept, EurekaLog, etc.) which in turn would hurt the users.

Button captions and such are defined by resourcestrings. For example, see Vcl.Consts.pas: resourcestring [...lots of strings...] SOKButton = 'OK'; SCancelButton = 'Cancel'; SYesButton = '&Yes'; SNoButton = '&No'; SHelpButton = '&Help'; SCloseButton = '&Close'; SIgnoreButton = '&Ignore'; SRetryButton = '&Retry'; SAbortButton = 'Abort'; SAllButton = '&All'; You can use any of of the many different localization solutions to have them translated. E.g. this one: https://bitbucket.org/anders_melander/better-translation-manager

Install madExcept and use that to detect and report when the application freezes (provided the freeze is caused by the application not pumping the message queue).

They are in business to make money; Not to be practical. I can't imagine that they would sell a single license more because they had a cross-platform stack tracer.

I can't see why they would do that.

Life-time license. Sounds good but in reality it means the developer has no incitement to maintain the product - at least not a commercial one.

This sounds like contract work; You should probably clarify. A screenshot of the existing forms would also be nice.

https://www.google.com/search?q=delphi+"rrequires" As far as I can tell the only identified cause seems to be line endings. Of course that doesn't rule out that there might be other causes but until we get an answer from OP all we can do is guess.