Remy Lebeau

You chopped off some of the error message. It is complaining that the "protocol version" is not accepted. Even though you are setting the version to TLS 1.2, chances are that Indy or OpenSSL is falling back to TLS 1.0 or 1.1 instead, which will fail if the server actually requires TLS 1.2. Also, something else to consider - even if TLS 1.2 were being used correctly, most TLS 1.2 servers nowadays require clients to use the SNI extension to send the requested hostname in the TLS handshake (so appropriate certificates can be used), but Indy 10.5.9 did not support SNI. So upgrading to an up-to-date Indy version will gain you that feature. 10.5.9 is VERY old. Even if you don't update Delphi/Indy,, you should at least make sure you are using an updated OpenSSL. The last version of OpenSSL that Indy 10.6.2 officially supports is 1.0.2u (1.0.2.21). Support for OpenSSL 1.1+/3.0 is a WIP (https://github.com/IndySockets/Indy/pull/299), if you want to try it.

Nothing in Indy depends on that package. Double-check that your DPK and DPROJ files didn't pick up something unexpected by accident.

Nothing in Indy depends on that package. Double-check that your DPK and DPROJ files didn't pick up something unexpected by accident.

Offhand, the code you have shown looks OK (except for the potential memory leaks), but I can't really answer your question, because you didn't show how you are obtaining the token in the first place, or what settings you have used for it.

Yes. This works for me: procedure TForm1.Button11Click(Sender: TObject); var MyXMLDocument : IXMLDocument; DocElement, FounderNode : IXMLNode; begin MyXMLDocument := NewXMLDocument(); MyXMLDocument.Active := True; DocElement := MyXMLDocument.CreateElement('ab', 'MyString'); MyXMLDocument.DocumentElement := DocElement; // alternatively: // DocElement := MyXMLDocument.AddChild('ab', 'MyString'); DocElement.DeclareNamespace('xsi', 'https://www.guru99.com/XMLSchema-instance'); DocElement.DeclareNamespace('xsd', 'https://www.guru99.com/XMLSchema'); // if this call is present then the 'xmlns=MyString' attribute will be at the end of the element, // but if this is omitted then the attribute will be at the front of the element instead, due to // the earlier CreateElement/AddChild call... DocElement.DeclareNamespace('', 'MyString'); FounderNode := DocElement.AddChild('founder'); FounderNode.Text := 'Krishna'; MyXMLDocument.SaveToFile('TestOne01.XML'); end; It is important that the 'ab' element actually have the 'MyString' namespace assigned to it, so that any child nodes can inherit it. When an `xmlns` attribute appears on a child node, it means the namespace was not inherited correctly.

The only HWND available in FMX comes from the TForm itself. Child controls do not have their own HWNDs. You can get the Form's HWND by using either WindowHandleToPlatform() or FormToHWND() in the FMX.Platform.Win unit. Otherwise, if you want a child control that has an HWND, you will have to create it yourself using the Win32 API CreateWindow/Ex() API directly.

That will only work for TForm handles (and alternatively, you can use FormToHWND() instead). In FMX, only a TForm has an actual Win32 HWND assigned, its child control do not have their own HWNDs, like they do in VCL. FMX child control are custom-drawn directly onto the TForm's window.

That line should be this instead: MyXMLDocument.DocumentElement.DeclareNamespace('', 'MyString'); Which is equivalent to this: MyXMLDocument.DocumentElement.SetAttributeNS('xmlns', 'http://www.w3.org/2000/xmlns/', 'MyString'); The DeclareNamespace() documentation does not mention that the Prefix parameter can be a blank string, but it is actually supported. This will treat the attribute as an actual namespace declaration in the DOM, even though it doesn't have a prefix assigned. It should also assign the 'MyString' namespace to the DocumentElement since that element doesn't have a prefix assigned, either. You are creating the element, but you are not assigning any text to it, which is why the element appears as </founder>. You need to add this after calling AddChild(): FounderNode.Text := 'Krishna'; Also, you may or may not need to specify the desired namespace when calling AddChild(), as well (this part I always forget about when exactly a namespace should be specified and when it can be inherited from the parent element - once you start dealing with namespaces in XML, you will find that you need to specify namespaces in add/insert and search operations more often than not): FounderNode := MyXMLDocument.DocumentElement.AddChild('founder', 'MyString');

If that is the case, if each event is its own HTTP chunk, then you can use the TIdHTTP.OnChunkReceived event to handle the stream events. At the moment, you still have to provide a TStream in order for the OnChunkReceived event to fire (I may change that in the future), but you can use TIdEventStream with no event hanlders assigned so that the chunks written to the stream are ignored.

That is a VERY old version of Indy. Indy has been in 10.6.2.x since 2015. You should seriously consider upgrading to the latest version from Indy's GitHub repo.

Seems you already asked this on StackOverflow, and a few answers were posted there: https://stackoverflow.com/questions/74422756/

Seems to be. I can't access anything on alpha.mike-r.com, so it must be down. I'm sure you can find another QOTD server online somewhere. There are a few mentioned on the bottom on https://wiki.freepascal.org/QOTD, for instance. Just look around.

Why are you trying to send JSON? That is not what Microsoft's documentation tells you to send: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow#redeem-a-code-for-an-access-token The body is NOT to be JSON at all. It needs to be a '&'-delimited list of 'name=value' pairs instead. The TIdHTTP.Post() method handles the 'application/x-www-form-urlencoded' format for you, but only if you give it a TStrings (like TStringList), not a TStream, eg: requestBody := TStringList.Create; requestBody.Add('grant_type=client_credentials'); requestBody.Add('client_id=xxx'); requestBody.Add('client_secret=_xxx_'); requestBody.Add('scope=https://graph.microsoft.com/.default'); url := 'https://login.microsoftonline.com/' + TenantID + '/oauth2/v2.0/token'; FLastResult := IdHTTP.Post(url, requestBody);

I have implemented this kind of logic before, but only in plain socket code (though I suppose it can be applied to socket libraries like ICS or Indy, too). It requires the TLS server to peek not recv the first few bytes of a new connection, and only if those bytes belong to the header of a TLS handshake then enable TLS on that connection (allowing the previously-peeked bytes to now be read by whatever TLS library you use), otherwise don't enable TLS on the connection and just read the connection raw.

The screenshot you provided appears to be an actual websocket event. 'text/event-stream' is just a stream of linebreak-delimited events. TIdHTTP is not currently designed to handle that kind of stream. Using TIdEventStream is going to give you arbitrary blocks of data as they are read off the socket, which you are assuming are complete events, but that is not guaranteed (or even likely) to happen. To be safe, you would have to buffer the stream data, break it up on linebreaks as they become available, and decode only complete events as UTF-8. The code you have presented has the potential to decode incomplete events. In this type of situation, it would be useful if TIdHTTP had a flag available to tell it not to read the response body at all and just exit, letting the caller then read the body from the IOHandler directly as needed. Similar to the existing hoNoReadMultipartMIME and hoNoReadChunked flags, but for other kinds of responses. Such a flag does not exist at this time.

That is only part of the response, and not even the relevant part, eihter. That snippet shows that you are requesting an unencrypted HTTP url and being redirected to an encrypted HTTPS url, but it is not showing the contents of the subsequent HTTPS request or its response, which contains the actual event data.

Those are the wrong settings to use when attachments are involved. You should read the following articles on Indy's blog (just ignore the portions about HTML): https://www.indyproject.org/2005/08/17/html-messages/ https://www.indyproject.org/2008/01/16/new-html-message-builder-class/ In your situation, you need to set the top-level ContentType to 'multipart/mixed' instead, and then add the plain text as a TIdText object in the TIdMessage.MessageParts collection, and the PDF as a TIdAttachmentFile object in the TIdMessage.MessageParts collection, for example: IdMessage1.ContentType := 'multipart/mixed'; with TIdText.Create(IdMessage1.MessageParts, nil) do begin ContentType := 'text/plain'; CharSet := 'utf-8'; Body.Text := 'Tässä on ääkkösiä ja liite'; end; with TIdAttachmentFile.Create(IdMessage1.MessageParts, '<path to>\1.pdf') do begin ContentType := 'application/pdf'; end; The helper TIdMessageBuilderPlain class can set that up correctly for you, for example: Builder := TIdMessageBuilderPlain.Create; try Builder.PlainText.Text := 'Tässä on ääkkösiä ja liite'; Builder.PlainTextCharSet := 'utf-8'; Builder.Attachments.Add('<path to>\1.pdf').ContentType := 'application/pdf'; Builder.FillMessage(IdMessage1); finally Builder.Free; end; By setting the top-level ContentType to 'text/plain', you are telling email readers to interpret the email's entire content as just one big plain text document, rather than letting them parse the content for attachments, etc. The default AttachmentEncoding is 'MIME', you should leave it at that. UUE was popular way back in the days of Usenet groups, but nobody uses those anymore. MIME is the dominant encoding used nowadays.

Since the data is streaming, there is no guarantee that the data that is available during each firing of the TIdHTTP.OnWork event will represent a complete line of data. It could be partial data. At the very least, I would not suggest using the Memo's LoadFromStream() method, which replaces the entire contents of the Memo on each call. It would be better to convert each event's data to a raw string and then append it to (not replace) the Memo's current text, which can be done efficiently using its SelStart/SelLength/SelText properties. But, more importantly, the TMemoryStream that you are having TIdHTTP write to will just keep receiving more and more data that you are never discarding from memory, so the stream's memory usage will keep growing over time, until memory runs out eventually. If you want to process the data in chunks as it is arriving, I would suggest using a TIdEventStream instead, replacing the TIdHTTP.OnWork event handler with a TIdEventStream.OnWrite event handler instead. You will be given access to the actual bytes per event as a dynamic array, which means you can simply increment the array's refcount, send the array pointer to the main thread, and then decrement the refcount.

It would help if you could show the raw HTTP response data that is actually being transmitted. curl is only outputting the JSON data, not the full HTTP data (you can enable its verbose output to see that). Streaming events like you have described could be transmitted in many different formats. Depending on the format used, using Indy's TIdHTTP component, for instance, you might be able to either: - use its OnChunkReceived event - enable its hoNoReadMultipartMIME or hoNoReadChunked option and then read the lines manually from Indy's socket directly - use a TIdEventStream as the target to receive the data, using its OnWrite event to access the lines. It is hard to say for sure without more information.

There is another possibility. If you don't mind assigning the OnHint events in code at runtime (or at least looping through the actions at runtime to update their OnHint handlers that are assigned at design-time), then you can use the TMethod record to alter the event handler's Self pointer to point at each TAction object instead of the TForm object. Then you can just type-cast the Self pointer inside the handler. For example: procedure TForm1.FormCreate(Sender: TObject); var Evt: THintEvent; begin ... Evt := Action1.OnHint; // or: Evt := @ActionHint; TMethod(Evt).Data := Action1; // instead of Form1 Action1.OnHint := Evt; ... // repeat for all TAction objects that share ActionHint()... end; procedure TForm1.ActionHint(var HintStr: string; var CanShow: Boolean); begin // use TAction(Self) as needed... end;

I don't have an up-to-date version to verify this with, but I seriously doubt what you claim is true. Up to at least XE8, FileExists() was never coded to raise any exceptions. I can't imagine Embarcadero would ever add exception handling to FileExists() in the years since that release.

Unfortunately, you can't, at least not from the event itself, anyway. You will have to instead use a different event handler for each action, making them call a common method if they need to share code, eg: procedure TForm1.Action1Hint(var HintStr: string; var CanShow: Boolean); begin DoActionHint(Action1, HintStr, CanShow); end; procedure TForm1.Action2Hint(var HintStr: string; var CanShow: Boolean); begin DoActionHint(Action2, HintStr, CanShow); end; procedure TForm1.DoActionHint(Sender: TObject; var HintStr: string; var CanShow: Boolean); begin ... end; .

Apparently, this is a known bug since inline variables were first introduced in 10.3 Rio, and the following tickets are still open: RSP-22359: Nameless types are not allowed within inline variable declarations RSP-31970: How to inline static array variables in Rio Based on the comments on the tickets, the workaround I suggested earlier to pre-define the array type should work for an inline variable: type Char256Array = array [0 .. 255] of Char; var buffer: Char256Array;

List counts are 32bit Integers, not 16bit Smallints. I doubt you will ever have more than 32K Forms/DataModules active at a time, but it is less efficient to make the compiler compare a Smallint loop counter to an Integer count on every iteration, the counter would have to be scaled up to 32bits each time. Is that an actual compiler error? Or just an ErrorInsight error, but the code actually compiles fine?

Yes. Its scope is limited to the loop body, so it will enter and leave scope on each iteration. Not really, no. If ARC were involved (which is no longer the case), that would include incrementing and decrementing the object's refcount. But in any case, since the variable is just a pointer, the compiler is likely to optimize the variable to reuse the same memory for each new instance each time the loop iterates. What does the error message actually say? It looks OK ome, so I'm guessing that the compiler simply hasn't implemented support for inline arrays. Do you have the same problem if you declare the array type beforehand? type Char256Array = array [0 .. 255] of Char; var buffer: Char256Array; Last I heard, the CodeEditor/ErrorInsight still hadn't been updated to support the new inline syntax yet. But the compiler will still accept it.