Remy Lebeau

Classes are reference types in Delphi: "Reference types can be forward declared because their size are always known (=SizeOf(pointer))."

When another user calls, display a notification, and when the receiving user clicks on the notification, the app can then come forward and complete the call.

That has been the case for several years now. Near the end of each beta, some testers (not all) are granted permission to publicly blog about their experiences in the beta. Note the disclaimers given at the top of each non-Embarcadero blog mentioned above (and others), eg: "I have been given permission from Embarcadero to blog about some of the new features and improvements." "Published with special permission from Embarcadero" "I’ve specifically been given permission to show updates and new features in the product" etc...

Short answer - background tasks that want to stay awake and running need to be done in a background service, not in a thread in an app that moves between the foreground and background.

Processes and Application Lifecycle Understand the Activity Lifecycle Android is the same way. Background apps have to let the OS know that they are still "running" and should not be killed off. The OS is still free to kill them if it NEEDS to, though (low resources, etc).

The data you are seeing is not *encrypted*, it is *compressed*. You are telling the server that you will accept responses in a compressed format (on top of encryption used by SSL/TLS), and the server is choosing to actually send a compressed response (you can verify that by looking at the TIdHTTP.Response.ContentEncoding property after the response arrives), however you have not setup TIdHTTP to actually decompress the compressed data for you, so you are seeing the compressed data as-is (well, after it has been String'ified, anyway). Get rid of that assignment to the TIdHTTP.Request.AcceptEncoding property (unless you really want to try your hand at decompressing the data manually). Instead, assign a TIdZLibCompressorBase-derived component, such as TIdCompressorZLib, to the TIdHTTP.Compressor property, and let TIdHTTP manage the AcceptEncoding property for you based on the compressor's capabilities. Don't call the TIdLogFile's Open() and Close() methods directly. Use its Active property instead, which will call Open()/Close() for you: IdLogFile1.Active := True; try LResp := IdHTTP1.Get('https://www.trivial.com.br/envia_arq3.php?senha=violeta&nome=tre'); finally IdLogFile1.Active := False; end; Calling Open() will open the log file you specify, but any sent/received data will not be logged to the file if Active is False.

VCL's TBitmap supports only the BMP format (and actual BMPs, not JPEG/PNG-encoded BMPs that recent Windows versions support). Saving a VCL TBitmap to a file with a ".png" extension DOES NOT create a PNG image, it creates a BMP image. PNG is compressed, whereas BMP is (usually) not (though VCL's TBitmap can load a compressed BMP - I think - but it does not produce compressed BMPs). FMX's TBitmap supports many formats, including BMP and PNG. Saving an FMX TBitmap to a file with a ".png" extension creates a real PNG image. Try saving your FMX TBitmap to a file with a ".bmp" extension and you will see a result closer to what VCL's TBitmap creates. BMP and PNG are both lossless formats. The pixel data in both formats may represent the same color arrangements to a viewer, but the way the data is stored in memory and in a file are very different.

Yes, Sleep()/usleep() really does block the calling thread, stopping it at the OS level, yielding to other threads so they can run, for at least the specified time (may be more). TEvent.WaitFor() is waiting for its internal event/semaphore object to be signaled by TEvent.SetEvent(), up to the specified time. During that wait time, the calling thread is stopped in a blocking sleep, yes. It is just using a different API to accomplish that.

It is not ideal, but it is not a problem, since the server will just ignore the 'Content-Type' request header in a GET request. 'application/x-www-webform-urlencoded' would not be a valid media type for an 'Accept' request header.

There are numerous examples and tutorials online for how to work with webcams using the Win32 API. That information is accessible via webcam APIs. You don't need VCL or FMX for that. Or, you could simply take the screenshot using an in-memory GDI bitmap, and then copy the raw pixel data from that bitmap into an FMX TBitmap as needed. Look at CreateCompatibleDC(), CreateCompatibleBitmap(), GetObject(), and TBitmap.Canvas.MapBitmap()/UnmapBitmap().

The fact that you are even getting an HTTP 403 error at all means the SSL portion is working fine, since HTTPS is encrypted and you are able to see a decrypted response. So the problem has to be related to something else. Maybe you are not accessing the correct URL. Maybe you are not authenticated properly with the server. Maybe you are missing a client-side certificate. We don't know, since we don't know your setup or what the server is expecting. One thing you could try is capture the HTTP request the browser is sending (using your browser's built-in debugger, or an external HTTPS debug proxy like Fiddler), and then capture the HTTP request that TIdHTTP is sending (assign one of Indy's TIdLog... component to the TIdHTTP.Intercept property), and compare them for any differences. If you don't see anything apparent at the HTTP layer (cookies, login credentials, etc), then the issue could be at the SSL layer (ie, certificates, etc) You likely need to talk to the server admins about this, ask them what the server requires to get permission to access it. Have them look at the HTTPS requests on their end to see why the server is rejecting them. You should contact AToZed to double-check, but I do not believe that paid support is still provided, at least for Indy. Probably only for IntraWeb, if at all.

Yeah, THAT is not going to happen anytime soon, either.

It wasn't resetting the last-error at all. That was, and always has been, the sole job of the OS to handle. Whatever value was assigned to the last-error going into the RTL's ThreadProc(), that is the value that was still set when going into TThread.Execute(). And since the issue is reproducible in FPC and Visual Studio then it has nothing to do with Delphi's RTL at all. Something has clearly changed internal to the OS itself, and you are not going to figure out what that is unless you trace into the OS's internal source code for yourself. That is because CreateThread() in Win9x does not allow the lpThreadId parameter to be NULL. If it is, CreateThread() fails with ERROR_INVALID_PARAMETER (87). That behavior was changed in NT4 onward to allow the lpThreadId parameter to be NULL, as the thread's ID is not typically needed by most users. That restriction used to be documented: The restriction is no longer documented since Win9x is no longer supported:

Not going to happen. You can't forward-declare records.

That doesn't sound right. All shipped BPL files should have the IDE's package version in their filenames. Their corresponding BPI/DCP file may not, but Indy does not make use of {$LIBSUFFIX} yet, so even its DCP files should have the package version in their filenames. Unless Embarcadero has created their own unversioned packages. I haven't installed a new IDE in several years, so I wouldn't know how the shipped Indy is compiled anymore.

Um, maybe I'm missing something, but that test is not passing a NULL pointer for the threadid. But, it doesn't matter anyway, because that test code belongs to WINE's emulated implementation of the Win32 API, it does not belong to the actual Win32 API on Windows.

But, if you decide to use GetLastError() the way it is MEANT to be used, you would never see this happen AT ALL, because you would NOT be calling GetLastError() until after an API function actually overwrites the calling thread's last-error with a meaningful value first. That user's mistake (using a thread procedure of the wrong signature) has no bearing on how GetLastError() works. If anything, all that mistake would do is cause an extra value to be pushed on the call stack before entry to the thread procedure (LPVOID lpParameter), and that value would not be popped off the call stack properly after exiting the procedure. But inside the procedure, there is no effect. I don't think it is anyone's bug, except maybe yours if you choose to misuse GetLastError() in the first place. That is absolutely not needed when using GetLastError() the proper way. GetLastError() simply does not return a meaningful value when GetOverlappedResult() returns TRUE, only when it returns FALSE. As is the case with most API functions. Most API functions DO NOT overwrite the calling thread's last-error on success, only on failure, unless explicitly documented otherwise (for example, CreateEvent(), etc). Or, if they do overwrite the last-error on success, it could just be as a side effect of internal operations that were handled as needed, and you are supposed to ignore the last-error since the API returned success to you. Socket Overlapped I/O operations use the WSAOVERLAPPED struct and WSAGetOverlappedResult() function. Which just HAPPEN to currently be binary compatible with OVERLAPPED and GetOverlappedResult() as an implementation detail. Don't rely on that. Use the proper API. I do not have 10.3.3, but I cannot reproduce or confirm it in other versions. There is no difference between an anonymous thread and any other TThread. TThread.CreateAnonymousThread() merely creates a TAnonymousThread object, a TThread descendant whose Execute() simply calls the provided user procedure, no frills, no other logic: type TAnonymousThread = class(TThread) private FProc: TProc; protected procedure Execute; override; public constructor Create(const AProc: TProc); end; constructor TAnonymousThread.Create(const AProc: TProc); begin inherited Create(True); FreeOnTerminate := True; FProc := AProc; end; procedure TAnonymousThread.Execute; begin FProc(); end; class function TThread.CreateAnonymousThread(const ThreadProc: TProc): TThread; begin Result := TAnonymousThread.Create(ThreadProc); end; So, any issues with GetLastError() used in TThread.CreateAnonymousThread() would also have to affect all TThread objects in general. Which would imply a problem is present in Classes.ThreadProc() itself before TThread.Execute() is called. And that is not likely given how little code is present before that call. On Windows, there are only 2 lines of code executed before Execute() is called (unless something has changed in recent RTL versions): the assignment of TThread.FCurrentThread (a threadvar), and the opening of a try..finally block. Exception handling blocks do not affect a thread's last-error, but TLS storage can. But it is unlikely that the assignment of FCurrentThread would fail, unless the RTL were not initialized properly at process startup.

Why does it matter? In your example, the error code would have to be getting set before your thread procedure is even called, in which case it would be internal to the OS when preparing the thread, or even internal to the RTL before calling TAnonymousThread.Execute(), but either way it is not in your own code, so who cares about WHY it happens? You are not supposed to be using that error to begin with, since it has no meaningful value in the context you are using it in. Its value is indeterminate in that context. In fact, I just did a quick test of my own, and the value of GetLastError() upon entering the thread procedure WAS NOT 87, it was 0. So the result you are observing has to be environmental in nature.

There is no "generic" Indy. The IDE ships with Indy 10 pre-installed. You can't have multiple versions of Indy 10 installed in the IDE at the time same. But you can have multiple copies in different folders on your HDD, and then tweak the IDE search paths when needed to refer to one copy or the other at any given time. And possibly create multiple Registry configs for the IDE to use at different times (see the -r command-line parameter). But, if you didn't backup the original Indy before updating it, then the only way to restore it is to reinstall the whole IDE fresh. Otherwise, you could just recompile the 3rd party library so it uses the updated Indy 10 that you installed, if you have the source code for that library.

(Get|Set)LastError() use thread-local storage internally. The last-error code is stored inside the OS thread object itself. It doesn't matter how you create the thread, calling SetLastError() in one thread context and then calling GetLastError() in another thread context will NEVER work. The last-error simply can't cross thread boundaries. This is documented behavior: https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-getlasterror https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-setlasterror https://docs.microsoft.com/en-us/windows/win32/debug/last-error-code

Hard to answer without knowing which articles you are actually reading. But most likely, the way to sort a grid in FMX has likely not changed much, if at all.

The same way you encode any other <input> field - as a "name=value" pair, where the "name" and "value" are properly url-encoded. The "type" of the <input> field doesn't matter. Yes. The <form> in question specifies "method=post", so you would need to send the encoded parameters in a POST body, not in the query component of a URL, eg: POST /envia_arq2.htm HTTP/1.1 Host: www.trivial.com.br Content-Type: application/x-www-form-urlencoded Content-Length: 36 Connection: close senha=violeta&nome=tre&enviar=Enviar However that translates to TSslHttpCli/TSslHttpRest (I don't use ICS).

You can, but not the way you are thinking. If you call RegisterServiceCtrlHandler/Ex() manually, then you can't use any pre-existing service framework (TService, DDService, SvCom, etc), as they make their own call to RegisterServiceCtrlHandler/Ex() for you. You would have to make ALL of the SCM-related API calls manually, starting with StartServiceCtrlDispatcher() and implementing ServiceMain() to call RegisterServiceCtrlHandler/Ex(). Read MSDN for more details: Service Program Tasks I'm not sure. I've seen conflicting info on that. Some people say yes, some say no. I haven't tried it myself to check. How can I Execute a Function from service program when Windows Fast Startup How to detect wake up from sleep mode in windows service? Detect resume from hibernate in a windows service Detecting Hibernation / Standby and resume in a Service Chapter 6: OnNow/ACPI Support That code will not work: - a service's Handler/Ex() cannot call RegisterServiceCtrlHandler/Ex(), because it has already been called before the OnStart event is called. - WM_POWERBROADCAST is a window message, not a service notification. A service would need to handle SERVICE_CONTROL_POWEREVENT notifications instead.

Also, it is common for webservers to use cookies with webforms, so you should first GET the webpage that contains the webform so that you download any initial cookies, then parse the webform fields (ie, in case any contain randomly generated field values), then submit the webform as directed. Also, make sure you submit ALL <input> fields that have a non-empty value - including the submit button itself! Sometimes webforms have multiple buttons, in which case the webserver needs to know which one is performing the submission.

See Raymond Chen's blog for why: Modality, part 3: The WM_QUIT message and Why is there a special PostQuitMessage function?