Der schöne Günther

Oh my, Dev-Cpp brings back memories. I never knew it was built with Delphi/C++ Builder.

A deployment manager deploys files. It's not an installer. Maybe they will add something like this once RAD Studio will also support MSIX.

I don't quite understand what you mean with "different part of the system". Every packaged app gets its own view of the registry and the file system. Here is a good summary: https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes

Yes, you're in control of what you do there. I think its the most straightforward way.

I honestly don't think the deployment manager is the right tool for this. It's intended to bundle the sqlite template with your app, but not initialize "first run" scenarios. The user files belong in %AppData% and Windows takes care of virtualizing this per user. So all you have to do is, at runtime, take your local .sqlite file and copy it to %Appdata%\... if it's not already there.

Can I make a suggestion? I have so often tripped over ignoring an exception and then forgetting about it, the exception being ignored even days later. Would it be possible to add something like "scope" for these rules? Something like This debugger session This project Global

You're making it unnecessarily hard for you if you rely on interface elements (like the TMemo) for data storage and processing. I guess the button "Read data" gets the numbers from the memo and then keeps them in an array or list? If yes, that's good, because it's probably the hardest part. Because if you have your numbers in a list or an array, you can then easily loop over them with a for statement. If you have some code (especially what is behind your "read data") then we could help with advice tailored to your project, instead of general recommendations.

Interesting. I was under the impression that the image was still exported as a JPEG image, even though AllowVectorExport was already true. Thanks, I will give it a try 😊

I don't even use bitmaps but vector images but yes, that seems to be the cause. I set PrintOptimized to false, and the speed is now tolerable. At least on one of the reports I tested. Many thanks! I have been unable to find documentation, the RAD Studio installation ships with a PDF file that dates back to 2008, but I also found this blog entry where PrintOptimized is also mentioned: http://web.archive.org/web/20200525054725/https://www.fast-report.com/en/blog/324/show/ Thanks.

I have completely migrated a project that was built with Delphi 10.0 Seattle with Fast Report VCL 5.1.5 (and a few others, like TeeChart Pro) to Delphi 10.4 Sydney with Fast Report VCL 6.7. I am having a problem with FastReport, especially the PDF export. I am generating "reports" that are just one A4 page in size, with a few images (TMetaFile). In FastReport 5/Delphi Seattle, it was more or less instant. Now, a PDF export for one page takes up to ten seconds. When I use the debugger to pause the application, the stacktrace often looks something like this: :009c086c ; C:\Users\localUser\Desktop\myProject\Win32\Release\myApp.exe :009bcde9 jpeg_write_scanlines + $9D :009b03d6 TJPEGImage.JPEGNeeded + $E frxExportPDF.TfrxPDFExport.AddObject(???) frxExportPDF.TfrxPDFExport.ExportObject($4086150) frxPreviewPages.ExportObject($4086150) frxPreviewPages.ExportPage(0) frxPreviewPages.DoExport frxPreviewPages.TfrxPreviewPages.Export($38DD5D0) frxClass.TfrxReport.Export(???) :009c18ba @jpeg_fdct_float + $246 :009bee45 ; C:\Users\localUser\Desktop\myProject\Win32\Release\myApp.exe :009bcde9 jpeg_write_scanlines + $9D :009b03d6 TJPEGImage.JPEGNeeded + $E frxExportPDF.TfrxPDFExport.AddObject(???) frxExportPDF.TfrxPDFExport.ExportObject($4086150) frxPreviewPages.ExportObject($4086150) frxPreviewPages.ExportPage(0) frxPreviewPages.DoExport frxPreviewPages.TfrxPreviewPages.Export($38DD5D0) frxClass.TfrxReport.Export(???) Since I don't have the FastReport source code, I can only guess what is now suddenly taking so long. Directly printing to a printer is a bit faster, but still considerably worse than with Fast Report 5. Does anyone have a clue? I am not aware of any new features that Fast Report 6 added, maybe it's possible to use an older Fast Report 5 version with 10.4? Probably not 😐

Thanks for elaborating. I would have expected both versions to behave the same since they should have the same package id (although different manifests). So it seems like the "Associate this app with a store entry" button in Visual Studio really is necessary. I found no exact details on what it actually does, but maybe these two links are helpful: What does the "Associate App with the Store" wizard do? Submitting an app to the Microsoft Store (MR) With no further details, it's probably no fun trying to figure out what VS actually does (maybe by monitoring with tools like Process Monitor) and then re-create it for RAD Studio. I just did some fumbling around in VS, and after getting through the "Associate App with the Store", it generated a "Package.appxmanifest" and a "Package.StoreAssociation.xml" file. Maybe those help. I'm still doubtful whether it actually matters which certificate was used to sign it... Another way would probably be skipping the packaging part in RAD Studio and doing it entirely with something like the MSIX Packaging tool.

The error message means that you will need to add the certificate (the one you used to sign your local .appx) to the "trusted root certificate directories" (or whatever the proper English name is). Have you never run/installed a self-signed .appx before? But yes, it seems that the RAD Studio documentation doesn't mention you need to add your own certificate to the trusted root certificates: https://stackoverflow.com/a/53174601 http://docwiki.embarcadero.com/RADStudio/Rio/en/Creating_a_Certificate_File

I would guess this is because it's simply not packaged and doesn't even have a package id. If you ran the generated .appx file and have not changed anything in the manifest, I would expect it to continue to work - Given that you have already installed it from the store at least once. This is also what the documentation states: and

I'm puzzled why a UnicodeString is the only thing that leaks. If the problem was a missing disposal of a JSON object, we should be leaking much more. It's just a stupid idea, but were you running in the debugger? I think sometimes, if you inspect values, the debugger increases the reference count on managed things like arrays or strings and will keep them alive until the very end of the application.

Your Delphi version would be interesting.