Leaderboard

I always liked the concept of splines a lot, and here is now the reason why https://www.youtube.com/watch?v=jvPPXbo87ds This beautifully unveils all hidden secrets about it ( Ok, not all, hopefully more to come ).

I'm quite sure that the people at TIOBE are driven night and day by their intense feelings of envy towards Delphi. I really can't imagine they think about anything else.

We have just released an open-source Delphi implementation for a HTML-based cross-platform application help system. Information page: Ziphelp - an open cross-platform help format Direct download link: https://www.helpandmanual.com/download/delphi-ziphelp-demo-source.zip About Ziphelp On the surface, Ziphelp is basically HTML in a compressed zip archive, hence the name. Pack any folder with HTML files into a zip archive and you are good to go. But Ziphelp is more than that, it is a protocol based on the standard sitemap protocol, designed to give a help viewer (here: the Delphi implementation) extended information about the content of the help system. That is help context numbers, help keywords, associative keywords, page titles. This information is missing in a standard sitemap.xml. Ziphelp extends the sitemap protocol and enables direct communication of an app with the help system. The Ziphelp protocol is not just for zip archives. It works inside an archive, with uncompressed folders or with HTML content loaded directly from a website. A Delphi desktop app may be deployed with local application help, uncompressed, zipped or embedded. A mobile or web application might not ship with local HTML content, but refer to an online version instead. The mechanism is the same in both cases and the TZiphelp component implements this for Delphi. Demo Application A demo app for VCL and FMX (Win/MacOS) is included. The demo builds on standard Delphi components (TWebBrowser) to display the help system.

As one of the few lib devs that actually test their code on all supported Delphi versions I object - dproj files so often have incompatibilities in them. Yes, it is possible to have only multiple dproj files but only one dpk they refer to and put the libsuffix stuff into an inc file referencing that one on the dpr (have done that, works fine) but it is tedious. I rather copy the latest version when a new one comes out/is in beta. The more important thing imo is using forward-compatible defines in the code - it drives me mad whenever I compile some code in a newer version and it simply does not work because the code requires explicit defines because they are not done in a forward-compatible way.

That issue basically just says "Give me a 64-bit version because I say so - or else". I would just close it if I were Embarcadero. But I'm sure that migrating to Lazarus will ensure that you don't have to worry about memory limitations anymore. You will have a whole slew of other problems to keep you busy instead. Good luck with that.

The code will not work as intended. Streams store bytes, not characters, and the size of a character is 2 bytes in Unicode-enabled Delphi versions. To calculate the number of bytes to write you have to use strmSize := Length(s) * Sizeof(char); TStream.Read and TStream.Write are also somewhat deceptive and excellent traps for beginners . They use untyped parameters and those do not work as you obviously expect from your code snippets. The compiler passes the address of the variable s to the method, not its content. So your strm.Write statement writes strmsize bytes starting from the address of s, but since strings in Delphi are reference types that address only holds a pointer pointing at the actual content of the string. You have to use strm.Write(s[1], strmSize); to write the content of the string. Reading it back has to follow the same pattern, and you have to position the stream to the start first and make sure the string you read into has enough memory allocated. Assuming the stream contains only the one string you have written into it this would look like this. I use a local string variable here to make things clearer, globals just confuse things: procedure TForm1.btnStrmToStringClick(Sender: TObject); // load/read into a tedit control var LTarget: string; begin strm.Position := 0; SetLength(LTarget, strm.Size div sizeof(char)) strm.Read(LTarget[1], Length(LTarget)* sizeof(char)); eb2.Text := LTarget; end; Things get more complex if you want to store more than one string into the same stream. In such a case it is advisable to store the length of a string (as integer) before the string content, so you can read the length first to figure out how to size the target string and how many bytes to read into it. Delphi has useful helper classes like TStringReader and TStringWriter to make such stuff easier. And if you only have to handle text you can put it into a TStringlist and use the list's SaveToStream and LoadFromStream methods to avoid all the hassle completely.

I advise against the use of TCheckBox or similar for such an input. There are multiple reasons: "greyed" state doesn't clearly mean "not sure" AND you might have to click twice to change your answer from one answer to the other. I'd suggest to have three radio buttons, right next to each other, with each column having a title; like an online questionare. Somthing like this:

The IFEND works in all versions. LEGACYIFEND ON only makes XE4+ accept only IFEND, too. That might be helpful to write code compatible with versions before XE4 when written and tested with newer versions only. So it is more like a safeguard for the developer, but code written like before XE4 will also compile in XE4+ without that LEGACYIFEND directive.

For the same reason they have ridiculous NDAs and don't have public betas; They are so stuck in the 90s that they think anyone still gives a damn.n They never understood how to build a community.

A multiline string is multiline - simple as that.

Yes, it does. But it can only handle messages that are already in the message queue (or synthetically generated by the queue) at the moment it is called. It does not process future messages. And the behavior you describe sounds like the actions are being delayed such that ProcessMessages() doesn't see all of them right away, which is why calling ProcessMessages() multiple times produces better results. You really should not be using ProcessMessages() in this manner in the first place. Break up your code logic using TThread::ForceQueue() or a TTimer or equivalent to allow control to flow back into the main message loop so it can continue to process new messages while your desired time interval is waiting to elapse. For example, using TThread::ForceQueue(): void __fastcall TForm1::Button1Click(TObject *Sender) { Button1->Enabled = false; Button2->Enabled = false; Button3->Enabled = false; TThread::ForceQueue(nullptr, &Step2, 3000); } void __fastcall TForm1::Step2() { Button1->Enabled = true; Button2->Enabled = true; Button3->Enabled = true; TThread::ForceQueue(&Step3, 3000); } void __fastcall TForm1::Step3() { //... } // alternatively void __fastcall TForm1::Button1Click(TObject *Sender) { Button1->Enabled = false; Button2->Enabled = false; Button3->Enabled = false; TThread::ForceQueue(nullptr, [this](){ Button1->Enabled = true; Button2->Enabled = true; Button3->Enabled = true; TThread::ForceQueue(nullpr, [](){ //... }, 3000); }, 3000); } Or, using TTimer: void __fastcall TForm1::Button1Click(TObject *Sender) { Button1->Enabled = false; Button2->Enabled = false; Button3->Enabled = false; //Timer1->Interval = 3000; Timer1->Tag = 1; Timer1->Enabled = true; } void __fastcall TForm1::Timer1Timer(TObject *Sender) { if (Timer1->Tag == 1) { Button1->Enabled = true; Button2->Enabled = true; Button3->Enabled = true; //Timer1->Interval = 3000; Timer1->Tag = 2; } else { //... Timer1->Enabled = false; Timer1->Tag = 0; } } // alternatively... void __fastcall TForm1::Button1Click(TObject *Sender) { Button1->Enabled = false; Button2->Enabled = false; Button3->Enabled = false; //Timer1->Interval = 3000; Timer1->OnTimer = Step2; Timer1->Enabled = true; } void __fastcall TForm1::Step2(TObject *Sender) { Button1->Enabled = true; Button2->Enabled = true; Button3->Enabled = true; //Timer1->Interval = 3000; Timer1->OnTimer = Step3; } void __fastcall TForm1::Step3(TObject *Sender) { //... Timer1->Enabled = false; Timer1->OnTimer = nullptr; }

You can start from here: https://github.com/IndySockets/Indy/wiki/Updating-Indy

How about such solution ?

Please stop using VERxxx. It's been possible to do {$if CompilerVersion >= XX} since Delphi 6 or 7. It's so annoying having to edit the .inc files of various 3rd party libraries with each new version of Delphi because they're designed as if the latest version = the last version. Graphics.32 uses {$LIBSUFFIX AUTO} for the D11+ packages. The earlier packages are manually maintained by using a diff tool to keep them synchronized with a master. The master usually comes from the latest supported Delphi version. There's no way I'm wasting disk space on old versions of Delphi just to maintain the package files. I have the latest version, and the few versions required by my job, and that's it.

I would really like to see a list of problems that a 64 bit IDE could solve.

I immediately understood the new syntax at first glance. The syntax you proposed looked like broken code. Honestly I doubt there is any possible solution to this that would not cause someone to complain, but I am glad they didn't decide to override the function call syntax for this. Personally I am glad we are finally able to move beyond the 255 character limit and have a viable option for pasting in multiline content to be used as a string literal.

The closing quotes dictate the alignment, lines inside the string thus cannot be more left than the closing quotes, the last line does not have a trailing line break, if you want a trailing line break, add an empty line

Not quite the implementation I would have liked though. Triple quotes '''? Who came up with that? Is that copyied from another programming language? I mean, Pascal is said to be very verbous, so why not somehing more explicit like: blub := multiline(' line1 line2, indented line3 '); People who don't like verbosity would complain of course, but these would complain about Pascal syntax anyway. (Goes away, silently weeping and anticipating yet another long night trying to adapt the GExperts Source Formatter to yet another string syntax ...)

The process on Android is to: Check the checkbox for Camera permission in the Uses Permissions of the Project Options Request the permission at runtime, e.g: PermissionsService.RequestPermissions(['android.permission.CAMERA'], procedure(const APermissions: TClassicStringDynArray; const AGrantResults: TClassicPermissionStatusDynArray) begin if AGrantResults[0] = TPermissionStatus.Granted then // Permission was granted end );

BCB6 predates Visual Styles and VCL Styles and basically most modern UI practices. For example, when UI changes are animated by the OS or Styles, it would thus take multiple paint cycles to fully animate the complete state change, and ProcessMessages() or Update() may not (likely will not) catch all of the paint cycles in a single call. You can mitigate that somewhat by using thread pools, for instance. There is nothing in UI programming that says like "state change is finished and the UI for it is fully drawn". Not even back in BCB6's day. Although back then, drawing was much simpler, and usually completed in 1 paint cycle. That may not be the case anymore in modern UIs. That is not really a factor of the property itself, but in the UI rendering behind the scenes, so more oriented to differ between OS versions rather than compiler/VCL versions. Update() only processes paint messages that are already pending in the message queue. But you also need Invaliidate() to generate those messages in the first place, if they are not already generated for you. So that is where Repaint() comes into play, to signal that a new paint cycle is needed if it hasn't already been signaled.

This project deserves some attention (greenlets-coroutines, generators, channels and more). It is based on fibers.

What @DelphiUdIT said. Indy 10 does have .dpk package files for Delphi 7, namely: IndySystem70.dpk IndyCore70.dpk IndyProtocols70.dpk dclIndyCore70.dpk dclIndyProtocols70.dpk

Yikes. Nobody touches my screen! Not even myself. Besides touch screens add cost and complexity.

A TCheckBox with AllowGrayed set to true has three possible states; checked, unchecked, and grayed according to : http://www.delphigroups.info/2/6/245597.html I thought TRzCheckbox might have more, but the thread seems to think not... Edit: here's the VCL documentation on it: https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.StdCtrls.TCustomCheckBox.AllowGrayed

Received my new OV token from Digicert today - it is a SafeNet 5110+ FIPS token (thankfully) and I am able to automate signing with it 😅 I spent some time messing with a self signed certificate on a yubikey token over the last week, but cannot for the life of me figure out how to get it to sign without prompting for a password. This was just an experiment with the yubikey (which I already had for other purposes).