Uwe Raabe

IIRC, Snagit has that as default shortcut.

Been thinking about writing exactly the same. I worked with quite a lot of developers falling in this category, too.

As I cannot make any sense out of your question: Do you refer to the Day 10 Puzzle of 2024?

It depends on the way you do the scaling. If the form is created and loaded with 96dpi and you scale up there is non loss. When it comes to another scaling, you need to downscale to 96 dpi first and then upscale to the required scaling. This assures that the positions and sizes for each scale are consistent.

Yes, upscaling and downscaling by the same factor keeps all values intact (I provided a mathematical proof for that), but downscaling and upscaling does not. That was the main reason for my feature request: RSP-35301 - Option to design in Screen PPI but save in 96 PPI

In MMX Properties - Pascal - Parser - Miscellaneous there is an option Parser evaluates conditions.

Actually that contradicts the quoted suggestion. Therefore it is indeed misleading: Also I'm eager to see any measurements backing your experience about improved compile time and reduced memory usage when placing units in the interface uses clause instead of the implementation one.

Indeed. I can only assume that the term to reduce the chance of circular references is meant as to reduce the chance of errors about circular references. To be more specific: Circular references are not bad in the first place. They only put some additional burden onto the compiler. If using pre-compiled DCUs you won't see any performance drop. That's why some developers avoid compiling the sources of 3rd party libraries and use only their DCUs instead. In fact we all do this with the Delphi libraries, which are full of circular references, BTW.

I guess that question can only be answered by someone from Embarcadero familiar with the compiler internals. On the other hand, cyclic dependencies between units do make a significant difference in performance and probably also in memory consumption. As moving all units into the interface uses clause will just not allow circular dependencies, so it may guide you to pure non-cyclic units and thus increase performance. That doesn't imply that this cannot be achieved with units in the implementation uses clause. Personally I didn't notice any drawbacks with the latter approach.

This raises the question why you need absolute path names for the dcu output in the first place. IIRC that is a no-go for build systems and should be avoided in development systems, too. Although I also use alternative dcu output paths (usually to separate dcu output for different projects in a project group in addition to separate platforms and build configurations), all of these are relative to the project. As I often have multiple work trees of a repo, I would open a can of worms when all of them were using the same dcu output folder.

Seems like you were asking the wrong question then.

Can you explain how you came to this conclusion or is it just a gut feeling?

Adding this mapping to the query makes field c a Double:

Mapping rules can be added to each query and have a NameMask. This allows to specify a rule for only one field of one query.

Have you tried adding a MapRule for field c? See Data Type Mapping (FireDAC)