Remy Lebeau

Fix checked in.

I have checked in .dproj files for 10.3 now. I don't know if they work. I don't really use .dproj files myself, and I don't have 10.3 installed to make them for me, so I just copied the files from 10.2 and tweaked them. Otherwise, you can just open and compile the individual .dpk files instead and let the IDE generate new .dproj files. Fixed now. Fixed now.

Another option would be to release ownership if the constructor fails, that way the caller retains ownership until the constructor is successful: constructor TMyClass.Create(_SomeInstance: TSomeOtherClass); begin inherited Create; FSomeInstance := _SomeInstance; try // other code here except FSomeInstance := nil; raise; end; end; Or, you could simply not take ownership until the very end after everything else is successful: constructor TMyClass.Create(_SomeInstance: TSomeOtherClass); begin inherited Create; // other code here FSomeInstance := _SomeInstance; end; If something needs to be called during construction that requires FSomeInstance, modify that something to let the constructor pass _SomeInstance to it as a parameter: constructor TMyClass.Create(_SomeInstance: TSomeOtherClass); begin inherited Create; // other code here DoSomethingWith(_SomeInstance); FSomeInstance := _SomeInstance; end;

Same with SvCom, written by Aldyn Software (this is the one I use). In fact, there are quite a few 3rd party TService replacements available. Or, you could simply make a copy of SvcMgr.pas and patch TService yourself.

I just now checked in that fix.

Nevermind, I'm blind. I see the issue now. It needs to be referred to as Union.IfIndex instead: A.Union.IfIndex := 0; Now I know what needs to be fixed in Indy, too. I'll do that tomorrow.

Let's do a quick test: create a new test app, and put something like this in it: program Test; {$APPTYPE CONSOLE} uses Winapi.IpTypes; var A: IP_ADAPTER_ADDRESSES; begin A.IfIndex := 0; end. If that compiles, then I'm out of ideas why Indy fails to compile when accessing IfIndex when using the definition of IP_ADAPTER_ADDRESSES from either Winapi.IpTypes or IdStackWindows.

It shouldn't matter. Delphi defines it with a leading underscore, Indy does not. Delphi should have another statement that maps _IP_ADAPTER_ADDRESSES to IP_ADAPTER_ADDRESSES.

That clearly shows that the IfIndex field is present in Delphi's definition of IP_ADAPTER_ADDRESSES, as it should be. I don't know what else to tell you then. If you load up Indy's IndySystem package in the IDE and Ctrl-Click on PIP_ADAPTER_ADDRESSES in the IdStackWindows.pas code, where does it take you?

Refresh and look at my updated previous reply

But, did you validate whether Delphi's definition of IP_ADAPTER_ADDRESSES has IfIndex or not? I don't have access to the RTL's IpTypes.pas source file right now to look myself, I'll do that tomorrow. Indy should not be accessing any 3rd party IpTypes unit. But, that is why I did say to make sure that is not happening (did you read that link yet?): If HAS_UNIT_IpTypes is defined, then try making that same change to IdStackWindows.pas. But, if HAS_UNIT_IpTypes is not defined, then that doesn't matter, and you should not be getting the error since Indy does define the IfIndex field in its own definition of the IP_ADAPTER_ADDRESSES record: IP_ADAPTER_ADDRESSES = record Union: record case Integer of 0: ( Alignment: ULONGLONG); 1: ( Length: ULONG; IfIndex: DWORD); // <-- HERE!!!!! end; Next: PIP_ADAPTER_ADDRESSES; AdapterName: PIdAnsiChar; FirstUnicastAddress: PIP_ADAPTER_UNICAST_ADDRESS; FirstAnycastAddress: PIP_ADAPTER_ANYCAST_ADDRESS; FirstMulticastAddress: PIP_ADAPTER_MULTICAST_ADDRESS; FirstDnsServerAddress: PIP_ADAPTER_DNS_SERVER_ADDRESS; DnsSuffix: PWCHAR; Description: PWCHAR; FriendlyName: PWCHAR; PhysicalAddress: array [0..MAX_ADAPTER_ADDRESS_LENGTH - 1] of BYTE; PhysicalAddressLength: DWORD; Flags: DWORD; Mtu: DWORD; IfType: IFTYPE; OperStatus: IF_OPER_STATUS; Ipv6IfIndex: IF_INDEX; ZoneIndices: array [0..15] of DWORD; FirstPrefix: PIP_ADAPTER_PREFIX; TransmitLinkSpeed: ULONG64; ReceiveLinkSpeed: ULONG64; FirstWinsServerAddress: PIP_ADAPTER_WINS_SERVER_ADDRESS_LH; FirstGatewayAddress: PIP_ADAPTER_GATEWAY_ADDRESS_LH; Ipv4Metric: ULONG; Ipv6Metric: ULONG; Luid: IF_LUID; Dhcpv4Server: SOCKET_ADDRESS; CompartmentId: NET_IF_COMPARTMENT_ID; NetworkGuid: NET_IF_NETWORK_GUID; ConnectionType: NET_IF_CONNECTION_TYPE; TunnelType: TUNNEL_TYPE; // // DHCP v6 Info. // Dhcpv6Server: SOCKET_ADDRESS; Dhcpv6ClientDuid: array [0..MAX_DHCPV6_DUID_LENGTH - 1] of Byte; Dhcpv6ClientDuidLength: ULONG; Dhcpv6Iaid: ULONG; FirstDnsSuffix: PIP_ADAPTER_DNS_SUFFIX; end;

OK

See Support for Subversion clients in GitHub's documentation. Now that Indy is on GitHub, SVN revision numbers don't really have any meaning to Indy anymore. There is no readily available mapping of GitHub's SVN revision numbers to GIT commits within the GIT system, so when you say "svn rev XYZ", I don't know which GIT commit that actually refers to, unless I go access the system via SVN and look at the metadata. Just saying...

There is no /trunk folder in GitHub. Did you even try the fix I posted last night for you? The AdapterIndex error should be fixed now. Regarding the IfIndex error, Indy manually defines the IP_ADAPTER_ADDRESSES record only when HAS_UNIT_IpTypes is not defined. HAS_UNIT_IpTypes is defined for XE2+, and 10.3 is later than XE2, which means Indy is going to use an external (hopefully Delphi's!) definition of IP_ADAPTER_ADDRESSES rather than Indy's definition. It would stand to reason that the external definition lacks the IfIndex field (why, I don't know), otherwise you wouldn't be getting an error on it. Double-check Delphi's definition in the RTL's Winapi.IpTypes.pas unit is accurate, and also make sure you are not falling into this trap. In the meantime, a simple workaround would be to just comment out the {$DEFINE HAS_UNIT_IpTypes} statement in IdStackWindows.pas for now.

Indy does not use SVN anymore. The latest code is now on GitHub. That should be fine, though the resulting BPLs won't be named consistently with other packages installed in 10.3. I just haven't gotten around to making and posting project files for 260 yet. In part because I don't have 10.3 installed! Hmm, interesting. I was not aware of that. I'll have to consider disabling that warning. IfIndex is used when Indy calls GetAdaptersAddresses(), and the IP_ADAPTER_ADDRESSES record has an IfIndex field defined, so not sure why that error would be happening. AdapterIndex is used when Indy calls GetAdaptersInfo(), but the IP_ADAPTER_INFO record does not have an AdapterIndex field defined. Not sure where I got that idea from when I wrote that code. I have fixed that now.

In VCL, colors are expressed using TColor. You can use the RGB() function or the TColorRec record to specify decimal/hex values for the individual R, G, and B channels. In FMX, colors are expressed using TAlphaColor. You can use the TAlphaColorRec record to specify decimal/hex values for the individual R, G, B, and A channels.

Do you really need this, though? If you simply include 'System' and 'Vcl' in the Unit Scope Names list in your project options, you won't need to update the 'uses' clauses at all.

Then do what Dave said to do: In other words, add something like this to the code: procedure TPhoneDialerForm.FormCreate(Sender: TObject); begin {$IFDEF ANDROID} FCallPhonePermission := JStringToString(TJManifest_permission.JavaClass.CALL_PHONE); {$ENDIF} { test whether the PhoneDialer services are supported } if TPlatformServices.Current.SupportsPlatformService(IFMXPhoneDialerService, FPhoneDialerService) then FPhoneDialerService.OnCallStateChanged := CallStateChanged; // <-- ADD THIS! end; procedure TPhoneDialerForm.CallStateChanged(const ACallID: String; const AState: TCallState); var Calls: TCalls; Call: TCall; begin if AState = TCallState.Incoming then begin Calls := FPhoneDialerService.GetCurrentCalls; try for Call in Calls do begin if Call.GetCallID = ACallID then begin // use Call as needed ... Exit; end; end; finally for Call in Calls do Call.Free; end; end; end;

And how are you going to handle the case where a thread allocates some memory, then that thread terminates/dies and its ThreadID gets reused by a new thread, and then that new thread wants to deallocate the earlier memory? Storing the ThreadID in the memory metadata may not suffice, and if you use TLS storage for the memory then you lose the original memory altogether. Even if the SAME thread does the allocating and deallocating, you still need some kind of thread-safe mechanism to synchronize (de)allocations with OTHER threads so they don't try to reuse/trample the same memory block while it is still being used.

What makes you think it is any different for Android? Most platforms use the same Berkeley-based socket API. That is true for Windows. That is true for Posix systems, like Linux (which Android runs on top of). select(), recv(), these functions exist and behave the same on Android (when coding at the native layer, as you describe) as they do on Windows.

Yes. Indy 11 will just be a maintenance cleanup, no real new functionality (anything that does get added will likely be able to backport to Indy 10), so old projects won't have to worry about Indy 11. But Indy 12 will likely start making big changes and adding new features, and it likely won't make sense to try to support those in old compilers going forward.

A declaration of an alias, anyway. TMyClass and TAnotherClass will be the same type, as far as the compiler and RTTI are concerned. Now, if you do this instead: TMyClass = type TAnotherClass; Or this: TMyClass = class(TAnotherClass) Then TMyClass will be its own unique type.

Because you are merely checking the socket for readability only. If select() returns 0, it timed out, which in this case means the socket is not readable because it has no pending data, not even a graceful disconnect. As long as connect() is successful and the socket doesn't report read/write errors, it is connected.

No, it is an undefined method. Calling recv() with a buffer length of -1 is undefined behavior, and AFAICS no platform actually defines what should happen with that input.

Cross-platform, the only way is to perform an I/O operation on the socket and check for error. On Windows, at least, a non-blocking socket can issue an asynchronous FD_CLOSE notification when the connection is closed, but you should still check I/O operations for errors, too. The same type of coding will work on POSIX, too. The base BSD socket API, like select() and recv(), is common across multiple platforms. Why are you passing your fd_set variable as the buffer for recv() to read into? More importantly, you can't pass -1 as the size of the buffer to read into. On Windows, the len parameter is an int, so it will at least compile with a length of -1, but semantically asking recv() to read -1 number of bytes makes no sense, and is not documented as a supported operation. But worse, on other platforms, the len parameter is a size_t, which is an unsigned type, so passing in a length of -1 will wrap to a very large value and very bad things can happen! Also, you are not checking to make sure that select() actually reports the socket is readable before then calling recv() on the socket. Since you are only querying 1 socket, the return value of select() will be -1 on error, 0 on timeout (not readable), and 1 (readable). Alternatively, since select() modifies the fd_set struct on output, you can check if your socket is still in the set after select() exits. Also, you are not handling recv() reporting an error at all. Either way, do keep in mind that you are performing an actual read, so any bytes that recv() does actually receive will not be available for subsequent reads, so you will have to buffer the bytes somewhere in memory so you can still use them later. In most cases, implementing an IsConnected() type of function is really unnecessary and should be avoided.