Leaderboard

If you build a project, all visible sources are compiled. Only when you just compile a project where the dcu and source are both available, the source is compiled only when its time stamp or memory content is newer than the binary. If you don't want to compile any library sources but always use the binary, you must remove the source from Tools > Options > Language > Delphi > Library > Library path as well as from Project > Options > Building > Delphi-Compiler > Search Path. Unfortunately that removes the ability to debug the library sources. To fix that, you have two options. Which you choose depends on where you add the binaries folder: A: Tools > Options > Language > Delphi > Library > Library path: Add the source folder to Browsing path in the same dialog. B: Project > Options > Building > Delphi-Compiler > Search Path: Add the source folder to Project > Options > Debugger > Source Path Obviously, solution A affects all projects, while B affects the current project only. Note: You have to compile the library with debug options to make that work. With solution A you can separate the debug binaries from the release ones by placing the debug binaries in a separate folder (just as the Delphi lib folder is organized) and add the debug binaries folder to the Debug DCU path entry of Tools > Options > Language > Delphi Options > Library. This will allow to use the debug binaries when the Use debug .dcus option is set in Project > Options > Building > Delphi-Compiler > Compiling.

Unfortunately, I'm not morally depraved enough for that.

Did you file a report to request it? https://qp.embarcadero.com

You could ask me too, thats cheaper

Thank you all . I've found the issue and it was in the installation of the webview2 runtime , not in Delphi. Now all is working as it should be.

Hear, Hear.

Hi everyone, more than twenty-one years ago, I started the German-language part of this forum and could not even begin to imagine what it would become. Thanks to the tireless support of many moderators as well as your thirst for knowledge and willingness to answer other people's questions, it has become a pillar of the virtual Delphi community - even far beyond the German-speaking world. Since 2018, this English-language part of the forum has also been available, with considerable support from Lars. With an online presence of this size comes the obligation to take proper care of it. I have always been very happy to do this, but over twenty-one years is a very long time and life and its priorities change. I can't help but realize that my daily/weekly time has become less available and the time has come for me to hand over the management of the forum to someone else. Thankfully, Thomas B. ("TBx") has agreed to take over the Delphi-PRAXiS and continue it in good hands - together with Lars, of course. You know Thomas as a longtime moderator of this forum and now he will take over my previous role. I myself will of course remain part of the Delphi community - not least because I continue to work a lot with Delphi in my job. I will also remain a part of this forum. Thank you all for over 21 great years!

Further, just talking about the safety concepts... I would classify using variadic behaviour with the va_* like functionality as unsafe, even if it is appealing, and possibly more optimal than having them wrapped by an 'array of const', where fields are encoded into a TVarRec etc, I'd rather stick to the pascal idiom as it is easier to loop through the parameters multiple times, query type information as you go , etc.

You can create vararg functions in Delphi - but not all compilers support it... 32bit Windows DCC32 only binds to external functions (so mapping onto functions exposed from external sources like .obj, .dll, etc) I created a sample to illustrate that works on 12.2 using Win64 compiler... I havn't done a test on older compilers. program VarArgsDemo; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils; function SumNumbers(const acount: integer): double; cdecl; varargs; var LVAList: TVarArgList; i: integer; begin result := 0; VarArgStart(LVAList); for i := 0 to acount - 1 do result := result + VarArgGetValue(LVAList, double); VarArgEnd(LVAList); end; begin try writeln(floattostr(SumNumbers(5, 1.1, 2.2, 3.3, 4.4, 5.5))); except on E: Exception do writeln(E.ClassName, ': ', E.Message); end; end. This relies on some magic TVarArgList, VarArgStart, VarArgGetValue, VarArgEnd If you are familiar with C, you will note how these map onto the equivalents: va_list, va_start, va_arg, va_end So VarArgStart positions LVAList in the correct location on the stack so that subsequent calls to VarArgGetValue will extract the values from the stack. Note that it is up to you to come up with the logic to help VarArgGetValue reference the appropriate type so that the LVAlist increment is done appropriately. In my example, I've kept it simple, with the problem just summing ACount doubles. If you think about C's printf, where you may want to support different types like printf("%d %s %f\n", 10, "hello world", 42.123); you would have to parse the string to then call something like VarArgGetValue(LVAList, integer), VarArgGetValue(LVAList, string), VarArgGetValue(LVAList, double) to extract the values to do something meaningful with them.

That sounds like making underwear for people with a left leg, a right leg, or both. Given that most of the world has two legs, it seems like a lot of needless work to deal with just one or the other.

Greetings to All!. I've built (TSignInWithGoogle) a basic component to integrate Google Sign-in into your Android app using Credential Manager, adhering to Google's most recent guidelines. I'll leave it here for anyone who might find it useful!. Here the link: https://github.com/MEStackCodes/SignInWithGoogleDelphi

This is still a work in progress, but I'm really happy with how it is going so far so I thought I would share... https://github.com/jimmckeeth/FMXColorDialog There are a few custom components in the dialog, and there is a palette code library, plus there is a new CMYK color record. Just fun project to mess around with on vacation. FMXColorDialogSample_PseA8aEaZC.mp4

The forthcoming version of PyScripter will have built-in integration with LLM. See the blog post for a taste of the functionality provided.

Fun fact: some years ago someone (not me, not Andreas) achieved being able to inherit record helpers by simply patching one flag in the compiler. 😉 I am just saying this to emphasize that its not some technical limitation but simply the compiler does not allow it when it sees "record helper" but does when its "class helper" as otherwise its the same code.