Anders Melander

Nicely avoids the problem of integrating with the IDE help system - by not integrating with the IDE help system 🙂 Also contains the only instance of a cocktail shaker bubble sort that I've seen used in practice. "Outdated help is better than no help" - apparently.

I have an IDE wizard lying around somewhere on my HD that AFAIR will can redirect the help request to an URL if the other help providers fail to resolve it. It was made for Delphi 5 or 6 (so it's 20-25 years old) and from back when the MSDN help was distributed on CDs. I'll see if I can locate it and get it to compile with a newer Delphi... Yup it works; I just had to update the default search URL. However, for some reason it only works if I search on a keyword the standard help doesn't resolve. Otherwise the IDE help lookup fails with an exception. I can post the source if anyone wants to have a go at it.

Give madExcept a try again; It's much easier.

I have migrated countless JIRA instances from server to cloud and it has never been "a significant effort". The only problem I can think of is if they had modified their server so much that it couldn't be migrated automatically. Indeed. Normally this wouldn't be that big of an issue as lack of features and bug are to be expected, this being a relatively new product. But the problem with Atlassian is that the suckage only ever increases. I think they hate their users. Eventually Github will eat their lunch.

A single item for me so YMMV on the "essentialness".

A google search would have told you that. Or the IDE insight: or the help... Command line. Replace <map-filename> with the name of your map file. Run VTune, configure your project there, launch the application from within VTune. But before you do anything, please read some VTune documentation. You don't need to post anything to get notifications. Just click the Following dropdown.

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.