Remy Lebeau

Indy does not currently support OAuth yet. However, it would be fairly simple to create a TIdSASL-derived component that can be added to the TIdSMTP.SASLMechanisms collection to transmit an OAuth bearer token using the SMTP "AUTH XOAUTH2" command. But getting that token in the first place is the tricky part, and has to be done outside of SMTP.

There is nothing like FPC's TProcess in Delphi's RTL. I'm sure you can find a 3rd party implementation, though. Or just write your own.

Those are the defaults that are established by the Vcl.Graphics.pas unit (see the InitDefFontData() function) during unit initialization, and then applied to the global DefFontData variable, which is used to initialize every TFont object at runtime. Not in the IDE, no. However, the DefFontData variable is publicly accessible, so you can modify it at runtime before creating any of your TForm objects.

That makes no sense. If you pass the SAME AChildNode node into both calls, with the same AParentNodeName value (which you didn't show), then they will return the same node on output. Perhaps you meant LNode2 instead of LNode1 in the second call? If you pass in DIFFERENT node pointers on input, then obviously you are going to get DIFFERENT node pointers in output, unless they have a COMMON parent node, in which case you WILL then get the same node pointer on output. Unless, for some reason, Microsoft decided to make the IXMLDOMNode.parentNode property getter allocate a new implementation object every time it is called, which is unlikely (but easy to test). If you can't compare the node pointers directly, then you have to compare the content they represent. There is no getting around that. Can you show an example XML and code demonstrating exactly what you are trying to accomplish? How are you retrieving the IXMLDOMNode pointers that you are trying to compare?

OK, so the default is to expose only Public and Protected properties and methods, and all available data fields. That is still way more RTTI available than TypInfo.pas provides (only Published properties/methods). Rtti.pas uses TypInfo.pas internally for some of its RTTI, but there is a lot more RTTI made accessible by Rtti.pas than TypInfo.pas ever provided. Much of the RTTI in Rtti.pas does not go through TypInfo.pas at all.

Why were you using ShellExecute() for that? You should have been using CreateProcess() instead. To detect when the process ends, use WaitForSingleObject() or related function on the returned process handle. On Linux, you can start an external process using the fork(), exec...(), or posix_spawn() functions. To detect when the process ends, use wait() on the returned process ID.

Why are you using AnsiString at all? You should be using (Unicode)String instead, since that is what the TMemo expects. In any case, Char is WideChar in D2009+, so SizeOf(Char) is 2 not 1, so you are allocating memory for your AnsiString for only 1/2 of the file data, but then reading the full file into that memory. So you are going to corrupt surrounding memory. Use SizeOf(AnsiChar) instead, which is 1 so you can just drop the SizeOf() altogether. var LoadString: AnsiString; FS: TFileStream; begin FS := TFileStream.Create(FileName, fmOpenRead or fmShareDenyNone); try SetLength(LoadString, FS.Size); FS.ReadBuffer(Pointer(LoadString)^, FS.Size); finally FS.Free; end; Memo.Lines.Add(String(LoadString)); end; Alternatively, there are other options, such as TMemoryStream.LoadFromFile(): uses System.Classes; var LoadString: AnsiString; MS: TMemoryStream; begin MS := TMemoryStream.Create; try MS.LoadFromFile(FileName); SetString(LoadString, PAnsiChar(MS.Memory), MS.Size); finally MS.Free; end; Memo.Lines.Add(String(LoadString)); end; Or TStreamReader: uses System.Classes, System.SysUtils; var LoadString: String; Reader: TStreamReader; begin Reader := TStreamReader.Create(FileName, TEncoding.ANSI); try LoadString := Reader.ReadToEnd; finally Reader.Free; end; Memo.Lines.Add(LoadString); end; Or TFile.ReadAllText(): uses System.IOUtils, System.SysUtils; var LoadString: String; begin LoadString := TFile.ReadAllText(FileName, TEncoding.ANSI); Memo.Lines.Add(LoadString); end;

I can see that being true for Standard RTTI (TypInfo.pas), which is only generated for published members. But that should not be true for Extended RTTI (Rtti.pas), which sees everything, even private/protected stuff. That is why TRttiMember has a Visibility property.

You can use Extended RTTI for that. TRttiMethod has a VirtualIndex property.

Feel free to file a bug report with Embarcadero.

The only way I could see that happening is if either: - the requests are being sent on the same TCP connection (using HTTP keep-alives and maybe HTTP pipelining) and one of the requests is blocking the ones that arrive after it - your requests are arriving on different TCP connections and are accessing some piece of shared data/functionality that is being blocked/deadlocked, thus blocking all requests that try to access it. It is really hard to know what is going on without more details about your code and the requests. The only option is to close the socket that belongs to that TIdContext. But if your code is blocked/deadlocked on something that is not related to the socket itself, then closing the socket is likely to not have any/much effect in this situation. You really need to narrow down WHAT exactly is blocking. You still haven't answered my earlier questions about that.

Sounds like a bug that you should report to Embarcadero directly.

Since Delphi 2010, actually. RTTI data is pooled in memory. There is only 1 ref-counted copy of the RTTI data in memory that all active TRttiContext instances share. That article is old, and not 100% accurate. For instance, the implementation of TRttiContext.Create() shown in the article is how Create() was implemented in D2010, but it was changed in XE. Test1 is creating and destroying the RTTI pool 100 times, because it only has 1 TRttiContext instance alive at a time. The pool's refcount never goes above 1. The pool is recreated each time the refcount is incremented to 1, and destroyed when the refcount is decremented to 0. That is not the case in Test2, which has 2 active TRttiContext instances alive at a time so the pool is not destroyed until after the loop is finished.

What is the actual problem you are experiencing? You did not provide any details whatsoever about that. Are you getting an error? Corrupted data? Which version of Indy are you using? How is the Java server configured? Which SSL/TLS version(s) does it expect? Please be more specific. With the code you have shown so far, the SSLIOHandler uses only TLS 1.0 by default. Does the server support TLS 1.0? Many servers nowadays no longer support TLS 1.0 and earlier, they expect TLS 1.1 or 1.2 at a minimum. You can enable TLS 1.1 and 1.2 in the SSLIOHandler's SSLOptions.SSLVersions property (only sslvTLSv1 is enabled by default).

I think you mean the external DLL uses your jpeg, right? What failure exactly? You need to be more specific. What makes you think TJPEGImage creates invalid JPG files? Perhaps the real problem is an error in how the DLL uses the JPG file.

He said the code is running in a thread. Locking a TBitmap's Canvas is required when working with a TBitmap in a thread, otherwise the main VCL thread can swoop in at any time and reclaim the GDI resources being used by the TBitmap behind its back.

Nothing has been announced publicly yet.

Or email the RAD Studio beta directly: rad.beta@embarcadero.com

Oh, that's interesting. I just tried it on my desktop, and sure enough it takes on the mobile look&feel when I shrink my browser window (I always use it full screen, so I never noticed that before).

When I first started using this site on mobile, it took me a LONG time to find the option there. Definitely not the most intuitive place for it. I would have expected it to be under "Activity" along side the "Unread Content" option.

I don't understand what is confusing about it. Actions have several properties and events that apply to Forms just as they do to any other UI control.

The same could be asked for any UI control that has a published Action property and a published OnClick (or other actionable) event. One reason is code reuse, the same Action object can be assigned to multiple controls, even the Form itself. For instance, Actions are commonly shared with menu items and other UI controls that invoke the same actions. Another use would be sharing common properties with multiple controls (Enabled, Visible, etc) so you can update 1 property and have it propagate to multiple controls automatically.

Sadly, you won't be able to do that with FMX's TWebBrowser. It simply doesn't have the necessary functionality for that (only VCL's TWebBrowser does). If you really want to use FMX's TWebBrowser, then I suggest using TIdHTTP or other HTTP client for the actual HTTP communications, that way you can automate it however you want, and just use TWebBrowser to display the HTML (or whatever) you retrieve, such as via its LoadFromStrings() method. And then use TWebBrowser events to block the browser from making HTTP requests, redirecting them to your HTTP client of choice. The experience won't be as seemless as a standard browser, but it will give you more control.

A better solution would be to forgo the TWebBrowser frontend altogether and redesign your web app to accept REST requests on the backend server to do the work you need. Then use a standard UI on the client side to display the results as needed. You would have to check if the underlying platform browsers provide any APIs to automate them in code. VCL's TWebBrowser is a wrapper for Internet Explorer and exposes access to its DOM API. FMX's TWebBrowser does not expose similar functionality.

Correct. There is not, because you cannot combine 32-bit and 64-bit code into a single executable, so you will need separate 32-bit/64-bit DLLs, and thus will need separate 32-bit/64-bit processes to install their hooks into target 32-bit/64-bit processes.