Remy Lebeau

SizeOf(StringStream) This is wrong. This is the size of a pointer. How many bytes are you expecting the client to send? What does the client code look like? Ideally, the client should send the JSON's size before sending the JSON's data, and then the server should read the size before the data. IOHandler.Write(TStream) and IOHandler.ReadStream() can handle that for you, but not the way you are currently using IOHandler.ReadStream(). The client can call IOHandler.Write(TStream) with AWriteByteCount=True, and the server can call IOHandler.ReadStream() with AByteCount=-1 and AReadUntilDisconnect=False. That being said, since JSON is textual data, I would suggest using IOHandler.ReadString() instead of IOHandler.ReadStream(). Also, the preferred encoding for JSON is UTF-8 not ASCII. IdDecoderMIME1.DecodeStream(JSON.GetValue('image_encoded').Value, MemoryStream); ... Image1.Bitmap.LoadFromStream(MemoryStream); You are not rewinding the TMemoryStream back to position 0 before loading it. So the TImage ends up blank before you save it to file.

You are not doing anything wrong. By default, Form1 is simply becoming the parent window (in API terms, not VCL terms) for Form2, which is why Form2 can't move behind Form1. You can change this behavior by either: using Form2's PopupMode and PopupParent properties overriding Form2's virtual CreateParams() method to set TCreateParams.WndParent to either 0 or TApplication.Handle turning off TApplication.MainFormOnTaskBar, which has the (side) effect of making the TApplication window be the parent window for all Forms.

I would not use any global variable at all. The TField has access to the DataSet that owns the current record's fields, eg: Text := Format('%.*f', [Sender.DatSet.FieldByName('decimals').AsInteger, Extended(Sender.Value)]); Alternatively: Text := FloatToStrF(Sender.Value, ffFixed, 18, Sender.DatSet.FieldByName('decimals').AsInteger);

Perhaps the MCI_BREAK command can help you? CTRL+Break is the default for aborting am MCI wait operation, but you can specify a different key, or even disable breaking.

EPSV is not limited to just IPv6, it can be used for IPv4 as well. But also, EPSV has another benefit even for IPv4 - it has a well-defined machine-parsable response text, whereas PASV does not. PASV responses are harder to parse since different servers use different formats for their reply text, and there are quite a few different formats in use in practice.

That makes more sense. I just looked at the latest 9.3 source code, and no, I do not believe it does. For one thing, it is not checking if the server actually supports EPSV before sending that command. And second, it does not appear to switch to PASV when EPASV fails.

What is "auto passive mode"? Do you mean "Active" mode? "Active" (server connects to client) and "Passive" (client connects to server) are the 2 modes defined by the FTP protocol, and "Active" is the default. "Active" mode is not friendly to NATs, which are commonly used nowadays, so it is best to just always use "Passive" mode only.

That's the way I usually do it when I need an event handler without an object instance.

In general, RTL types named TXXXMethod refer to non-static class methods, and TXXXProcedure types refer to anonymous procedures.

Try using PROCESS_QUERY_LIMITED_INFORMATION instead. And do try using GetProcessImageFileName() or QueryFullProcessImageName() instead of GetModuleFileNameEx(). This approach should be more compatible with elevated processes.

You can't edit a post after some time has passed. And you can't delete a post, but you can flag a post and ask a moderator to delete it for you.

What exactly have you tried that is not working for you? Please show some code. Which API are you using to enumerate running processes? CreateToolhelp32Snapshot(), EnumProcesses(), EnumWindows()? Have you tried APIs like GetModuleFileNameEx(), GetProcessImageFileName(), QueryFullProcessImageName()?

The SysUtils unit in Delphi's RTL has AnsiDequotedStr() and AnsiExtractQuotedStr() functions for that exact purpose.

Winsock error 10014 is WSAEFAULT. I don't know ICS's internals, but presumably fSender.ReceiveFrom() calls Winsock's recvfrom() function, whose documentation says: Your lFromLen variable is uninitialized, so your code is passing an indeterminate value to recvfrom() which exhibits undefined behavior. Sometimes the value is too small, sometimes it is not. You need to initialize your lFromLen variable to specify the size of your lFromSock variable before calling fSender.ReceiveFrom(). On a side note: you are treating lCount=0 as an error condition, but it is not. Unlike TCP, UDP messages can be 0 bytes in size. You should be calling WSAGetLastError() only if lCount is SOCKET_ERROR (-1).

Does the host application display any UI windows of its own before the DLL's VCL form is displayed? If not, then does GetStartupInfo() report that the 1st window shown should be maximized?