Anders Melander

I think not...

source\Property Editors\FmxStyleLookup.pas

Maybe ask yourself that question from time to time. These threads aren't really improving the SNR here.

Let me look it up in the help for you...

I think you missed my point: Backward compatibility. While we can agree on the pitfalls of the current declarations and on how the types could have been declared, I have to take the users' existing code into account before I change something that have worked for over 20 years. Again you missed the point. It was just an example of how changing a publicly declared array type can break user code.

I started to make this change for all the publicly declared array[0..0] types (there's more than a few) but then I realized that this will probably break existing code. For example if a user of Graphics32 has the following declaration: type TMyStuff = record FirstPixel: TColor32; TheRestOfThePixels: TColor32Array; end; PMyStuff = ^TMyStuff; Then the compiler will refuse to compile it because the size of the structure exceeds the max allowed: Given that the [0..0] declaration is a very common technique and the problem here really is that range checking has been enabled for a corpus of code that wasn't written with that in mind (and I'm speaking of *Lemmix here) I think I'll leave it be. My recommendation to get around this for now is to search for PColor32Array and then surround the code with {$RANGECHECKS OFF}...{$RANGECHECKS ON} - or simply declare a new type and cast to it as @Kas Ob. has suggested. Give it a neutral name like TPixelArray/PPixelArray or something like that though; It's not really a hack.

Excuse me but why the hell would you ask ChatGPT about that? It knows nothing about coding; It's a linguistic AI. Also, no amount of googling will help you solve that particular problem. First you need to understand what the error means (what is a range check error), then you must understand what the code does. Pick the code apart and comment it along the way. Run it in the debugger, examine the values passed to the method, validate that they are within the expected bounds, etc. etc. Continue until you completely understand what is going on.

It sounds like you haven't realized why the overflow occurs. That would have been step 1; Understand the problem before you try to fix it. The problem is that GetTickCount wraps around every 49.7 days. The documentation for GetTickCount would have told you that. If you reboot Windows the problem "goes away" since GetTickCount will start from zero again. When GetTickCount wraps around the start time becomes "later" than the current time so the delta time becomes negative. Since we are operating on Cardinals (an unsigned type) you get an integer overflow error. The solution is one of the following: Use another algorithm Use GetTickCount64 and Int64 Use signed integers and cast the cardinal result to integer. Disable overflow checks locally for that particular code. In this particular case I would probably go for 3 or 4. It should be noted that this isn't really a bug. It only turned into a bug when you enabled overflow checks. You could have solved this problem on your own if you wanted to. It wasn't a difficult one. It might seem easier to ask somebody else for the solution to a problem, and sure it might even solve that particular problem, but what it doesn't do is give you the ability to solve future problems on your own. How do you suppose the "experienced programmers" acquired their knowledge? They didn't get it by asking for solutions. They got it by analyzing, doing research and experimenting.

That's a bug. Right now XE2 and later should be supported. I will probably soon change that to XE7 or something in that neighborhood - so a support window of approximately 10 years. The inline vars is something I keep introducing by accident simply because I've gotten so used to them that I don't even consciously notice when I use them. I'm not aware of any compatibility problems with the use of generics. I remember that generics was bugged to various degree in some of the early versions but I'm not going to work around that if that's the problem. I'm also not aware of any problems with Delphi 10; I'm using D10.3, D11.2, and D12 myself.

That's a classic - with an easy fix. Try Googling it and see if you can't fix it yourself; You'll learn more from that.

No and it isn't needed in this particular case. How about you have a peek at the code before you continue?

Okay but lack of imagination isn't a reason to eliminate it 🙂 The use of Sleep in OnIdle is definitely a problem but that doesn't mean that all use of Sleep in the main thread is bad. For example, the fade in/out code is a time limited (sub-second duration) loop containing a Sleep. While the fade in/out is in progress nothing else happens and nothing else should happen. It would be silly to complicate this with threads or timers.

It would probably be best if you had looked at the code before making such a broad recommendation... I haven't looked through all the code but I'm certain there at least some cases where it would make no sense to replace Sleep. I know because I wrote that code.

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.