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.

MMX V15.1.1 fixes some problems encountered with V15.1 and enhances the new directive aware parser. While evaluating IFDEFs was a long requested feature its actual implementation did raise some issues. One consequence of evaluating directives is that parts of the code are hidden from the MMX explorer. Only code that is embraced by conditions evaluating to True are taken into account in the explorer. F.i. a unit with this code: unit Example; interface {$IFDEF MYDEF} type TMyType = class public procedure MyProc; end; {$ENDIF} implementation {$IFDEF MYDEF} procedure TMyType.MyProc; begin end; {$ENDIF} end. will end up in an completely empty explorer. The only workaround in V15.1 was to place a {$DEFINE MYDEF} somewhere before the IFDEF to make MMX explorer see that class TMyType. Unfortunately that will also make the compiler see that class, which is probably not what you want. V15.1.1 offers two solutions to this (which can also be combined): The parser silently defines MMX. This allows to wrap the {$DEFINE MYDEF} inside an {$IFDEF MMX}/{$ENDIF}, so the compiler doesn't see it. The Project options page in the MMX Code Explorer properties dialog allows to have a special set of Defines and $IF Expressions used only by the MMX parser. Another unwanted effect in V15.1 was that the content of include files were added to the explorer, which was completely unintended, because they belong to another module (the include file). This has been fixed in V15.1.1 and the include file directives are added to the module section. A double click will open the file.

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)

That is most likely because you only use a small part of these packages. When building a monolithic exe the compiler will only take the parts actually used, but the packages contain a lot more.

I'm sorry, but it seems you answered the question yourself. There simply is no MMX DLL that can be loaded in D2007.

There is a new beta available. Changing the version number to 15 resembles not only the completely different new look due to theme support and new icons, but also the internal changes necessary to make all this work. Hopefully I didn’t break too much.

The menu Project -> Information for <xxx> should give you this: Information for Project

This doesn't seem right. The call should be SetLength(arrayvar[rowindex], columnsize), shouldn't it?

Project Magician has an option for that:

If you build a project, all visible sources are compiled. Only when you just compile a project where the dcu and source are both available, the source is compiled only when its time stamp or memory content is newer than the binary. If you don't want to compile any library sources but always use the binary, you must remove the source from Tools > Options > Language > Delphi > Library > Library path as well as from Project > Options > Building > Delphi-Compiler > Search Path. Unfortunately that removes the ability to debug the library sources. To fix that, you have two options. Which you choose depends on where you add the binaries folder: A: Tools > Options > Language > Delphi > Library > Library path: Add the source folder to Browsing path in the same dialog. B: Project > Options > Building > Delphi-Compiler > Search Path: Add the source folder to Project > Options > Debugger > Source Path Obviously, solution A affects all projects, while B affects the current project only. Note: You have to compile the library with debug options to make that work. With solution A you can separate the debug binaries from the release ones by placing the debug binaries in a separate folder (just as the Delphi lib folder is organized) and add the debug binaries folder to the Debug DCU path entry of Tools > Options > Language > Delphi Options > Library. This will allow to use the debug binaries when the Use debug .dcus option is set in Project > Options > Building > Delphi-Compiler > Compiling.

Indeed! Probably no one at Embarcadero is going to change a that old behavior, because no one can say for sure what the consequences would be for existing code. Asking here only reaches a small part of the existing Delphi developers, from which some may not even know whether their code relies on the current implementation or not. I second Anders view of better using a workaround. Besides his suggestion, you can also write a sentinel value as the only collection item, which is removed after reading. Candidates for interception can be the ReadState/WriteState methods of the component. In WriteState add the sentinel when the collection is empty before calling inherited and in ReadState remove the sentinel if found after calling inherited.

So your certificate has been issued in 2022 and thus doesn't fall under the new hardware rules. You can use it as long as it is valid, but then you need one of the new ones bound to a hardware token.