Uwe Raabe

That is not what can be read in that comment. I cannot see anything about licenses being invalidated or not being able to compile old code. Even the question does not imply that. It is only about downloading the setup files, isn't it? If my business were founded on the fact to be able to download old Delphi installation files I would do something wrong in the first place. I suggest to install old Delphi versions inside a VM and have a good backup strategy for those - like many people I know are already doing for years now. In case someone is worried about not being able to register a valid license later, the solution can be to convert the Named User license into a Network Named User license. That requires an ELC server installed somewhere in the local network, but it simplifies registrations a lot. License bumps are no longer necessary with that. Moving a Delphi installation to a new machine boils down to installing it and importing a slip file. My own situation covers quite some of your points. I have old software that has to be maintained (if at all) with old Delphi versions. Some of my customers are stuck with an old Delphi version, so I am regarding their projects. I see no problems in any of those. Even if Embarcadero would be hit by a comet, I would be able to work for plenty of years. No! If anyone would be affected there are ways to prepare for it and be safe. No problem and I think it is fair. There is plenty of other software where it is impossible to get old installation files now. I can still remember times when software was delivered in CD or even Floppy disks. We were used to make backup copies of those in case they will break and the vendor would charge for a replacement CD - if even offering that at all. One can do something similar for ISO images. Having that said, the other points are just meaningless.

You can also check the dproj file the DesignClass and FormType values to be correct. <DCCReference Include="Unit527.pas"> <Form>DataModule527</Form> <FormType>dfm</FormType> <DesignClass>TDataModule</DesignClass> </DCCReference>

I guess David is referring another assembler sequence.

The maintenance confirmation mail and the support terms say: There is a difference between the Primary Contact (the one who pays the bill) and Authorized Contacts (the developers using the product). So tell the person in charge in your company to assign you as an Authorized Contact.

For Windows 8+ there is InterlockedCompareExchange128

Yes, because the reference to tPolar2D is only inside tPoint2D, which still has to be declared after tPolar2D. The benefit of the operators is the ease of conversion by assignment. This is the (corrected) declaration with some example assignments (TBD: calculations): type tPolar2D = record Radius: Double; azimuth: Double; end; type tPoint2D = record x: Double; y: Double; public class operator Implicit(A: tPoint2D): tPolar2d; overload; class operator Implicit(A: tPolar2D): tPoint2D; overload; end; class operator tPoint2D.Implicit(A: tPoint2D): tPolar2d; begin Result.Radius := ... Result.azimuth := ... end; class operator tPoint2D.Implicit(A: tPolar2D): tPoint2D; begin Result.x := ... Result.y := ... end; var cart: tPoint2D; pol: tPolar2D; begin cart := pol; pol := cart; end.

What about operators: tPoint2D = record x: Double; y: Double; class function Implicit(A: tPoint2D): tPolar2d; class function Implicit(A: tPolar2D): tPoint2D; end;

I can't help, but this looks like you are trying to make that dictionary construct work like a database.

Well, that code is far from usable in production. F.i. you can still select that invisible control - at least if the space is not occupied by something else. I also get AVs when I unload that package.

Gerrit Beuze, the original inventor of MMX Code Explorer, managed to provide sort of a Micro IDE to test things.

IIRC, that functionality exists since Delphi 1. After 25 years someone finally managed to hit it. Congratulations.

Quick-And-Dirty ( complete package attached ) unit HideControls; interface procedure Register; implementation uses Vcl.Controls, DesignIntf, DesignEditors; type THideControlsEditor = class(TComponentEditor) private procedure SetDesignVisible(Value: Boolean); public procedure ExecuteVerb(Index: Integer); override; function GetVerb(Index: Integer): string; override; function GetVerbCount: Integer; override; end; procedure Register; begin RegisterComponentEditor(TControl, THideControlsEditor); end; procedure THideControlsEditor.ExecuteVerb(Index: Integer); begin case Index of 0: SetDesignVisible(False); 1: SetDesignVisible(True); end; end; function THideControlsEditor.GetVerb(Index: Integer): string; begin case Index of 0: Result := 'Hide Control(s)'; 1: Result := 'Show Control(s)'; else Result := ''; end; end; function THideControlsEditor.GetVerbCount: Integer; begin Result := 2; end; procedure THideControlsEditor.SetDesignVisible(Value: Boolean); var I: Integer; list: IDesignerSelections; begin list := CreateSelectionList; Designer.GetSelections(list); for I := 0 to list.Count - 1 do if list.Items[I] is TControl then TControl(list.Items[I]).SetDesignVisible(Value); end; end. HideControlsAtDesignTimeDemo.zip

I usually place a client aligned TPanel onto every TForm and TFrame with all borders removed and ParentBackground set to False. That way all forms and frames are drawn with the current styles panel color, which is usually the same as the form color.

You might have a look at DataSnap Callbacks then: http://docwiki.embarcadero.com/RADStudio/Rio/en/DataSnap_REST_Messaging_Protocol#Heavyweight_Callbacks

That should work with PerMonitor v2 as well. The application reads the DPI from the current monitor (even if there is only one) and scales accordingly.

Yes, that is what the DPI options in Manifest are for. If you have multiple monitors with different DPI and a more recent Windows 10 version I suggest the Per Monitor v2 setting.

Perhaps we are talking about different things. The settings for DPI awareness are only valid when running the application, not when designing it. A form designed with PixelsPerInch set to 120 is not scaled when opened In Delphi 10.3 on a system with PixelsPerInch=96. You already found that out. That is different to older versions and I am not aware of any setting to change that. You need to open the form with an older version of Delphi (still implementing this behavior) on the 96 dpi system, save the form with 96 dpi and you are good. In case you consider waiting for Embarcadero to fix this, there already is QP entry 15141 closed as Won't Fix.

Try with a fresh project. If that succeeds, find out the differences to your project.

Sounds like a TFlowPanel may be better suited for that. Just set the Control.Parent to the FlowPanel and then use FlowPanel.SetControlIndex to move it to the desired position.

If you have a static IP in your local router, you can add a port forwarding in the router to the FireBird server. This allows the FireBird server to be accessed from outside your local network. Note that this is actually opening up your local network to the Internet, so you need some expertise to setup all this in a safe and reliable way. If you are not familiar with the terms mentioned above, I suggest asking for professional help.

I guess you have to use overload methods. function Format(const Format: string; const Args: array of const): string; overload; function Format(const Format: string; const Args: array of const; const AFormatSettings: TFormatSettings): string; overload;

Actually, these messages should not be sent in the first place. Seems I somehow missed to switch of some settings before compiling the release.

Code that doesn't interact, so it can be split in separate parts without change. In the context above that means, one can identify properties, fields and methods in a class that can live on their own. If you delete all of these, the rest of the code is still compiling. Also vice versa, if you delete all the other code it still compiles. You can achieve the same result by just copying the class and then deleting one part in each.

The task to extract the controls from a tab sheet or other part of a form into a frame is quite common. A requirement is the code affecting those controls being orthogonal in the first place. The I am able to copy all relevant properties, methods and event handlers from the form class into the frame class. After that I can copy the controls from the form designer into the frame. This usually keeps the event handlers wired. After verifying that everything still compiles I am able to remove all those properties, methods and controls from the original form and clear the event handlers so that they will be removed. All this are about three or four steps when using MMX. I am pretty sure that writing an expert able to do all this automatically will be pretty complicated and error prone. It might work for some simple cases, but probably not for medium sophisticated code.

You can inherit from a class helper, so it is still possible to extend that one. Alas, that doesn't work for record helpers.