Leaderboard

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.

Whenever people say anything like this, I have to think: when will it not be too advanced for me? It's either advanced or it isn't. I'm either up to the challenge or I'm not. I'll only know if I go ahead and try it. With that said, allow me to be the first to admit that I am definitely no more than a novice programmer at best, my interest and experience in it is all from a hobbyist point of view. But, take a look at what I've achieved with SuperLemmix over the past year. You might be surprised at what a beginner is capable of given enough determination and some strong goals!

DocInsight, also known as Documentation Insight, is an API documentation tool for Delphi developers. The upcoming release of DocInsight 2024 represents a major update. It includes: Highlights - Support for Delphi XE7 - Delphi 12 - Redesigned DocInsight CLI - Bug fixes and valuable improvements It's recommend to visit What's New in DocInsight 2024 (Draft) to get more details. New Licensing Model With the release of DocInsight 2024, we are pleased to introduce a revamped licensing model: - Commercial License Licenses are purchased by the company and can be assigned to any single developer within the organization. - Personal License Tailored for individual use, this license is intended for those who purchase it with their own funds and should not be financed by companies in any form. For more details, please refer to our separate announcement. Beta Invitation If you are interested in early access of the DocInsight 2024 Beta, please join our Community Forum and drop us an email at support@devjetsoftware.com to request access to DocInsight Beta. Thanks!

I am taking yet another different approach: The "If you download the sources, the buildnumber will 0. Live with it." approach.

Thanks for your feedback. I will probably consider the external XML documentation files in upcoming minor update as it is required for auto-generated/unmanaged source code, as well as other things (like project-level documentation may not be suited to be put in dpr/dpk). Please see this feature request. The new theme is in the roadmap of the 2024 version. Basically it must support: Responsive Theme (Light/Dark) Customization and Rebranding It is recommended that you create an issue in the DocInsight Support portal. I will make polls in the community forums to know what features really matters to our customers. Best Regards

We are pleased to present the new version 2 of the Firebird Monitor with “Trace and Audit”. We are currently offering a 10% discount on the purchase of a license until the end of June 2024. The coupon code is "Discount10". With “Trace and Audit”, they are able to record and evaluate every single event in the database. Visit our homepage and download the demo version. https://fbm.gksoft.ch

Not sure if this is related or not, but we had issues with running FinalBuilder 8 on windows 11 arm - it would crash on startup or just hang shortly after - I "fixed" it (so far so good) by changing the emulation settings to "strict execution" - try that on bds.exe

Yes thank you. It really helped. I wrapped it in TTask.Run and it worked more responsively: if Assigned(FDEventAlerter.Connection) then TTask.Run( procedure begin FDEventAlerter.Connection := nil; end);

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.

I was looking for an excuse to use VTune again 😉 (thanks to Anders map2pdb!) and here's a flame graph of what's going on while the form is shown: (this is without any sounds being played in the background since I don't have BASS dll lying around - and I'm glad I don't) So the Sleep in ApplicationIdle wastes about one third of the total time. And while FormCreate does spend quite some time in InitializeTreeView, half of it is now because the OnExpanded handler is called during it (that's what @Lars Fosdal was hinting at). But in the end most of the time is spent reading and parsing the level info that is spread over hundreds of text files.

Not with the built-in tools, but here's an excellent summary by Remy of what you need to do: https://stackoverflow.com/a/1130506/386473 I just used exactly that approach and was able to find and fix the memory leaks in like half an hour. I'll try to make a pull request on GitHub as the patch is a bit larger due to spacing when I introduced new try/finally blocks.

This indicate long process and from the memory graph there is huge allocation(s), but no CPU spike also no spike in IO, this means the process or the main thread was waiting or sleeping, aka doing nothing. While this is concerning, Context Switches at 272k with 3 seconds of User Time, this is too much of thread switching while the code in user mode. See this is my ThunderBird (an old version before switching to Chromium means it is single process) , It was up and running for 6 hours and still doesn't have that much of switching while in CPU cycles used as half of the shown in your screen shot. I asked for 2 different shots to compare with some interval between them, so we can see if these context switches as still happening or stopped after loading the form, and fortunately your screenshot landed on your app main thread, which i didn't explicitly point it to fearing of spending time explaining stuff might not be relevant here, so if you will repost screenshot make sure to select that thread from your EXE. ps: if you will repeat the screenshot then first run Process Explorer as Administrator, i would helpful to see the kernel time. Anyway, and to what i do see: Your application is literally doing nothing, there is no intensive CPU usage at all, but there is two background threads i am concerned about, one from dsound usaualy indicate the directsound is playing or recording, in other words there is an audio operation in work. one from BASS.dll, but not sure about this as i am not familiar with bass, only general and past knowledge, so it might be relevant to the above or might not be. from the above i have a question : Are you playing sound(s) in the background or on mouse movement events ? (are you playing sound effects ?) What ever is the answer, try to stop all audio operation like playing sounds and see how does that impact the responsive of your UI, and please share your finding. One more point : to my knowledge BASS library is fully equipped with background threads handling/playing, so most its operations can be asynchronous, to me your unresponsiveness UI is a symptoms of long synchronous operations called from MainThread, the one that should not be doing much other than handling user input, UI, and essential OS calls/notifications, and of course drawing/updating UI (this drawing is more like slapping already rendered image on a canvas).

Maybe I should simply turn off source code downloads from SourceForge ...

Isn't that certificate only for websites? He needs a certificate for signing executables.

Given the current issues regarding optimization that all LLVM-based Delphi compilers (that is all but the two Windows ones) have I am tempted to say that an x86 or x64 binary using the emulation layer might be faster than what a compiler that directly targets ARM would produce today. There are multiple reports about this and it boils down to "need to migrate to a newer LLVM version" which we have been told for years now - since recently the C++ Builder side was migrated to a recent LLVM version I hope that now the Delphi side gets addressed. https://quality.embarcadero.com/browse/RSP-9922 https://quality.embarcadero.com/browse/RSP-17724 https://quality.embarcadero.com/browse/RSP-25754 https://quality.embarcadero.com/browse/RSP-28006

I've just added a new demo: https://github.com/DelphiWorlds/Playground/tree/main/Demos/Advertising to the Playground repo