Uwe Raabe

The phrase when you report the error is most likely targeting the official issue tracker at https://qp.embarcadero.com/ and not this forum.

In MMX options select Pascal - Sorting. In the group Format unit uses clauses check Group and sort uses clause. Next time you execute Format Uses Clause (Ctrl-Alt-U) the unit names are resolved based on the current Unit Scope Names of the current project. If you don't want the grouping you can simply empty the Groups entry in MMX Project options.

MMX Code Explorer can do this and GExperts has a similar option, IIRC.

I'm pretty sure that meanwhile they've already got it.

It depends a bit what the exact use case is, but it probably can be achieved with a class derived from TMemo with the following extensions: type TLinkMemo = class(TMemo) private FLinkedMemo: TLinkMemo; procedure WMVScroll(var Message: TMessage); message WM_VSCROLL; procedure DoScroll(var Message: TMessage); public property LinkedMemo: TLinkMemo read FLinkedMemo write FLinkedMemo; end; procedure TLinkMemo.DoScroll(var Message: TMessage); begin var saveLinkedMemo := FLinkedMemo; try FLinkedMemo := nil; Perform(Message.Msg, Message.WParam, Message.LParam); finally FLinkedMemo := saveLinkedMemo; end; end; procedure TLinkMemo.WMVScroll(var Message: TMessage); begin inherited; if FLinkedMemo <> nil then FLinkedMemo.DoScroll(Message); end; In FormCreate you just assign both LinkedMemo properties: procedure TForm1.FormCreate(Sender: TObject); begin Memo1.LinkedMemo := Memo2; Memo2.LinkedMemo := Memo1; end; To avoid having to register this new control TLinkMemo you can use an interposer class declared before the form, either in the same unit or in a separate unit used in the interface uses clause. type TMemo = class(TLinkMemo); Note, that editing one of the memo will break sync between the controls.

That doesn't surprise me. At least we've got some insights now.

While there might be a technical reason for this and it may as well be well thought through at that time, it doesn't hinder us to ask for a change. If that turns out to be impractical, needing too much effort or just impossible without breaking everything, we hopefully get a decent explanation about it.

There are different approaches: Everytime a form takes focus it inserts itself at the top of Screen.CustomForms ShowModal inserts the previously focused form at the top of Screen.SaveFocusedList

The "why" is probably caused by a specific decision taken a long time ago. The people having taken it are most likely no longer at Embarcadero, so we might not even ask them about it.. Fortunately the "why" is almost irrelevant, as you can issue a feature request for a change.

Static class methods miss the implicit Self parameter, which holds the current type called. They are quite similar to global procedures/functions and therefore they cannot be virtual - there is just no VMT available. It is the same reason why static class methods cannot call virtual methods.

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

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.

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.