Leaderboard

Because there are differences between different operating systems and how their internals work. In other words, some things and some workflows that are possible on one operating system is impossible on another. Like I said before ExecuteWork is internal method and MUST NOT be used. It is part of the interface so internal code can call that method when appropriate, but this method is not part of public API. Forget that it exists. Just because some method is available and can be called does not mean it is meant to be used by developers, regardless of how it is available - through interface or directly through object instance. Another example of methods that should not be called directly is TThread.Execute, or TObject.FreeInstance... there are plenty of such examples around.

In the end, I had to abandon PUCU as the author never bothered to react to my bug reports. Instead, I tried to adapt the JEDI implementation: I removed all dependencies and fixed the worst bugs and performance issues. Finally, I ran the code against my unit tests. The result was a big disappointment; While it didn't crash like PUCU, it failed even more of the test cases. The test suite uses the 19,000 NFC (compose) and NFD (decompose) normalization test cases published by the Unicode consortium. So back to square one again. Comparing the algorithms used by the JEDI library against countless (I've looked at over a hundred) other Unicode libraries didn't reveal the cause. They all used the same algorithms. Blogs and articles that described the algorithm also matched what was being done. I was beginning to suspect that Unicode's own test cases were wrong, but then I finally got around to reading the actual Unicode specification where the rules and algorithms are described, and guess what - Apart from Unicode's own reference library and a few others, they're all doing it wrong. I have now implemented the normalization functions from scratch based on the Unicode v15 specs and all tests now pass. The functions can be found here, in case anyone needs them: https://gitlab.com/anders.bo.melander/pascaltype2/-/blob/master/Source/PascalType.Unicode.pas#L258 Note that while the functions implement both canonical (NFC/NFD) and compatible (NFKC/NFKD) normalization, only the canonical variants have been tested as they are the only ones I need.

@bravesofts This was already covered on your StackOverflow question yesterday: delphi Thread ITask.ExecuteWork not wait until Task finish in mobile devices? Guess you didn't like what you were told there? So you came here instead, just to be told the same things. Funny how the same knowledge can span across multiple forums, huh? 😉

Reminds me of this one: Why does a call to GetDIBits fail on Win64?

@dummzeuch I dont know this format, but here have a sample in C step-by-step (if help you) https://imkaywu.github.io/blog/2016/04/ply/

Yes, it is impossible. Also this approach while works on Windows is also not the best one. The only way to wait is using fTask.Wait, but then the main thread will block and OS will kill your application. If you need to run some code after task completes the only way to do that is from within task procedure. Also if you start a task and then call wait you are defeating the purpose of having background thread in the first place. begin _Taskcomplete := false; fTask := TTask.Create( procedure begin // Here you do your task code while not _Taskcomplete do Lbl_Task.Text := ElapsedSec.ToString; TThread.Synchronize(nil, procedure begin // Here you can call code that needs to run after task is finished Lbl_Task.Text := 'task complete ..'; showMessage('we wait until Task Complete to show you this message !!'); end); end); fTask.Start; end;

No. The reason to create a thread is to move to the next line without waiting for a block of code (inside the thread) to complete. That's the purpose for threads in every platform.

It's a shame this thread slipped into a gender debate unnoticed. Sorry about that. BTT: https://meta.stackexchange.com/questions/390106/moderation-strike-update-data-dumps-choosing-representatives-gpt-data-and-wh

Macbook M1

32-bit and 64-bit Windows Apps Runs fine in Windows for ARM under Parallells on my MacBook Pro M1 (macOS Ventura 13.4.x)

I contributed ISO8601-compliant DateTime parsing to DUnitX: VSoftTechnologies/DUnitX: Delphi Unit Test Framework (github.com) I'd recommend using ISO8601 so that it doesn't depend on the build machine's locale.

I had some curious bug today with the following code: procedure ReadHeader(out _w, _h, _Depth: Integer); const PGM_Magic_Number = 'P5'; var s: string; begin s := ReadChar + ReadChar; if s <> PGM_Magic_Number then raise ESigError.Create(_('File is not a valid PGM file:') + ' ' + _fn); // more code here end; Which failed the test even though the first call to ReadChar returns 'P' and the second returns '5' (I stepped through it in the debugger) so s should have been 'P5', but the actual value of s was '5P'. Apparently Delphi created code that called the second ReadChar before the first. But why? Maybe because it fills the parameters for the function System._UStrCat3, that it apparently calls to do the concatenation, from right to left? So I changed the code like this: procedure ReadHeader(out _w, _h, _Depth: Integer); const PGM_Magic_Number = 'P5'; var s: string; begin s := ReadChar; s := s + ReadChar; if s <> PGM_Magic_Number then raise ESigError.Create(_('File is not a valid PGM file:') + ' ' + _fn); // more code here end; and it works now.