Der schöne Günther

https://quality.embarcadero.com/browse/RSP-23466 reports that OmniThreadLibrary is also affected. Can somebody confirm that?

Still doesn't help you for something like this: procedure p(x,y: Byte); begin if (y = 0) then raise EArgumentOutOfRangeException.Create( NameOf(y) + ' must not be zero'); (...) end;

I'm doing kiosk software that runs 24/7 and has to be able to cope with a sudden power loss. To get around the problem of corrupted local files, I usually Create a windows file handle with the flags FILE_FLAG_WRITE_THROUGH for a file like "config.ini.new" Pass that handle to a THandleStream, and save my content by SaveToStream(..) or whatever Call FlushFileBuffers(..) on that handle Close the windows file handle Atomically move "config.ini.new" to "config.ini" "Atomically move file" just boils down to procedure moveFileAtomic(const fromPath, toPath: String); const flags = MOVEFILE_REPLACE_EXISTING or MOVEFILE_WRITE_THROUGH; begin Win32Check( WinApi.Windows.MoveFileEx( PChar(fromPath), PChar(toPath), flags ) ); end; So far, everything was fine. Now I thought I was being smart and skipped step 1-4 by just using System.IoUtils.TFile.WriteAllText(filePath, fileContent). At one client with a power loss, that file ended up on disk, but just contained nullbytes. The WriteAllText method from Delphis library boils down to calling CreateFile(..) with FILE_ATTRIBUTE_NORMAL So basically what I guess must have happened: The file was not yet written do disk, and MoveFileEx moved something that wasn't even there yet. I cannot reproduce this by normally running software and not yanking the power cord out. My question is: What exactly was the cause? Was I missing FlushFileBuffers(HANDLE), was is that the original must have been created with FILE_FLAG_WRITE_THROUGH as well?

"Currency" is money. Do you mean money or plain numbers?

I don't have my RAD Studio in English, so the translation might be off: Project options -> Delphi Compiler -> Hints and Warnings -> Not supported language Features You can set this from "True" to "Error" so the compilation will stop.

Are you sure F8 is the right hotkey? I think in your case, it should be Shift+F8 (run until return). Also, TStringList is from Delphis default RTL. Be sure to have "With Debug DCU files" checked in your project or you cannot have breakpoints in there.

Nothing against nested methods (altough I never use them), but what you show is way over the top. Let's put all these things in a single class.

It's beyond me why, if it's never getting fixed, why they can't at least add a compiler warning. We don't even have warnings for the most obvious mistakes like using an uninitialized return value or this. I don't understand why.

Do you mean just using the pen for drawing some stuff (maybe including text recognition)? Or are we talking about more elaborate things like tilt angle of the pen or using built-in graphical brushes like pencils? If the first is enough for you, these features have been in Windows since XP. If you don't mind Kraut language, some fine gentleman put together a very decent demo that does text recognition in a VCL application => https://www.delphipraxis.net/192146-stift-eingabe-zum-schreiben-auf-tablet.html By the way: Of course the Microsoft Surface might be the most famous device, but it's not limited to Surface devices. A lot of devices have pen support, some also with tilt support.

This is something I really miss when using other IDEs, I really fell in love with "every 10nth line number".

There is an (outdated) copy of Spring4D on Github, just for Delphinius: https://github.com/Spring4D/Spring4D I also asked myself that. Not going to complain - Just double-clicky and you're done. But I also wondered if there was another reason beside comfort.

But wouldn't that require the "CallerThread" to support something like this? As far as I know, only the Delphi main thread has something like this, queueing/synchronizing something to a regular TThread has absolutely no effect.

Only who supplies the callback (your TForm1) knows if it's important to have it synced to the main thread or not. So it should take care of synchronizing/queueing it to the main thread, not your TCompressor.

Wasn't ModelMakerTools for Delphi able to do that?

I find it difficult to keep track of all the different products and technologies. VirtualBox is easy, I got that. Hyper-V appears to be more or less the same, it's a virtual computer running on some host (like my local machine). Then, there is the new Windows Sandbox. And there is "Application Guard" which allows some applications (like a browser) to run in a shielded environment, but display regular windows on my desktop. And then there is "App-V", which has been around since Windows 7, I think. Are they related?

A TWinControl has a method RecreateWnd(): http://docwiki.embarcadero.com/Libraries/en/Vcl.Controls.TWinControl.RecreateWnd Maybe you can have a look at the VCL sources where this gets called...

Wouldn't that be the easiest? I don't see much of a "problem" of how to know when everything is ready. By default, it should be after the first time OnShow (or maybe even OnActivate) has been called. This can be done in your base class. If you need more elaborate logic in one form class, then you can override that behaviour.

NTFS allows files to be compressed. When a directory is compressed, that just means its files automatically inherit the "compressed" attribute. You can use WinApi.Windows.GetCompressedFileSize(..) to find about how many bytes a file actually uses on disk. When compressed, it is less than the actual file content.# My "problem": When a file is written into a directory with the "compressed" attribute set, it will first get written without compression, then Windows will take care of compression in the background. While I query the "true" file size with GetCompressedFileSize(..), I can see it shrinking. I would like to find out when the compression has finished. Is it possible? In case someone wants to test a running Demo, here is the source for a console application: https://gist.github.com/JensMertelmeyer/eb238ce57f8bb6cbb1ef3514c3d58ae8

Thanks, I will try that. I didn't notice the file was supposed to be locked, I think it could still be moved around in explorer while compression was taking place but I might be wrong.

Sorry, I didn't know. That really paints a different picture of the whole situation.

No Embarcadero "This repo is a copy of our GetIt stuff"-type of thing, I meant the repo of the thing I wanted to use. Clone it, store it offline, never worry again. GetIt is great for quickly trying things out. If you rely on a component, get it from somewhere you can rely on (your own disk).

A year back or so, GetIt stopped working for 10 Seattle. I opened a support ticket with Embarcadero. I'm glad they were honest and told me they weren't going to fix it and I should download stuff from Github instead. That really showed it's nice for quickly trying something out, but no one knows when it will stop working.

But doesn't that defeat the purpose of using a thread in the first place if there can only be one canvas operation at a time?

Querying a random internet search engine with "Delphi TBitmap Thread", it appears to me as TCanvas is not meant to be used in threads. There are countless threads on this subject.

With proper source control you would have seen this immediately 🙃