Remy Lebeau

POP3 will work for Gmail, in that you can connect and download emails, but it just may not work the way you are expecting a typical POP3 server to behave. See: Read Gmail messages on other email clients using POP Gmail’s POP3 behavior

Why POP3 and not IMAP? GMail's POP3 implementation is a bit of an oddball, it does not exhibit standard POP3 behaviors. This is described in GMail's POP3 documentation. This is why I question your choice to use POP3 to begin with. More precisely, it tells you that you have 274 emails that have not been downloaded via POP3 yet. Once you have downloaded a Gmail email via POP3, you can't access it again via POP3, even if it still exists in the Inbox. In your Gmail settings, you have to specify what you want Gmail to do with emails that have been downloaded via PO3.

The IDE just knows that PAS/CPP and DFM files are related to each other, so it groups them together automatically based on matching unit/file names. AFAIK, there is no registration/API you can use to do this kind of grouping for other types of files.

"Best" is a bit subjective. What you describe could be the EASIEST way, but not necessarily the BEST or FASTEST way. An alternative that doesn't involve spawning a separate process or using any file I/O would be to use NtQuerySytemInformation(SystemHandleInformation) instead to find open handles that belong to your process, and then resolve which files they refer to. See Enumerating opened handles from a process. Yes, it is more work to code for, but it may be much more efficient in the long run.

True. However, when using Process Monitor, the user can see WHEN the file is being opened by his app in real-time. Maybe he can match that up to a specific operation the app is performing at that time, and then he can track down the code behind that operation to see if it is leaking the file handle.

Then the C struct should use an untyped pointer to begin with. Since the EXE can't make use of the pointer anyway, it is just for the DLL's private use. So the DLL can open a file and store the FILE* (or whatever) in the pointer, then cast it back when needing to access the file again. The EXE shouldn't have any knowledge about HOW the DLL accesses the file. Seems like a waste of effort to port the C code twice to two separate and unrelated languages. Some Roku devices already support H.264. And there are some existing 3rd party solutions for streaming RTSP to Roku.

Looks like someone forgot to notify Support that Embarcadero's community forums are now dead.

The C code is likely using a FILE* stream to read/write MP4E_track_t data from/to a media file on disk. In Delphi, you can use TFileStream for that same purpose.

Since the TImage.Picture property is operating correctly at run-time, this sounds like it is just a design-time issue. I'm guessing that maybe a 3rd party package has registered its own design-time editor for TPicture that is interfering with the IDE's native TPicture editor. I would suggest turning off all non-essential packages and see if the problem goes away. If you can't solve the design-time issue, there is a run-time workaround. You can store the PNG in the app's resources at compile-time, then use a TResourceStream to load it into the TImage.Picture at run-time via TPicture.LoadFromStream() or TPngImage.LoadFromStream(). At least that way you don't have to distribute the PNG as a separate file.

What I do is on each visit to this site, I click on "Unread Content" that is available at the top of every page, open any new messages that look interesting, and then click on "Mark site read" at the bottom of the list. I haven't had any problems with old messages popping up as unread after I have read/marked them.

EXTRA_CC takes a String[] array as input. You are creating a 1-element array holding a comma-delimited string. Try separating out the individual addresses instead, one address per array element. You could use Java's String.split() method for that, eg: Intent.putExtra(TJIntent.JavaClass.EXTRA_CC, StringToJString(Trim(ccTechs)).split(StringToJString('\s*,\s*')) ); Also, whether or not the email will populate the CC field is up to the email app that processes the Intent, it is not up to your code. It is possible that the email app you are testing with simply ignores the EXTRA_CC data. For example, Gmail 4.2 suffered from this problem, but that was fixed in Gmail 4.3.

You need to set the ServiceUrl to https://getit.embarcadero.com instead. https://getitnow.embarcadero.com is the web front end that is meant for humans to access, not the IDE to access.

The language member is an 'unsigned char' array on the C side, so make sure you use an AnsiChar array, or better a Byte array, on the Delphi side. Don't mistakenly use a (Wide)Char array: language: array[0..3] of AnsiChar; or language: array[0..3] of Byte; You could do it that way, yes (I would suggest (U)Int32 or DWORD instead). Or, you could use {$MINENUMSIZE 4} like David suggested.

Known issue (there are several discussion threads on this forum about it). That server was shutdown 2 months ago. Change GetIt's configuration to use https://getit.embarcadero.com instead of https://getit-104.embarcadero.com, see this discussion for how to do that:

The old Borland socket components do not support Unicode strings. Some methods were updated to at least accept UnicodeString parameters, but they are not transmitted as Unicode, or even converted to 8bit properly. So avoid the SendText()/ReceiveText() methods and just use the SendBuf()/ReceiveBuf() methods, doing any string<->byte conversions manually in your own code. Or Indy, which is already pre-installed in the IDE, handles Unicode strings, and even has an HL7 component that can operate as both client and server modes.

But the issue would still be dependent on HOW AppTethering is using Indy internally. Why the Server is using so many ports, and why there are so many incomplete connections between components. What you describe sounds like port exhaustion, but you shouldn't be getting that on a TCP server, only on a TCP client. Without these kind of details, I couldn't say whether the problem is due to an error in AppTethering itself, or in the user's configuration for AppTethering, etc.

Since the bug has workarounds, has Mitov updated his code to apply the workarounds until the bug is fixed?

https://wiki.python.org/moin/Android https://python-for-android.readthedocs.io/en/latest/ https://pythonspot.com/sl4a-android-python-scripting/

Sorry, no. I've never worked with App Tethering.

By default, but that is not a requirement. You have to look at the response's Connection header to know for sure whether the server is leaving the connection open or not. If the connection is closed by the server, the response's Connection header will be set to "close", and the socket connection should be gracefully closed (but that depends on implementation) immediately after the last byte of the response has been sent. This kind of socket error can only happen if the client tries to read more bytes after the connection has been lost. Which means either the client is not detecting the end of the response correctly so it knows when to stop reading, or the server is not reporting the end of the response correctly. If the response's Content-Length header is missing, EOF is reported by socket connection closure (unless the response's Content-Type is a self-terminating media type, like MIME), so the server SHOULD close the connection gracefully, not abortively. If the Content-Length is present but has an invalid value, then the client may try to read more bytes than is actually being sent, which may lead to an abortive closure.

In a word, no. That is simply not how TCP works, let alone HTTP. This is not limited to just TIdHTTP, but to any TCP/HTTP implementation. Only the low-level TCP stack has access to the ACKs that indicate data packets have actually reached their destination. Applications do not have access to that information.

That has NEVER been true, in ANY version... ... THAT is the correct behavior, in ALL versions. Auto-created Forms, like the MainForm, are owned by the Application object. They are not destroyed until the Application object is destroyed, which is after the main DPR code is done running and the VCL is being cleaned up. Nothing has changed. So the chance has to be something in your own code that is destroying the MainForm before the Application object is destroyed.

The {$IF} and {$ELSEIF} directives have supported {$ENDIF} since Delphi XE4. See http://docwiki.embarcadero.com/RADStudio/en/Legacy_IFEND_(Delphi)

You need to use {$ELSE}{$IFDEF ...}: {$DEFINE test2} ... Step := 0; {$IFDEF test1} Step := 1; {$ELSE} {$IFDEF test2} Step := 2; {$ENDIF} {$ENDIF} or {$ELSEIF Defined(...)}: {$DEFINE test2} ... Step := 0; {$IFDEF test1} // or: {$IF Defined(test1)} Step := 1; {$ELSEIF Defined(test2)} Step := 2; {$IFEND} // or: {$ENDIF} since XE4

There are quite a few intrinsic functions that have been around for awhile but are still not documented by Embarcadero, but they are by 3rd parties. For instance, https://stackoverflow.com/questions/30417218/. See https://www.google.com/search?q=delphi+undocumented+intrinsics