Remy Lebeau

Yeah, that is about what I found, too. Apparently, there aren't that many apps that actually support EXTRA_HTML_TEXT nowadays. You need an app password only if you don't use OAuth2 authentication, which is what Google wants you to use nowadays (well, they WANT you to use their own APIs, but if you have to use SMTP directly, use OAuth2). Indy's GitHub repo currently has a sasl-oauth branch which adds a few TIdSASL components for OAuth2, including Gmail's XOUATH2. You would still be responsible for implementing your own code to retrieve an OAuth2 token from Gmail (Indy doesn't have components for that purpose), but at least you could then have Indy use that token during SMTP authentication, no app password needed.

Ah, that issue, yes. I keep forgetting about that. Yes, that was originally a bug in Indy that was fixed in 2019 prior to the release of 10.4.

The RTL/VCL/FMX frameworks are much better supported in Classic, but spotty at best in Clang.

Wow, that was actually a half-decent response, for once.

There is a description in the PythonEngine source code: { A B C +-------------------++------------------------------------------------------+ | PyObject header || TPyObject class | +----------+--------++-----------------+------------+----------+------------+ |ob_refcnt |ob_type ||hidden Class Ptr |PythonType |IsSubType |PythonAlloc | |integer |pointer ||pointer |TPythonType |Boolean |Boolean | |4 bytes |4 bytes ||4 bytes |4 bytes |1 byte |1 byte | +----------+--------++-----------------+------------+----------+------------+ ^ ^ | | ptr returned ptr returned by Adjust by GetSelf - a Python object must start at A. - a Delphi class class must start at B - TPyObject.InstanceSize will return C-B - Sizeof(TPyObject) will return C-B - The total memory allocated for a TPyObject instance will be C-A, even if its InstanceSize is C-B. - When turning a Python object pointer into a Delphi instance pointer, PythonToDelphi will offset the pointer from A to B. - When turning a Delphi instance into a Python object pointer, GetSelf will offset Self from B to A. - Properties ob_refcnt and ob_type will call GetSelf to access their data. } Internally, Adjust() calls PythonToDelphi(): procedure TPyObject.Adjust(PyPointer: Pointer); var ptr : PNativeInt; begin ptr := PyPointer; ptr^ := NativeInt(PythonToDelphi(PPyObject(ptr^))); end; function PythonToDelphi( obj : PPyObject ) : TPyObject; begin if IsDelphiObject( obj ) then Result := TPyObject(PAnsiChar(obj)+Sizeof(PyObject)) else raise EPythonError.CreateFmt( 'Python object "%s" is not a Delphi class', [GetPythonEngine.PyObjectAsString(obj)] ); end; I have no idea.

The FIdSSLIOHandler.PassThrough property is True by default, so the connection is treated as a plain TCP connection. You need to set the PassThrough property to False to initialize the TLS handshake. So, that is why you are getting the error on your 1st Send(). Your application data is the 1st thing being transmitted, so the server is mistaking that as the TLS handshake, hence the error. You can set the PassThrough to False either before calling Connect() (ie, for implicit TLS, sending the handshake as soon as the TCP connection is established) or afterwards (ie, for explicit TLS, to allow for a protocol-level STARTTLS-style command before sending the handshake): procedure myFoo; var FIdTCPClient : TIdTCPClient; FIdSSLIOHandler : TIdSSLIOHandlerSocketOpenSSL; begin FIdTCPClient := TIdTCPClient.Create; FIdTCPClient.Host := '10.10.10.10'; FIdTCPClient.Port := 10007; FIdSSLIOHandler := TIdSSLIOHandlerSocketOpenSSL.Create; FIdSSLIOHandler.SSLOptions.Mode := sslmClient; FIdSSLIOHandler.SSLOptions.VerifyMode := []; FIdSSLIOHandler.SSLOptions.VerifyDepth := 0; FIdSSLIOHandler.SSLOptions.SSLVersions := [sslvTLSv1_2]; FIdTCPClient.IOHandler := FIdSSLIOHandler; FIdSSLIOHandler.PassThrough := False; // <-- either here FIdTCPClient.Connect; // <-- will send the handshake if PassThrough is False FIdSSLIOHandler.PassThrough := False; // <-- or here, optionally after sending a STARTTLS command FIdTCPClient.Send([0,1,2,3]); end; That is because you are explicitly setting Sock.SslEnable to True and then calling Sock.StartSslHandshake() after calling Sock.Connect(). You are not doing the equivalent with Indy. No, it is a bug in your code. You are telling ICS to initiate the TLS handshake, but you are not telling Indy to do the same. This is not a new issue in 11.3. This is how Indy has always behaved. Yes - the PassThrough property. OpenSSL DLLs that are known to work with Indy are available in Indy's GitHub repo: https://github.com/IndySockets/OpenSSL-Binaries

That is not what I suggested. I suggested putting plain text (no HTML code) in EXTRA_TEXT, and HTML code in EXTRA_HTML_TEXT. I doubt it. You will likely have to import it manually. Importing an Android Class For Use in Delphi Convert any Android API to Delphi and C++ Builder units to utilize in your FireMonkey Android Projects Once you have it imported properly, I think it would just be as simple as: Intent.putExtra(TJIntent.JavaClass.EXTRA_HTML_TEXT, TJHtml.JavaClass.fromHtml(StringToJString(sMessageBody), 0) );

What about it?

You don't need to pass in NativeUInt indexes to begin with. You are passing in 2 very small values (offset and bit count) which you can bit-stuff into a plain Integer just fine (and pay attention that you are using hex values correctly!), eg: type STRUCT_PSAPI_WORKING_SET_BLOCK = record private Flags: ULONG_PTR; function GetBits(const aIndex: Integer): ULONG_PTR; procedure SetBits(const aIndex: Integer; const aValue: ULONG_PTR); public property Protection: ULONG_PTR index $0005 read GetBits write SetBits; // 5 bits at offset 0 property ShareCount: ULONG_PTR index $0503 read GetBits write SetBits; // 3 bits at offset 5 property Shared: ULONG_PTR index $0801 read GetBits write SetBits; // 1 bit at offset 8 property Reserved: ULONG_PTR index $0903 read GetBits write SetBits; // 3 bits at offset 9 {$IFDEF WIN64} property VirtualPage: ULONG_PTR index $0C34 read GetBits write SetBits; // 52 bits at offset 12 {$ELSE} property VirtualPage: ULONG_PTR index $0C14 read GetBits write SetBits; // 20 bits at offset 12 {$ENDIF} end; function MakeMask(NumBits: UInt8): ULONG_PTR; var I: UInt8; begin Result := 0; for I := 1 to NumBits do begin Result := (Result shl 1) or 1; end; end; // depending on C compiler implementation, you might need to // reverse the math on these bit shifts, as bitfield ordering // is not standardized! function STRUCT_PSAPI_WORKING_SET_BLOCK.GetBits(const aIndex: Integer): ULONG_PTR; var Offset: NumBits: UInt8; Mask: ULONG_PTR; begin Offset := UInt8(aIndex shr 8); NumBits = UInt8(aIndex); Mask := MakeMask(NumBits); Result := (Flags shr Offset) and Mask; end; procedure STRUCT_PSAPI_WORKING_SET_BLOCK.SetBits(const aIndex: Integer; const aValue: ULONG_PTR); var Offset: NumBits: UInt8; Mask: ULONG_PTR; begin Offset := UInt8(aIndex shr 8); NumBits = UInt8(aIndex); Mask := MakeMask(NumBits); Flags := Flags and not (Mask shl Offset); Flags := Flags or ((aValue and Mask) shl Offset); end; That being said, I would have translated each bitfield into its own getter/setter instead, to more closely mimic how bitfields actually work in C, and to pass around more appropriate data types, eg: type VirtualPageValueType = {$IFDEF WIN64}UInt64{$ELSE}UInt32{$ENDIF}; _PSAPI_WORKING_SET_BLOCK_STRUCT = record private Flags: ULONG_PTR; function GetProtection: UInt8; function GetShareCount: UInt8; function GetShared: Boolean; function GetReserved: UInt8; function GetVirtualPage: VirtualPageValueType; procedure SetProtection(const AValue: UInt8); procedure SetShareCount(const AValue: UInt8); procedure SetShared(const AValue: Boolean); procedure SetReserved(const AValue: UInt8); procedure SetVirtualPage(const AValue: VirtualPageValueType); public property Protection: UInt8 read GetProtection write SetProtection; property ShareCount: UInt8 read GetShareCount write SetShareCount; property Shared: Boolean read GetShared write SetShared; property Reserved: UInt8 read GetReserved write SetReserved; property VirtualPage: VirtualPageValueType read GetVirtualPage write SetVirtualPage; end; _PSAPI_WORKING_SET_BLOCK = record case Integer of 0: (Flags: ULONG_PTR); 1: (Struct: _PSAPI_WORKING_SET_BLOCK_STRUCT); end; PSAPI_WORKING_SET_BLOCK = _PSAPI_WORKING_SET_BLOCK; PPSAPI_WORKING_SET_BLOCK = ^STRUCT_PSAPI_WORKING_SET_BLOCK; ... // Notes: // // hex | binary // --------------------------- // $01 | %0000_0001 // $07 | %0000_0111 // $1F | %0001_1111 // $FFFFF | %1111_1111_1111_1111_1111 // $FFFFFFFFFFFFF | %1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111 // // depending on C compiler implementation, you might need to // reverse the math on these bit shifts, as bitfield ordering // is not standardized! function _PSAPI_WORKING_SET_BLOCK_STRUCT.GetProtection: UInt8; begin Result := UInt8(Flags and $1F); end; function _PSAPI_WORKING_SET_BLOCK_STRUCT.GetShareCount: UInt8; begin Result := UInt8((Flags shr 5) and $07); end; function _PSAPI_WORKING_SET_BLOCK_STRUCT.GetShared: Boolean; begin Result := ((Flags shr 8) and $01) <> 0; end; function _PSAPI_WORKING_SET_BLOCK_STRUCT.GetReserved: UInt8; begin Result := UInt8((Flags shr 9) and $07); end; function _PSAPI_WORKING_SET_BLOCK_STRUCT.GetVirtualPage: VirtualPageValueType; const cMask: ULONG_PTR = {$IFDEF WIN64}$FFFFFFFFFFFFF{$ELSE}$FFFFF{$ENDIF}; begin Result := VirtualPageValueType((Flags shr 12) and cMask); end; procedure _PSAPI_WORKING_SET_BLOCK_STRUCT.SetProtection(const AValue: UInt8); begin Flags := Flags and not $1F; Flags := Flags or (ULONG_PTR(aValue) and $1F); end; procedure _PSAPI_WORKING_SET_BLOCK_STRUCT.SetShareCount(const AValue: UInt8); begin Flags := Flags and not ($07 shl 5); Flags := Flags or ((ULONG_PTR(aValue) and $07) shl 5); end; procedure _PSAPI_WORKING_SET_BLOCK_STRUCT.SetShared(const AValue: Boolean); begin if AValue then Flags := Flags or (ULONG_PTR(1) shl 8) else Flags := Flags and not ($1 shl 8); end; procedure _PSAPI_WORKING_SET_BLOCK_STRUCT.SetReserved(const AValue: UInt8); begin Flags := Flags and not ($07 shl 9); Flags := Flags or ((ULONG_PTR(aValue) and $07) shl 9); end; procedure _PSAPI_WORKING_SET_BLOCK_STRUCT.SetVitualPage(const AValue: VirtualPageValueType); const cMask: ULONG_PTR = {$IFDEF WIN64}$FFFFFFFFFFFFF{$ELSE}$FFFFF{$ENDIF}; begin Flags := Flags and not (cMask shl 12); Flags := Flags or ((ULONG_PTR(aValue) and cMask) shl 12); end;

DateTimeToStr() calls DateTimeToString() with its Format parameter set to a blank string, which will set the Format to 'C' as a default: When formatting a time value, milliseconds will be output only if the format string includes the 'Z' placeholder. But there is currently no logic to handle the decimal separator, so yes, if the format string has something like '.ZZZ' then the '.' will be output as-is as a literal character, not translated to TFormatSettings.DecimalSeparator. Sounds reasonable. That kind of information should be stated in the bug report. I have added a comment about it.

If you include EXTRA_HTML_TEXT, that is supposed to be an alternative format to the plain text in EXTRA_TEXT. So maybe don't put HTML code in EXTRA_TEXT if you also put it in EXTRA_HTML_TEXT? Note that not all (or very few?) email apps actually support EXTRA_HTML_TEXT, which is why EXTRA_TEXT is also required. So it could be that on your device, EXTRA_HTML_TEXT is being ignored and displaying EXTRA_TEXT as plain text instead, which might explain why you are seeing the HTML code as plain text instead of as formatted text. Also, when adding HTML code to EXTRA_TEXT or EXTRA_HTML_TEXT, try passing it through the Html.FromHtml() method first, rather than adding it as a plain string.

Are you referring to this ticket? [RSP-41434] StrToDateTime uses Decimalseparator for microseconds There is not much useful information provided in that ticket, and certainly not a reproducible example. I can imagine Embarcadero closing the ticket as "not reproducible" or "works as designed". Also, you filed the ticket as a bug (which it is not, IMHO, at least not the way you described it), but you are proposing a new feature at the end, so you should have filed the ticket as a Feature Request instead of as a Bug. In any case, I don't understand what the actual problem is. You say in the ticket: ScanTime() uses TFormatSettings.DecimalSeparator to parse milliseconds, so what is stopping you from specifying a custom separator when parsing a string? var Fmt: TFormatSettings; Fmt := TFormatSettings.Create; Fmt.TimeSeparator := ':'; Fmt.DecimalSeparator := '!'; StrToDateTime('12:34:56!789', Fmt); I don't see that being necessary at all. Especially since most platforms don't define such a separator in their respective environments anyway, AFAIK.

Some UI controls do, and some do not. A TLabel control does not have a Clear() method, in either VCL or FMX. Also, VCL's TLabel does not have a Text property, it has a Caption property instead: labelAnswer->Caption = ""; On the other hand, FMX's TLabel does have a Text property. VCL's TEdit does have a Clear() method: Edit1->Clear(); FMX's TEdit, on the other hand, does not. However, it does have SelectAll() and DeleteSelection() methods instead: Edit1->SelectAll(); Edit1->DeleteSelection();

Maybe not in your code, but who knows what the VCL does internally. MainFormOnTaskbar=true does some really funny things. In any case, have you tried verifying with GetWindowLongPtr(GWL_EXSTYLE) or Spy++ or equivalent that your affected windows don't actually have that style when you are not expecting it? Just a thought. Can you produce a bare-bones test project with minimal code that reproduces the behavior?

Not even if you edit the Registry to add that command-line parameter to the file association that launches the IDE?

The expression: ch + " is " + chValue Does not do what you think it does. It does not perform string concatenation, it actually performs pointer arithmetic instead. The string literal " is " is a 'const char[5]' array, which in this context will decay into a 'const char*' pointer to its 1st character. You are adding a 'char' and an 'int' (both integer types) to that pointer, moving around where it points in memory. So, for example, if 'A' is entered, then you are advancing the pointer forward in memory by 65+65=130 characters. And then, you are assigning that final pointer to the Label->Caption, which is why you end up with garbage output. If you are going to append integer values to strings, make sure you append them to String objects, not to char* pointers. AnsiString and UnicodeString have overloaded constructors for converting various data types, including integers, eg: Char ch = EditCharacterEntry->Text[1]; int chValue = static_cast<int>(ch); LabelAnswer->Caption = ch + String(" is ") + chValue; Alternatively, you can convert the integers to String object before concatenating them, eg: Char ch = EditCharacterEntry->Text[1]; int chValue = static_cast<int>(ch); LabelAnswer->Caption = String(ch) + " is " + String(chValue); // or IntToStr(chValue) Alternatively, use a function that to designed for formatting strings from different types of inputs, such as Sysutils::Format() or String::sprintf(), eg: Char ch = EditCharacterEntry->Text[1]; int chValue = static_cast<int>(ch); LabelAnswer->Caption = Format("%s is %d", ARRAYOFCONST((ch, chValue))); or LabelAnswer->Caption = String().sprintf(_D("%c is %d"), ch, chValue);

It is equally important to make sure that only the remote ends of the pipe are actually inherited, not the local ends, or else you won't be able to handle the pipes being closed correctly when the child process exits. And also, be careful if you call CreateProcess() multiple times with bInheritHandles=TRUE, as each child process may end up inheriting handles you didn't intend for it to inherit. Vista addressed that issue with the PROC_THREAD_ATTRIBUTE_LIST option of STARTUPINFOEX: Programmatically controlling which handles are inherited by new processes in Win32 Another way to create a process with attributes, maybe worse maybe better

Your code snippet is declaring a variable named TitleInfo, but you are sending WM_GETTITLEBARINFOEX with a pointer to a variable named TitleBarInfoEx instead. Also, make sure you initialize the TTitleBarInfo/Ex.cbSize member before sending WM_GETTITLEBARINFOEX. https://learn.microsoft.com/en-us/windows/win32/menurc/wm-gettitlebarinfoex https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-gettitlebarinfo So, try this instead: var TitleInfo : TTitleBarInfoEx; ... begin ... TitleInfo.cbSize := SizeOf(TitleInfo); // <-- ADD THIS! SendMessage(Handle, WM_GETTITLEBARINFOEX, 0, LPARAM(@TitleInfo)); ... end;

Are you switching between actual Win32 desktop, or virtual desktops? They are very different things. A window cannot be moved between Win32 desktops, it exists only in the desktop in which it was created. A window can be freely moved between virtual desktops, either by user action, or by code calling the IVirtualDesktopManager.MoveWindowToDesktop() method. Note, a window can appear in multiple desktops: https://learn.microsoft.com/en-us/answers/questions/611694/windows-virtual-desktops Another interesting tidbit: https://superuser.com/questions/950960/pin-applications-to-multiple-desktops-in-windows-10 Do your Forms in question have their BorderStyle set to bsToolWindow or bsSizeToolWin, by chance?

Using UnicodeString::operator[] to index outside of the bounds of the string (< 1, or > Length()) will throw an ERangeError exception.

Like any other string type, UnicodeString is an array of characters. You can index into individual characters, eg: // UnicodeString is 1-based, not 0-based! System::Char ch = EditCharacterEntry->Text[1]; int chValue = static_cast<int>(ch); Note that UnicodeString is a UTF-16 encoded string, where System::Char is a UTF-16 codeunit. It is wchar_t on Windows and char16_t on other platforms. If you need the 8-bit 'char' type specifically, you will have to perform a Unicode->ANSI data conversion at runtime, eg: // AnsiString is also 1-based! char ch = AnsiString(EditCharacterEntry->Text)[1]; int chValue = static_cast<int>(ch); Note that such a conversion is potentially lossy for non-ASCII characters > 127. AnsiString uses the caller's default codepage, so you will lose data if the UnicodeString holds Unicode characters that are not present in that codepage. You can use AnsiStringT<T> instead if you need to specify a specific codepage, eg: // AnsiStringT is also 1-based! // 28591 = ISO-8859-1, see https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers char ch = AnsiStringT<28591>(EditCharacterEntry->Text)[1]; int chValue = static_cast<int>(ch); Note that UTF8String is an alias for AnsiStringT<65001>.

The main project file should be a .cpp file without an associated .h[pp] file, and then each Unit in the project is a .cpp+.h[pp] pair (or a .cpp/.h[pp]/.dfm triplet if the Unit is a TForm/TFrame/TDataModule).

You did not show your code that is using TThreadDataInterface_TS, but I would assume a bug in your code before I would assume a bug in the standard library. This kind of random behavior is a good indicator that your code is experiencing undefined behavior. Perhaps you are calling Write_TS() on an invalid TThreadDataInterface_TS object? Maybe some piece of code has previously corrupted memory and TThreadDataInterface_TS is the unwitting victim? There are many possibilities. But they all stem from one fact - you have a bug SOMEWHERE in your code, and this behavior is the RESULT of that bug.

The IDE does not create header files with a .cpp extension, so you must have done that manually at some point.

SAVE - save the current unit file using its current filename. SAVE AS - save the current unit file using a new filename. SAVE PROJECT AS - save the current project using a new filename. SAVE ALL - save the current project and all unit files using their current filenames. Correct to both. Save one file/unit, vs save all files/units. Save whenever you want. But, consider also enabling the IDE's auto-save options, too: https://docwiki.embarcadero.com/RADStudio/en/Saving_and_Desktop