Remy Lebeau

Even if you could get it INSTALLED on XP, it won't RUN on XP. The IDE uses APIs and libraries that simply don't exist on XP.

In general, I could see this working if you connect the underlying TCP socket to the desired IP address, and then have the TLS handshake use the SNI extension to specify the desired domain name as the target for the certificate, and also have HTTP send a "Host" header specifying the same domain name. But I don't know if/how this can be done with THTTPClient, though. It is not doable with Indy's TIdHTTP (without hacking its source code) since everything uses the same hostname/IP specified in the URL.

This is covered in the documentation: http://docwiki.embarcadero.com/RADStudio/Sydney/en/10.4_Sydney_-_Release_2

Indy should definitely NOT be in the VCL unit scope. It is not setup that way in Indy's official repo, so that is something extra that Embarcadero must have setup on their end. Why, I could not answer that. Indy is available to both VCL and FMX without using separate unit scopes.

Why do people keep insisting on using the XE name for things that are not XE?!? Embarcadero stopped using the XE prefix after XE8. The current version is "10.4.2 Sydney", period. Did you read the Android 11 developer documentation? https://developer.android.com/about/versions/11 Google made behavioral changes: https://developer.android.com/about/versions/11/behavior-changes-all In particular: https://developer.android.com/about/versions/11/privacy/storage

Which version of Delphi are you using? $(Auto) is only supported in 10.4.1 and later.

Events are just properties, like any other. You can assign your event handlers like this: IdSMTP1 := TIdSMTP.Create(nil); ... IdSMTP1.OnWork := IdSMTP1Work; IdSMTP1.OnWorkBegin := IdSMTP1WorkBegin; IdSMTP1.OnWorkEnd := IdSMTP1WorkEnd; ...

Already exists: http://docwiki.embarcadero.com/RADStudio/en/Using_Namespaces_with_Delphi http://docwiki.embarcadero.com/RADStudio/en/Unit_Scope_Names

Yes, that is indeed odd. One would have hoped those helpers would have used WriteBuffer() instead of Write(), but they don't. Why knows why. Bad decision, IMHO.

Because drawing events are meant JUST for drawing, using the current UI state to decide what to draw. They are not meant for managing/updating the UI state. As long as you are changing the color/font of the Canvas that you are drawing onto, then that is perfectly fine. That is not UI state, that is just drawing state. On the other hand, changing the color/font of a UI control from inside a drawing event would be wrong, and can lead to endless repaint loops that eat up CPU cycles and slow down the UI message loop. Because that is NOT needed OR appropriate during a drawing event. That is for UI logic to handle instead, for instance in reaction to some action. Changing the visibility of a UI control will trigger a UI repaint to draw the updated UI display with/without the control in it. The drawing should account for the control's current state, not update its state.

It should not be working. Either it will pass the address of the Pointer itself rather than the address of the TRect, or else it will misinterpret the Pointer as a TBytes. Either way would be wrong. It needs to be either Write(r, sizeof(r)) or WriteData(@r, sizeof(r)).

Ideally, it should not compile. There are only 3 overloads of Write(), and that code does not logically match any of them: function Write(const Buffer; Count: Longint): Longint; overload; virtual; function Write(const Buffer: TBytes; Offset, Count: Longint): Longint; overload; virtual; function Write(const Buffer: TBytes; Count: Longint): Longint; overload; There is an overload of WriteData() that does match, though: function WriteData(const Buffer: Pointer; Count: Longint): Longint; overload; That being said, there is a known issue when passing a Pointer to Write(): https://delphihaven.wordpress.com/2012/09/30/potential-xe3-gotcha-dodgy-old-code-vs-new-tstream-overloads/ And that is the case here - as seen above, Write() is overloaded to accept either untyped or TBytes parameters. So, it is possible that sometime between Seattle and Sydney, Embarcadero finally fixed this bug in the compiler. Or, maybe it is just a matter of {$TYPEDADDRESS} being OFF in the Seattle code but ON in the Sydney code. As it should be,

Absolutely DO NOT EVER update UI state in a drawing event! It shouldn't be doing that at all. Get rid of it.

FMX's TBitmap has a Map() method for accessing the raw pixel data. Map() returns a TBitmapData, which has a GetScanline() method.

Here is a 3rd option: ... IdSMTP1 := TIdSMTP.Create(nil); try IdSSLIOHandlerSocketOpenSSL1 := TIdSSLIOHandlerSocketOpenSSL.Create(IdSMTP1); IdMessage1 := TIdMessage.Create(IdSMTP1); ... finally IdSMTP1.Free; end;

Indy is on GitHub: https://github.com/IndySockets/Indy/

Yes, it is. But I didn't notice that initially, I thought it was a String instead (which it should be).

I checked, and overload was added to TFileStream in Delphi 6, when the 3-parameter constructor for passing in Rights was introduced.

I'm aware of that. But I have never seen an example of anyone ever passing an existing file handle to a TFileStream constructor, only to a THandleStream constructor.

I didn't say it was wrong, just that it does not follow what Microsoft says to do.

I said to use THandleStream, not TFileStream. TFileStream does not have a constructor that accepts an external THandle as input. Unless that is a recent addition that has not been documented yet. Sure, eg: procedure TForm1.FormCreate(Sender: TObject); var lFile: THandle; lStrList: TStringList; lStream: THandleStream; lFileName: PChar; lAttrs: DWORD; begin lStrList := TStringList.Create; try ... lFileName := 'D:\temp\0104.txt'; lAttrs := GetFileAttributes(PChar(lFileName)); if lAttrs = INVALID_FILE_ATTRIBUTES then begin if GetLastError() <> ERROR_FILE_NOT_FOUND then RaiseLastOSError; lAttrs = FILE_ATTRIBUTE_NORMAL; end; lFile := CreateFile(lFileName, GENERIC_WRITE, FILE_SHARE_WRITE, nil, CREATE_ALWAYS, lAttrs, 0); if lFile = INVALID_HANDLE_VALUE then RaiseLastOSError; try lStream := THandleStream.Create(lFile); try lStrList.SaveToStream(lStream); finally lStream.Free; end; finally CloseHandle(lFile); end; finally lStrList.Free; end; end;

Yes, you should be able to simply configure the project's search/library paths to point at the Indy 10 source folders rather than the Indy 9 source folders.

That does not necessarily mean that is the interface's IP from the server's perspective for binding. That is just the IP that the LAN uses to reach the device. Do you get meaningful IPv6 addresses from Indy's GStack.GetLocalAddressList() method (not sure if it is implemented for Raspberry Pi)? Do you see that IP in the list?

From the CreateFile documentation: So, you don't have to actually remove the attributes, just match the existing attributes. Which FileCreate() can't do. But you could call CreateFile() directly, and then wrap the HANDLE in a THandleStream if needed.

You are not taking this change into account: Behavioral change to HTTPS handling in TIdHTTPServer When using non-default HTTP/S ports (as you are), you need to assign an OnQuerySSLPort event handler to tell TIdHTTPServer which port(s) you want to activate SSL/TLS on. In the older version, you could get away with not having that handler, but it is required now.