Uwe Raabe

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.

I usually write class helper for this. They can easily be removed when older versions are dropped.

Perhaps someone can write a DFM-to-Balsamiq converter. It's pretty much just a SQLite database.

Not that I am aware off. A workaround could be to open and save all forms in D2007 on a system with PixelsPerInch = 96.

The handling of PixelsPerInch has changed in recent Delphi versions with High DPI support. This may be the cause of what you see here.

Resizing an array to a smaller length doesn't invalidate the other elements. You should have range checking on to catch this error.

Indeed, it is a method with MethodKind = mkOperatorOverload.

No problems here. Everything working as expected. I am not aware of having tuned something for that.

Indeed, currently Hyper-V doesn't play well with any other hypervisor system. This is going to change in the near future at least for VMware Workstation, though.

Taken from: http://docwiki.embarcadero.com/RADStudio/Rio/en/Per_Monitor_V2