Leaderboard

Added a quick blog post on inline variables: https://www.ideasawakened.com/post/newly-discovered-hidden-benefits-of-inline-variables-in-delphi

I agree. The test case is invalid. Nope. There's no API contract that promises you that GetLastError will or should be zero at the point where you are testing it. If it's important to you that it is zero then sure, go ahead and set it to zero but it would be better to not misuse GetLastError that way. You should test GetLastError right after you have made an Win API call because at that point it will have been set to a relevant value.

(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

The only error here is the code that calls GetLastError and uses the value at a time when its return value is meaningless. All you have to do is to stop doing that.

This has nothing to do with threads. You're using GetLastError() altough there was no error for you to care about. https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-getlasterror

If you put a breakpoint on the first line of code in function ThreadProc in System.Classes and call GetLastError, it will be 87. This is the start of the thread code in Delphi so it's apparently simply starting out that way every time (at least in my limited testing.) As far "was this a known fact"... not known to me, not known to the few MS document searches that I did, but it does show up on a question from 2011 on StackOverflow: https://stackoverflow.com/questions/7199139/createthread-getlasterror-returns-87

Not looked closely at your code, only got as far as sleep in an event handler which is very bad design. You are also recursively starting a new request from the event, which calls the event again... To use async functionality properly, you should use a timer and triggers. ICS provides such functions in OverbyteIcsUtils, ie IcsGetTrgSecs, IcsGetTrgMins, IcsTestTrgTick which are used in OverbyteIcsSslMultiWebServ1.pas as an example. You set a trigger in the event to how every many seconds you want to wait, then test it in a timer triggering once a second or slower, then start the next request. Angus

Patient: Doctor, my eye hurts, when I poke it. Doc: Well then don't poke it. 😄

AFAIK it isn't and there's no reason for you to do it yourself because the value is irrelevant unless you're testing the result of an API function that has indicated that GetLastError should be used to get information about a failure. Here's another example of the exact same mistake: CreateThread() // GetLastError() returns 87 You don't need to "clear LastError" unless your function is using GetLastError as it's own status reporting mechanism and that would be very rare.

This is why Anders' advice is good advice: https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-setlasterror

Hi Feri, There is the global variable FastMM_OutputDebugStringEvents, which is a set of events for which OutputDebugString will be called. By default only critical events are included, but you can adjust it to fit your needs. Best regards, Pierre

Yeah, should be using '%p' format string

We’re now looking for a small number of Beta testers to try out our new iOS & Android build automation tool - MonkeyBuilder. The website is still under development but has some information to give you an idea of what it can do. https://www.monkeybuilder.io Beta test numbers are limited to begin with but we hope to open it up to more users over the next couple of weeks. If you are interested, please comment here or contact us via the email form on the website.

That is only an issue for library authors that need to target a range of past versions which is the vast minority of Delphi users. Most migrate to a new version, start using that and never have to run their code through previous versions. Type inference for inline variables is a really nice thing - no need to explicitly decare the type just to tell the compiler (yes, if you name your variable properly the type is irrelevant for understanding the code, ask programmers from other languages that have this feature for a long time). Also often enough you have to add units to a uses clause just to declare a variable of a type that is the return of a method of some other type being used - with type inference that becomes unnecessary.

It would have been trivial to solve if only you'd used the debugger. Make it your next mission to learn how to use the debugger.