Remy Lebeau

You can either: not assign the OnClick handler at design-time, but at runtime instead after you are done initializing the control. set a variable somewhere that the event handler can look at, and then clear that variable when finished.

I don't understand what you are describing. Please clarify. What EXACTLY is not working? What steps did you take to set it up, and what steps did you take to see that it is not working?

To elaborate, only the Unicode version of CreateProcess() requires the 2nd parameter to point at writable memory, as it may have to internally normalize/alter the Unicode string. This is documented behavior. In this example, sCommand is pointing at a string literal (ie, its RefCnt is -1), so the compiler won't allocate a block of writable memory for sCommand unless it is modified (ie, copy-on-write semantics), which this code doesn't do. So the UniqueString() is used to ensure that sCommand is pointing at a unique and writable string in memory (ie, its RefCnt is 1). If you use string variables to build up sCommand, then the UniqueString() won't be needed since the resulting string will be unique and writable, eg: var sProgram, sFilename, sCommand: string; sProgram := 'C:\PDF\pdftotext.exe'; sFilename := 'C:\PDF\ABC.PDF'; sCommand := '"' + sProgram + '" "' + sFilename + '"'; // or: sCommand := Format('"%s" "%s"', [sProgram, sFilename]); // etc...

If you are using strictly ASCII characters only, then no. All of the default settings should suffice. But, if you are using any non-ASCII characters, then make sure both client and server agree on a common byte encoding on the wire, ie UTF-8. You can use the TIdIOHandler.DefStringEncoding property, or the AByteEncoding parameter on individual read/write methods. Indy will convert Unicode to wire encoding on writes, and from wire encoding to Unicode on reads. In the D2007 code, you should also tell Indy which encoding your AnsiString's are using, if different than the OS default. You can use the TIdIOHandler.DefAnsiEncoding property, or the ADestEncoding/ASrcEncoding parameter on individual read/write methods, respectively. Indy will convert ANSI to Unicode to wire encoding on writes, and from wire encoding to Unicode to ANSI on reads.

You don't need to use RawToBytes() in this case. The TIdIOHandler.Write(string) method has an optional ADestEncoding parameter to specify the byte encoding on the wire, such as UTF-8 (the default is ASCII). You can alternatively use the TIdIOHandler.DefStringEncoding property. And, in pre-Unicode versions, Write() also has an optional ASrcEncoding parameter to specify the byte encoding of the input AnsiString (the default is the user's OS default). Or, you can alternatively use the TIdIOHandler.DefAnsiEncoding property.

Why are you using ShellExecute() to run pdftotext.exe indirectly via cmd.exe, instead of using CreateProcess() to run pdftotext.exe directly? Try something more like this: procedure TForm1.Button1Click(Sender: TObject); var sCommand: string; si: TStartupInfo; pi: TProcessInformation; begin sCommand := '"C:\PDF\pdftotext.exe" "C:\PDF\ABC.PDF"'; UniqueString(sCommand); ZeroMemory(@si, sizeof(si)); si.cb := sizeof(si); si.dwFlags := STARTF_USESHOWWINDOW; si.wShowWindow := SH_HIDE; if CreateProcess(nil, PChar(sCommand), nil, nil, False, CREATE_NO_WINDOW, nil, nil, si, pi) then begin CloseHandle(pi.hThread); CloseHandle(pi.hProcess); end; end;

Then try changing it from System.SysInit to just SysInit.

You have to analyze the certificate provided, and check whether or not its attributes match your desired criteria. Error 20 is X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY: Error 21 is X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE: See: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_verify.html https://www.openssl.org/docs/man1.0.2/man3/X509_STORE_CTX_get_error.html Sure, because you are telling OpenSSL that you deemed the certificate OK to use, even if OpenSSL thinks otherwise. Because OpenSSL pre-checks the certificate before letting you do your own checks on it. So, if OpenSSL doesn't think the certificate is OK, and you do nothing to override that decision, then the certificate is not usable and the handshake fails. Verifying the peer's identity is a separate operation from encryption. The peers have to trust each other before they exchange encryption keys with each other.

Alternatively, there are many color constants defined in the Vcl.Graphics and System.UITypes units. The Vcl.Graphics.clWebOrange constant maps to the System.UITypes.TColorRec.Orange constant, which has a numeric value of $00A5FF (ie, RGB(255, 165, 0)), which is almost identical to your desired RGB color.

Have you tried enabling the sslvrfPeer flag in the sslIO.SSLOptions.VerifyMode property?

What are the actual error messages? Changes are, those components are linked to the version of Indy that is pre-installed with the IDE, and will need to be recompiled if you install a different version of Indy, as a few method signatures did change to accommodate the OAuth SASL. That is odd, not sure what to make of that.

Have you considered using TCP/UDP sockets? Indy ships with Delphi and runs on both Windows and Android.

This is documented in Embarcadero's DocWiki: Nested Type Declarations

Extended RTTI via the System.Rtti unit was introduced in Delphi 2010. Why filter by visibility rather than by writability? if (LRttiProperty <> nil) and LRttiProperty.IsWritable then

I tend to stay away from those functions since they use Variant, which is usually unnecessary overhead. But it depends on your particular needs. Integral properties are handled by GetOrdProp() and SetOrdProp() (as in, Ordinal)

You can't take a pointer to a property, like you are trying to do. You should look into using RTTI instead. Someone else was asking a similar question on StackOverflow just yesterday: https://stackoverflow.com/questions/76729720/how-do-i-get-a-pointer-to-a-property-in-delphi

They are. But Delphi automatically handles reference counting for interfaces, whereas C++ does not, hence the use of _di_... smart pointers on the C++ side to mimic the Delphi behavior.

Has anyone else noticed that lately, when quoting a message in a reply, then placing the cursor inside the quote and pressing Enter a few times, no longer splits up the quote into 2 quotes with editable whitespace between them? It used to do this, and it was a very handy feature, but lately it hasn't been working for me, and it makes replying to quotes much more difficult. Now I have to do a lot of copy/pasting and dragging around of quotes to get the same result that inserting Enters used to accomplish.

I was not aware of that option. Or maybe I was but wasn't using it. I just now tried it and it works, so I guess I'll start using it 😉

And rename the new project, of course 😁

I think you meant SetWindowLongPtr() instead.

It's been a long time since I tried this, but it used to be that if you simply didn't have any project loaded in the IDE and then edited the Project Options, they would save as defaults. Not sure if that is still the case nowadays. Another approach would be to create Option Sets that contain your desired settings, and then you can apply those Sets to new projects as needed. https://docwiki.embarcadero.com/RADStudio/en/Option_Sets_Overview

Didn't used to be 😞 Used to be able to just quote an entire message and then break it up as I address each part of it. I can still accomplish that, but it's several more steps now, so more tedious, but I'm getting the hang of it. Still has some ugly quirks, though. I suppose so. Other forums have that option. Would like the original functionality back, though. But this added as a new separate feature could be useful, too. Depends on how big the selections are. Quoting a few sentences, sure. Quoting paragraphs/code snippets, maybe not so much, if you have to scroll to make the selection.

Yes, certainly. And very much as you described it. You have a base component class named TSQLBuilderProvider, which has virtual/abstract methods as needed. Then you derive several DB-specific classes from it, which implement those methods. Each class can have its own DB-specific properties as needed. Then you have a TSQLBuilder component, which has a published property of type TSQLBuilderProvider. Now, you can drop a TSQLBuilder component and a DB-specific TSQLBuilderProvider component onto your Form, and assign the Provider to the Builder. And then the Builder can use the abstract/virtual methods to interact with the Provider. For that, it would make sense to expose additional properties on each DB-specific Provider component. TSQLBuilderProviderFD could have published properties to assign TFDConnection and TFDQuery components to. TSQLBuilderProviderUni could have published properties to assign TUniConnection and TUniQuery components to. And so on. Then the implemented methods can use those properties as needed. Yes. That is basically what I described above. That is why they should be exposed by the individual Provider components, not by the Builder component.

Next time, read the documentation, and also just look at the declarations (ie, the DocumentElement property returns an _di_IXMLNode, not an IXMLNode*). Typically no, although you can do so manually if you want to, ie, to free the array's memory when you want to reuse the variable for a new array. Yes. The array's memory is freed when the object goes out of scope, or is reassigned. Just any any other good RAII-style class does. Yes No