Uwe Raabe

You already can do that: {$IF Declared(TCustomAttribute)}

Perhaps I didn't explain it well enough. In case my code contains a check like: {$IF CompilerVersion < RAD_Chicago} {$IFEND} {$IF CompilerVersion < RAD_Sydney} {$IFEND} {$IF CompilerVersion < RAD_Rio} {$IFEND} that may perfectly compile with a future Delphi version named Chicago incorporating constants RAD_Chicago = 63; // no offence ... RAD_Sydney = 34; RAD_Rio = 33; ... but fails with any compiler available today. So I still need this one file with all these declarations and independent from the compiler. Where would be the benefit of Delphi providing a bunch of different versions of such a file where most of them are probably outdated and thus useless? Imagine we have each Delphi version in a separate VM, where almost all of these don't have the latest version of this file. Getting all this working will result in way more hassle than having this file maintained in one place, copying that into each project that makes use of it and keeping it up to date with each new Delphi version.

So it works with the small example, but fails in your main app? In that case there is something in your code you didn't show us. BTW, you indeed create a Form2 with Form1 as its owner, but as soon as you destroy Form2 it removes itself from Form1. So that is most likely not causing the problem. Just to make sure: In your example you name both forms MyForm. I hope that are different variables?

I try to write code that puts the lower Delphi versions under conditions. These are easier to eliminate when support for those older versions is dropped. Therefore you find constructs like {$IF CompilerVersion < 32.0 Tokyo } in my code, or sometimes even if CompilerVersion < 32.0 { Tokyo } then to avoid conditional compilation completely. Perhaps I am too lazy to update these include files in dozens of projects each time a new Delphi version arrives.

How would this affect older Delphi versions, which are the relevant targets according to "(intended for library devs that have to support many compiler versions)"? The problem is, that you need to use always the latest version of this file as part of your library, so it is capable to handle all Delphi versions. Even if starting with 10.5 Delphi would provide such a file itself, it will be outdated as soon as 10.6 arrives. So you have to use the newer file even for older Delphi versions, which somehow rules out such a file coming with Delphi itself.

Have you tried IOTAEditorContent.ResetDiskAge after setting the content?

While Scaled = False is not the suggested standard, is removing these properties still a general solution or does it only work for your use case?

And copy the method body in each? Well, it could split that code and put the pieces into the appropriate overload. On the other hand, that is exactly what a developer would do - and that is way more readable and maintainable (at least IMHO).

If the password is a string, which I think is what N'...' implies, can you change the script to take only the macro and use AsString in the code? FDQuery2.Macros.MacroByName('USER').AsRaw := 'Blablabla'; FDQuery2.Macros.MacroByName('USER_PASSWORD').AsString := 'Let me out !!'; FDQuery2.ExecSQL; ALTER LOGIN [&USER] WITH PASSWORD = &USER_PASSWORD, DEFAULT_DATABASE = [&Database], DEFAULT_LANGUAGE = [us_english], CHECK_EXPIRATION = OFF, CHECK_POLICY = OFF;

There is also an OnConstrainedResize event.

I suggest to create a class helper: type TComboBoxHelper = class helper for TComboBox private function GetText: string; public property Text: string read GetText; end; function TComboBoxHelper.GetText: string; begin Result := ''; if Selected <> nil then Result := Selected.Text; end;

If there is a demand for it (there is, I guess). Just give me a few days more.

I see that behavior, too, but I also noticed that the Form Designer doesn't receive the focus after selecting another component. You can see that when clicking the forms tab which only then changes to selected. This might be related to the fact that pressing <enter> in this situation focuses the Object Inspector with the last property selected (if available). You should describe your expectations with (very) detailed steps in QP.

Strange! Unfortunately without steps to recreate that will be hard to fix.

So there must be some difference between our systems. Tested with 10.3.3 and 10.4. No GExperts installed, though.

Either someone didn't understand FreeAndNil or the code used TObject in the first place and later changed to a typed pointer, but forgot to adjust the FreeAndNil call.

I see a different behavior here: when the focus is in inside the Form Designer and I press F11 the Object Inspector is shown and the focus is inside the search box. The Form Designer stays visible. when the focus is inside the Source Editor and I press F11 the Object Inspector is shown and the focus is inside the search box. The Source Editor stays visible. when the focus is inside the Object Inspector and a) the Form Designer is visible: the Source Editor is shown and focused b) the Source Editor is visible: the Form Designer is shown, but the Object Inspector keeps the focus That way I can cycle through these states by continuously pressing F11.

Shouldn't that read case TComponent(Sender).Tag of TAG_FOO : DoFoo; TAG_BAR : DoBar; ... end;

Version 15.0.20 should fix this issue.

Yes, that has already been reported by others and will be fixed with the next update. Meanwhile adding these entries to the registry is the suggested workaround.

Usually the Debug folder is inserted into the project search path at the beginning when you select "With Debug DCUs". The release folder stays in the search path as it comes from the library path for the selected platform. That way the files in the Debug folder take precedence over those in the Release folder. Only files not found in the Debug folder are taken from the Release folder.

Seems that a TCardPanel is better suited for your needs.

There is no decent number, but more votes may increase the probability for a fix to be included in a release. There is no guarantee, though.

If we can gather some more votes for that issue I will be happy to point the product management to it. As it seems to be some low hanging fruit (looks like a missing MoveViewToCursor call), we might have this being included in 10.4.1.

I knew I had heard of this before : Clicking in Search for Usages window doesn't scroll cursor into view