GabrielMoraru

@Pat Heuvel- Thanks. I tried the (relatively) new version from github and it works!

Somebody suggested ProcessMonitor, but there is a better tool for this: PE Explorer (although not freeware). It will show you a red dot like this where the dependency fails. There is also Dependency Walker 2.2 (freeware, but kind of old) but it freezes with Delphi BPLs.

Thanks. But this is way beyond that. I think that under certain conditions, the linker simply does not put the debug information into the DCU or EXE file. Or if it is there, the debugger cannot use it. My environment is identical with Lars' except " current user has local admin rights". It is quite random... Today works, tomorrow not. Restarting the IDE helped in 2-3 cases but not in other 10-15. Until now only the code in packages (dpk) was not available for debugging. Once, I rebuilt all packages in a certain order and then I was able to debug again. Friday was the first time when it happen in the project (dpr) itself. But as I said... suddenly it fixed itself so I cannot experiment anymore. The DProj files are very old and I have seen strange lines in there. Lines that are not in a fresh DProj file. I tried to remove those lines one by one, trying to find the offending one. This (broken DProj file) is only a supposition. Until now I strongly believed that it has something to do with the package. But Friday I removed every reference to any external units from the dpr file (except VCL.Dialogs and VCL.forms), cleaned up the DCU folder and it still happened. So, IT IS NOT related to packages. There was only a ShowMessage in the DPR file and it still won't stop there, at that line. uses //FastMM4, vcl.Forms, vcl.Dialogs; begin //Application.Initialize; //Application.MainFormOnTaskbar := True; ShowMessage('Worked!'); // Breakpoint //Application.CreateForm(TForm1, Form1); //Application.Run; end. ______ Normally the exe file is 55MB, and the size is not coming from internal resources and images but from code 🙂 I backed up the exe file and the DCU folder, now that debugging works. I will wait until it doesn't and I will compare the binary files, see if they are smaller.

I have some hints that it might be related to the DProj file. But then, suddenly the bug went away and I cannot reproduce it anymore. I will have to wait for it to reappear then I can continue the experiments.

I built my own program (on top of yt-dl), more specialized in extracting the soundtrack of a very large Youtube playlist. I want to have all my music with me, on my faithful MP3 player, on the bicycle 🙂 The youtube download is fast (when they don't block you because you did too many downloads 🙂 per minute). I inserted some delays to make it slower 🙂 But the conversion (ffmpeg) to mp3 is crazy slow even on a 5GHz CPU. Any ideas on how to make this conversion faster? __ Edit: I was thinking about downloading all the videos first and then processing them in parallel (I have 11 cores doing nothing)...

@Lars. Updates on this? I have a similar problem where debugging in Delphi 11.3 works.... for a while. Then suddenly all breakpoints are ignored. (Suddenly = I change one line a code and I recompile). I can't even put a breakpoint into the DPR! The project is properly set. I even turned on "map file" and "debug info into exe" in the Linker page. The project is really really large: Exe file (with debug info inside) 191MB. Exe file (without debug info inside) 51MB. Map file = 43MB. DCUs = 4MB (the rest is in (DPK) libraries).

https://www.anoopcnair.com/windows-11-version-numbers-build-numbers-major/

Cool!

Great tutorial!

In the Delphi 12 IDE, under Tools, there is a "Reload LSP server" menu: It would be so cool to have it as an icon in the tool bar. But thanks to the old gods and to the new ones, it has an accelerator!

I use a similar solution. I use the TaskManager (I have the Classic Task Manager from Win7 which is really fast installed on my Win11) to kill the fattest LSP process.

Hi I'm also interested in this. Any news/conclusions? Under VCL I had a reusable configurator where the user can change (dynamically) the font for the whole application (all forms/all controls). I would like to have it back in FMX also.

I gathered here a list of issues with FMX async messages. Some of them don't have the X button to close the message, some of them have the button but it does not work Some of them don't let you customize the caption Some of them don't show icons (error, warnings, info, question...) Some of them don't do the "ding" sound when they are displayed.

Also the TDialogServiceAsync.MessageDialog looks disappointing. No icons, no titlebar, no flavor. 😞 And the Fmx.Dialogs.ShowMessage is marked as deprecated 😞 _ Looks like I need to bake my own messages. I have seen a library here doing that but it uses Application.ProcessMessages - something I am not yet mentally prepared to accept 🙂

That's why I am asking how Roger deals with it. In my view, if you want true support for cross-platform (this includes also Android), there is no such thing as blocking/synchronous/modal dialog messages in FMX.