Remy Lebeau

In my company, we wrote our own logging solution from scratch for all of our apps to log to. It consists of a Windows service hosting an out-of-process COM server, managing a thread-safe FIFO queue of log entries. A background thread continuously writes the entries to a log file, stopping and starting a new file at night and archiving the old files, purging old records/files at scheduled intervals, etc. Another thread forwards certain log entries to a secondary service running on another machine, to email, to SNMP traps, etc. Our individual apps use the service's COM object to send log entries and other commands as needed. Under heavy load, it easily handles 1000s of log entries per second across multiple processes. And if a given app crashes, COM handles the cleanup for us. And then we have a separate viewer app to display the log entries in real-time. This is probably a bit extreme for your use case, though. Existing logging tech wasn't very good way back when this project was first started.

Or the one in Indy (TIdFTPServer). Not in FTP, no. That is simply not how the FTP protocol works. The client has to login up front at the beginning of the FTP session, and cannot re-login again afterwards without disconnecting first. Like Angus said, you will basically have to create your own FTP server that you have complete control over. A pre-existing server, like IIS, is not really going to help you with this kind of task. Statically defined virtual folders, yes. But dynamically defined virtual folders, no. Server components like the ones in ICS and Indy give you direct access to the client's commands, and virtual folders is really not that difficult to implement when you have direct access to the paths the client is trying to access. I once wrote a virtual folder manager for Indy (I don't have it any more, though), it is just a matter of splitting a requested path into its individual parts and then walking the parts resolving each one to a physical folder as needed until you end up with a final physical path. So, in your case, when the user starts the transaction, you create the virtual folder in your DB/whatever and make sure that folder is resolvable to a physical folder and is included in directory listings as needed. When the transaction is done, delete the virtual folder from your DB/whatever. If the client requests a path that includes a virtual folder that is no longer resolvable, a standard FTP 55x error response, like 550 or 553, will suffice to let the client know the path is no longer valid.

Then you are just going to have to debug the code at runtime to find out what is really happening. The OnJoyMove event is fired by an internal TTimer that calls joyGetPos() at regular intervals and then compares the latest coordinates and button states for any changes from the previous call. The fact that you get the OnJoyMove event fired at least once means the timer is running and polling correctly. So either you are doing something to block that timer from firing again, or maybe you are deactivating the TJoystick without realizing it, or maybe joyGetPos() itself is failing. We can't debug for you, because we can't see your real code. FWIW, manually polling the hardware at regular intervals is not the best way to go. Makes me wonder why TJoystick was not written from the beginning to use joySetCapture() instead to allow the OS to send its own event notifications to the app. No, this is likely not related to FMX at all - unless FMX's TTimer is broken. Although, do note that TJoystick is using Windows-specific APIs, so it won't work on any non-Windows platforms that FMX supports.

Replace the try..finally with try..except instead, then it will be fine: constructor TMyClass.Create(_SomeInstance: TSomeOtherClass); begin inherited Create; // other code here // don't take ownership unless everything above is fine... FSomeInstance := _SomeInstance; end; ... MyInstance := nil; try SomeInstance := TSomeOtherClass.Create; try MyInstance := TMyClass.Create(SomeInstance); except // ownership of SomeInstance is not taken, so free it now... SomeInstance.Free; raise; end; // ownership of SomeInstance is taken, will be freed when MyInstance is freed... ... finally MyInstance.Free; end;

If there is, I haven't found it yet. It is very easy in VCL (TColumn.Field and TColumn.FieldName), but apparently is more difficult in FMX (why? This is one of many reasons why I hate FMX, it over-complicates things that used to be easy). I suggested using TColumn.Header after reading this answer to FMX.TGrid how to allow user to move columns without messing up the data, which shows the TColumn.Header being used in a call to TClientDataSet.FieldByName().

You are on the right track. You need to use the Column parameter. In this case, you can use the TColumn.Header property to know which column is being drawn.

Was there something wrong with the example I gave you in my previous reply?

Um, do you see a try..finally in the example I provided? No. That example does not use one. The previous example did. 2 different scenarios.

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.