Uwe Raabe

IIRC, Snagit has that as default shortcut.

7 hours ago, Vincent Parrett said:

An opinionated formatter that doesn't allow me to configure to my taste is unfortunately not going to cut it.

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

57 minutes ago, JohnLM said:

 

I had a look at the Day-10 puzzle and I'm a bit confused with how they are detecting the asteriods. 

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

56 minutes ago, David Heffernan said:

I guess problems still arise when forms move back and forth at runtime. Because then you can't avoid down scale and then up scale. 

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.

1 hour ago, HeartWare said:

Always work internally (and store) values for 96dpi (100%) in the designer, only scaling it up for display.

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.

1 hour ago, Anders Melander said:

My own experience is that only having the necessary units in the implementation section improves compile time and reduces memory usage during compile.

Actually that contradicts the quoted suggestion. Therefore it is indeed misleading:

Quote

To reduce the chance of circular references, it's a good idea to list units in the implementation uses clause whenever possible.

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.

1 hour ago, ventiseis said:

Is that misleading?

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.

1 hour ago, ventiseis said:

But back to the original question: can we reduce our memory usage by the compiler if we follow a specific strategy with the uses clauses?

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.

3 minutes ago, ventiseis said:

we use subst to have the identical paths on every dev machine

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.

19 minutes ago, ventiseis said:

But this behaviour is broken in our environment: if I compile the same project twice, every single unit is compiled again to dcu - even if I do not change a single line of code!

We use an alternative dcu output path in the project options. It is a virtual drive created by the subst utility. If I remove that virtual drive and set the dcu output path to a different path, the documented behavior works again - i have no explanation for this.

Seems like you were asking the wrong question then.

7 minutes ago, ventiseis said:

but I tend to think that putting everything in the interface clause should improve compilation time and memory usage in the IDE.

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:

7 hours ago, MathiasBurbach said:

So a general mapping rule would not help.

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.

30 minutes ago, KuestenPeter said:

Is it somehow possible to use MMX V14.0.4  with Delphi 2007?  It is the first version where you dropped support for 2007

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

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

Just now, PeterBelow said:

for each row, set the number of columns with a SetLength(arrayvar, rowindex) call.

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

Project Magician has an option for that: 

Quote

Refresh Form Type

Sometimes the FormType entries in the project file are missing. This leads to the fact that during design time one cannot instantiate frames affected by this. This functionality restores the missing entries when opening a project.

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.

12 hours ago, Anders Melander said:

I also can't really see what they could do without breaking backward compatibility.

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.

16 minutes ago, Stano said:

hide the corresponding button in DBNavigator

That won't catch the keys pressed inside the grid itself. The BeforeInsert event is indeed the best place.

I would rather say that are 21 seconds (which is probably less than I actually need to just read the description). This is backed by this quote from the About text:

Quote

Depending on the puzzle, that day's leaderboard usually fills up anywhere between two minutes and an hour.

Since the start time of each puzzle is  way out of my awake periods a day, I can thankfully ignore the ranking system completely. This allows me to concentrate on finding a suitable solution, sometimes even a clever one.