Anders Melander

That's a strange statement. Why are threads evil? Eric is trying to do something with a class that just wasn't designed for what he needs. That in itself doesn't make the design wrong or bad. The counter-argument is that no one knows how the functionality of a class' public API will be implemented in future. Class members are private in order to not lock a public API to a specific implementation bound to those private members; They shield the API from implementation details. You are basically arguing against the use of encapsulation.

About three decades of progress. Database Desktop was, as far as I remember, a heavily trimmed down version of the Paradox front end. Borland sold Paradox to Corel in the 90s and apparently Corel, or whatever they're called these days, is still stuck with it. So if you want a query tool that support Paradox and runs on modern Windows your best bet is probably Wordperfect Office (shudder).

I guess so. If only there was some kind of advanced technology one could use to help with that. I mean it's not like this is the first time.

🤦‍♂️ If only there was some way to communicate stuff like that to their users...

I haven't worked on POS systems for almost a year, so things might have changed since then, but I seem to remember that one of the components that were kinda important to the customers was the actual Point Of Sale part... Maybe ask your AI why it left that little detail out...

Yes I know what MVP means but you, your customers, or your sales department, still need to define the criteria for what a "viable" product is. You can't ask us for that because we have no stake in it and we don't know your target market. If you know the needs and demands of your market there are simple methods to define a MVP but it's not a process that involves developers.

That depends on how you define "viable", doesn't it? Nobody is going to be able to answer your question without additional requirements.

As far as I can tell it uses GetStringType(CT_CTYPE3) and skips codepoints with the C3_NONSPACING flag or without the C3_ALPHA flag.

...also known as the single character U+00E5 (Latin Small Letter A with Ring Above) of which U+0061 U+030a is the decomposition. But, even if the input was guaranteed to be composed Unicode then it would not be safe to replace CharPrev with a "-1" without knowing the exact algorithm CharPrev uses internally. The "looks like" part is nonsense since the glyphs produced by that sequence depends on the font being used to render it but it seems like CharPrev just skips all Combining Diacritical Marks.

It took me a bit longer than expected to get here but I believe I've finally reached the goal. The following shows VTune profiling a Delphi application, with symbol, line number and source code resolution: Download Get the source here: https://bitbucket.org/anders_melander/map2pdb/ And a precompiled exe here: https://bitbucket.org/anders_melander/map2pdb/downloads/ The source has only been tested with Delphi 10.3 - uses inline vars so it will not compile with older versions. Usage map2pdb - Copyright (c) 2021 Anders Melander Version 2.0 Parses the map file produced by Delphi and writes a PDB file. Usage: map2pdb [options] <map-filename> Options: -v Verbose output -pdb[:<output-filename>] Writes a PDB (default) -yaml[:<output-filename>] Writes an YAML file that can be used with llvm-pdbutil -bind[:<exe-filename>] Patches a Delphi compiled exe file to include a reference to the pdb file -test Works on test data. Ignores the input file Example: Configure your project linker options to output a Detailed map file. Compile the project. Execute map2pdb <map-filename> -bind Profile the application with VTune (or whatever) Known issues The -bind switch must occur after the filename contrary to the usage instructions. PDB files larger than 16Mb are not valid. This is currently by design. 64-bit PE files are not yet supported by the -bind option. As should be evident I decided not to go the DWARF route after all. After using a few days to read the DWARF specification and examine the FPC source I decided that it would be easier to leverage the PDB knowledge I had already acquired. Not that this has been easy. Even though I've been able to use the LLVM PDB implementation and Microsoft's PDB source as a reference LLVM's implementation is incomplete and buggy and the LLVM source is "modern C++" which means that it's close to unreadable in places. Microsoft's source, while written in clean C and guaranteed to be correct, doesn't compile and is poorly commented. Luckily it was nothing a few all-nighters with a disassembler and a hex editor couldn't solve. Enjoy!

Not that I know of. The file format is completely undocumented and there's no known API to extract info from it. A bit of googling found these: https://www.delphipraxis.net/48587-dcp-format.html http://hmelnov.icc.ru/DCU/ https://gitlab.com/dcu32int/DCU32INT/-/blob/master/DCP.pas?ref_type=heads The DCU32INT project looks like it could be a stepping stone.

Next up: How to use "with" to make your code more readable.

Nice catch!

The Win32 AlphaBlend API also requires alpha premultipled RGB. But just because the display API requires premultipled pixels doesn't mean that TBitmap should premultiply and then discard the source pixels. What it should have done is to create an internal premultipled copy of the source pixel data for display purpose if and when it was needed. The GR32PNG implementation can probably be adapted for FMX. It's the default PNG format handler in Graphics32: https://github.com/graphics32/graphics32/blob/master/Source/GR32_PortableNetworkGraphic.pas https://github.com/graphics32/graphics32/blob/master/Source/GR32_Png.pas

Are you really comparing the way an actual sentient intelligence learns principles by study to the way a language model works?... Well, I guess you are then. While that's an interesting fantasy, the reality is that you are equaling two entirely different things. Language models can not and does not form independent ideas; It can only function by copying, either directly or indirectly, existing work and nothing prevents a LLM from suggesting a solution based entirely on or copied verbatim from a single source - and that is a license violation.

Open Source does not mean that the code can be used freely. There are still conditions that must be observed (attribution, restrictions on usage, etc.). An AI (or the people that train it) doesn't care about that. I think that is naive. Have the people who wrote those policies earned your trust? In my POV, that whole industry has shown from the start that they can't be trusted. I don't think you understand how these things work; We are nowhere near being able to do anything like that. In fact that task would require a completely different type of AI. All we have now is one that is good at emulating stuff. Volkswagen wasn't a mistake or an accident. They knowingly implemented a mechanism to circumvent an environmental test. AI companies use the Science excuse instead; Their purpose and goal is more important than rules and ethics. If they were actually working a kind of AI that could do more than just copy other peoples work then I might understand it - but they aren't.

It does complicate things but yes, as you suggested, you could have a structure that contains both an TStream (for persistence) and a TBitmap (for display). The TBitmap would be created and loaded from the TStream once, on-demand, when the image needs to be displayed. This is also the technique used internally by many VCL image containers (e.g. TGIFImage, TPNGImage, TJPEGImage). That at least would mean you only "wasted" memory on the bitmaps that were actually displayed. Not really. The data in the stream is compressed and probably much smaller than the decompressed image data.

I don't use FMX and I haven't looked at the source but as far as I can tell, from your the images and description, the problem is that TBitmap premultiplies on load and unpremultiplies on save. The degradation of pixels with alpha<>255 is caused by the inevitable rounding errors. The VCL TBitmap has the same problem if one messes with the AlphaFormat property. Apparently they didn't learn from their first mistake and instead decided to make it worse. The reason the FMX TBitmap premultiplies the bitmap is probably because it needs that when displaying the bitmap (e.g. when using the Win32 AlphaBlend function). Anyway, the solution to your problem is to not use TBitmap as a storage container. Use TBitmap only for display of the image and use instead use TMemoryStream or something like it for storage.

Please also post the image as it is after you have saved it. My guess is that the load+save premultiplies the RGB with the alpha.

OP is using FMX. You are using VCL...

Specify the project Source language. Specify the current Target language. Enter the translations in the grid. I don't know what you mean by "how to use the source". The xlat file is BTM's translation project file; It contain the source texts and the translated texts for all selected target languages of the application being localized. BTM uses the information in this file to build the language modules (which are in fact just code-less DLLs containing the translated resourcestring and DFM resources) that are loaded at run-time by your application. See the Delphi help for info about how the Delphi localization system works (I believe I have some info at the project page too). See: Getting started

Not really but it's a very reasonable feature request. Please create an issue for it. I assume you mean a filter on the module list because you can hide already translated entries by filtering on State=Pending in the property list. If so, please create an issue for this too.

Your question doesn't make sense. Please rephrase it. You message, before you edited it, said "No HEBREW to translate". If you are asking how to add an additional target language, then that is done by clicking on the little settings button on the Language bar (yes, it's a bad UI, I know): ...and then selecting the desired target languages:

The RTLs DFM and resourcestring load mechanisms are separate and, for the most part, completely different. The RTL's resourcestring handling changed in a recent version of Delphi and, assuming your dynamic resource DLL loader doesn't take this into account, I suspect that this is the cause of your problem. The problem is likely that the RTL is caching both the resolved resourcestrings and the resource module, so once a resource module has been loaded and a resourcestring has been resolved it will not be read from the resource module again. My guess is that since your dynamic resource module loader probably executes after the RTL has already loaded the default resource module, your module is ignored. If you place a breakpoint in System.pas LoadResString and run your application you will be able to see the sausages being made. You should end up in DelayLoadResourceModule (via FindResourceHInstance) where the decision is made to reuse an already loaded resource module if there is one or load one if there isn't (FWIW, the DFM loader also goes through this function). Once system.pas has done its thing, sysutils.pas replaces the default resourcestring loader with a caching string loader, so all resourcestrings resolved after that point will be cached. If all my guessed are correct, the solution will be to modify the resource entry of the main module record (maybe your solution already does this). Something like this: var Module: PLibModule := LibModuleList; while (Module <> nil) do begin if (Module.Instance = hInstance) then begin Module.ResInstance := TheModuleHandleOfYourResourceModule; break; end; Module := Module.Next; end; Note that this will not change the already cached resourcestrings. In order to do that you will need to call SysUtils.ResStringCleanupCache If the above doesn't solve the problem for you I will need you to: Create an issue at the bug tracker Attach a minimal reproducible example and I'll see if I can find a solution.

A bit more specifics would have been helpful. E.g. a link to the repository, how did you "install" it, etc. Anyway, if it's actually an IDE plugin it's listed in (for Delphi 12): HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\23.0\Known IDE Packages If it's a component package it's listed in: HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\23.0\Known Packages You can just delete it from there. Save a copy of the registry tree (right click the parent node, select export) if you are unsure of what you're doing.