Remy Lebeau

Without knowing exactly what that function actually is or where it comes from, and given how few parameters it takes, it MOST LIKELY is expecting the WHOLE bitmap, header and everything, not just the raw pixel data by itself. If so, you would just have to load your BMP file or TBitmap object into a TMemoryStream first, and then you can pass its Memory and Size properties to that function's parameters, eg: MS := TMemoryStream.Create; try MS.LoadFromFile('image.bmp'); or BmpObj.SaveToStream(MS); Result := ReadFromMemFile(hEngine, MS.Memory, MS.Size); finally MS.Free; end;

The TBitmap.ScanLine property getter handles top-down vs bottom-up differences for you. You can use scanline indexes as if the bitmap were always top-down, like a normal array, and the property getter will access the raw pixels as needed based on whether the bitmap is top-down or bottom-up. In other words, ScanLine[0] always represents the 1st line of pixels, ScanLine[1] always represents the 2nd line of pixels, and so on. function TBitmap.GetScanLine(Row: Integer): Pointer; begin Changing(Self); with FImage.FDIB, dsbm, dsbmih do begin if (Row < 0) or (Row >= bmHeight) then InvalidOperation(@SScanLine); DIBNeeded; GDIFlush; if biHeight > 0 then // bottom-up DIB Row := biHeight - Row - 1; Result := PByte(bmBits) + Row * BytesPerScanline(biWidth, biBitCount, 32); end; end; That means if you want a raw pointer to the entire image buffer as a whole, then you have to use ScanLine[0] for a top-down bitmap, and ScanLine[Height-1] for a bottom-up bitmap. But, if you just want to access the individual lines one at a time, then you can loop through ScanLine[0]..ScanLine[Height-1] without regard to whether the bitmap is top-down or bottom-up.

When that error happens, you can then call Indy's WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit to find out WHY it failed. Either the DLLs themselves could not be loaded into memory, or else they are missing exports that Indy requires. Indy supports up to the latest OpenSSL 1.0.2 DLLs. Those DLLs are known to be working with Indy.

I think that was the main reason why we switched from InterBase to FireBird many years ago.

As long as they are using separate IP/Ports, and any NAT proxy/router they are sitting behind has been configured properly for port forwarding, then there should be no problem. No.

No. But that does not mean IDN is not important to support, though. Granted, the majority of the Internet does not use IDNs, but some parts do, and you never know what you users are going to want to access.

Indy has some very limited support for IDN/Punycode, but it is at the socket layer when resolving a hostname to an IP, not at the SMTP/MIME layer.

Then DON'T pass the password on the command-line, use an IPC mechanism instead, such as a pipe, or even anonymous shared memory (coupled with this), or if you really want to be sneaky, there is an undocumented way to pass arbitrary data (up to 65531 bytes) to a child process via CreateProcess() (be careful though, it doesn't work under WOW64).

Um, because they are not actually easy to make. One needs to have a basic understanding of writing design-time packages and working with the OpenTools API, and a working knowledge of using the Visualizer API correctly, which can actually be a real PITA to work with.

In my company, I still use C++Builder 6 every single day. Our team WANTED to upgrade over the years, but upper management always said no for one reason or another. Either the IDE was too buggy, or the price was too high (both for the IDE, and for licensing 3rd party libraries we use), or the new features weren't beneficial enough to our work. Our company was bought by a competitor a few years ago and I'm the last remaining legacy developer, maintaining our software which is now on life-support pending its final end-of-life at the end of this year. Yeah, our company made that move years ago, writing new software in C# and maintaining existing software in C++. Our C# products don't hold a candle to our C++ software. Our C++ software took months to release to market and takes days to fix (usually), but our C# software took years to release to market and takes weeks/months to fix. The C# code is just so much more ugly and overly complex compared to the C++ code. At the time, I was glad to have never had to work on the C# products, but now I'm last man standing who can ever work on it, so I'm having to learn about it as I go.

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.