Uwe Raabe

Have a look at TNumberBox.

A file is stored in the format it has been loaded, unless you change the format via the File Encoding selector at the bottom of the editor. You can change the default encoding for new files in the Editor options.

It is located in the bin64 subfolder, which already exists. Most of the new 64-bit files are placed there, too. A couple of 64-bit design time BPL and DCP files are added to the appropriate places. The amount of additional needed disk scape can be neglected. The 64-bit IDE shares most of the registry entries, while adding a couple of x64 keys like Known IDE Packages x64 and Known Packages x64.

That's exactly my experience and the reason why such a feature would not bring any significant advantage for me.

Vcl.Graphics internally registers the following extensions: tiff, tif, wmf, emf, ico and bmp. All other extensions are registered in the units the format is implemented: gif in Vcl.Imaging.GIFImg jpeg and jpg in Vcl.Imaging.jpeg png in Vcl.Imaging.pngimage svg, webp and wbmp in Vcl.Skia Only when these units are used in your application the corresponding file extensions will be supported. While designing in the IDE, these units are usually registered because the vclimg and the Skia packages are loaded.

Calling GraphicFileMask(TGraphic) from Vcl.Graphics will give you a list of supported extensions.

I found the solution using the SB_THUMBPOSITION approach working best for all my tests. As I was a bit irritated by the WM_KEYDOWN, WM_MOUSEFIRST..WM_MOUSELAST (why act on every keystroke or mouse move?), I used the previous approach with CN_COMMAND, WM_HSCROLL and WM_VSCROLL message handlers: type TLinkMemo = class(TMemo) private FLinkedMemo: TLinkMemo; procedure CNCommand(var Message: TWMCommand); message CN_COMMAND; procedure WMHScroll(var Message: TMessage); message WM_HSCROLL; procedure WMVScroll(var Message: TMessage); message WM_VSCROLL; procedure SyncLink; public property LinkedMemo: TLinkMemo read FLinkedMemo write FLinkedMemo; end; procedure TLinkMemo.CNCommand(var Message: TWMCommand); begin inherited; if (Message.NotifyCode = EN_VSCROLL) or (Message.NotifyCode = EN_HSCROLL) then SyncLink; end; procedure TLinkMemo.SyncLink; procedure UpdateScrollBar(BarFlag: Integer; Msg: Cardinal); var scrollInfo: TScrollInfo; begin scrollInfo.cbSize := SizeOf(scrollInfo); scrollInfo.fMask := SIF_POS; if GetScrollInfo(Handle, BarFlag, scrollInfo) then LinkedMemo.Perform(Msg, MAKEWPARAM(SB_THUMBPOSITION, scrollInfo.nPos), 0); end; begin if LinkedMemo = nil then Exit; var savedLink := LinkedMemo.LinkedMemo; try LinkedMemo.LinkedMemo := nil; UpdateScrollBar(SB_HORZ, WM_HSCROLL); UpdateScrollBar(SB_VERT, WM_VSCROLL); finally LinkedMemo.LinkedMemo := savedLink; end; end; procedure TLinkMemo.WMHScroll(var Message: TMessage); begin inherited; SyncLink; end; procedure TLinkMemo.WMVScroll(var Message: TMessage); begin inherited; SyncLink; end; A more sophisticated solution can separate the HSCROLL and VSCROLL events and reduce the UpdateScrollbar call to the corresponding part.

I am pretty sure that this has never worked before - at least it does not in Delphi 7, Delphi XE8 or Delphi 12. So instead of filing a bug report this should probably better be a feature request. Besides that, I actually have problems using the mouse wheel while pressing the left mouse button, but that can also be caused by my age.

A quick look into REST.Consts.pas reveals: const HTTP_HEADERFIELD_AUTH = 'Authorization'; // do not localize It is used by the TCustomAuthenticator components, which a TRESTClient can be linked to via its Authenticator property. Especially TOAuth2Authenticator comes to mind with TokenType set to ttBEARER and AccessToken set to the proper value.

Perhaps you should specify the tests you are doing more precisely.

Horizontal scrolling can be made to work, but doing that with the mouse wheel always produces glitches. I guess, it is because the scrolling is done with pixels, while EM_LINESCROLL does it with characters. type TLinkMemo = class(TMemo) private FLinkedMemo: TLinkMemo; FSkipScroll: Boolean; procedure CNCommand(var Message: TWMCommand); message CN_COMMAND; procedure WMHScroll(var Message: TMessage); message WM_HSCROLL; procedure WMVScroll(var Message: TMessage); message WM_VSCROLL; procedure SyncLink; procedure DoScroll(var Message: TMessage); public property LinkedMemo: TLinkMemo read FLinkedMemo write FLinkedMemo; end; procedure TLinkMemo.CNCommand(var Message: TWMCommand); begin inherited; FSkipScroll := False; if (Message.NotifyCode = EN_VSCROLL) or (Message.NotifyCode = EN_HSCROLL) then begin SyncLink; FSkipScroll := True; end; 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.SyncLink; begin if LinkedMemo = nil then Exit; var saveLink := LinkedMemo.LinkedMemo; try LinkedMemo.LinkedMemo := nil; var myFirstVisibleChar := Perform(EM_CHARFROMPOS, 0, 0); var linkFirstVisibleChar := LinkedMemo.Perform(EM_CHARFROMPOS, 0, 0); if myFirstVisibleChar = linkFirstVisibleChar then Exit; var myLineIndex := Perform(EM_LINEFROMCHAR, myFirstVisibleChar, 0); var myLineStart := Perform(EM_LINEINDEX, myLineIndex, 0); var myCharIndex := myFirstVisibleChar - myLineStart; var linkLineIndex := LinkedMemo.Perform(EM_LINEFROMCHAR, linkFirstVisibleChar, 0); var linkLineStart := LinkedMemo.Perform(EM_LINEINDEX, linkLineIndex, 0); var linkCharIndex := linkFirstVisibleChar - linkLineStart; LinkedMemo.CaretPos := CaretPos; if myCharIndex < linkCharIndex then begin LinkedMemo.CaretPos := TPoint.Create(0, myLineIndex); LinkedMemo.Perform(EM_SCROLLCARET, 0, 0); LinkedMemo.CaretPos := CaretPos; linkCharIndex := 0; end; LinkedMemo.Perform(EM_LINESCROLL, myCharIndex - linkCharIndex, myLineIndex - linkLineIndex); finally LinkedMemo.LinkedMemo := saveLink; end; end; procedure TLinkMemo.WMHScroll(var Message: TMessage); begin inherited; if FSkipScroll then begin FSkipScroll := False; Exit; end; if LinkedMemo <> nil then LinkedMemo.DoScroll(Message); end; procedure TLinkMemo.WMVScroll(var Message: TMessage); begin inherited; if FSkipScroll then begin FSkipScroll := False; Exit; end; if LinkedMemo <> nil then LinkedMemo.DoScroll(Message); end;

OK, next iteration: type TLinkMemo = class(TMemo) private FLinkedMemo: TLinkMemo; procedure CNCommand(var Message: TWMCommand); message CN_COMMAND; procedure WMHScroll(var Message: TMessage); message WM_HSCROLL; procedure WMVScroll(var Message: TMessage); message WM_VSCROLL; procedure SyncLink; public property LinkedMemo: TLinkMemo read FLinkedMemo write FLinkedMemo; end; procedure TLinkMemo.CNCommand(var Message: TWMCommand); begin inherited; if (Message.NotifyCode = EN_VSCROLL) or (Message.NotifyCode = EN_HSCROLL) then SyncLink; end; procedure TLinkMemo.SyncLink; begin if LinkedMemo = nil then Exit; var saveLink := LinkedMemo; try LinkedMemo := nil; saveLink.CaretPos := CaretPos; saveLink.Perform(EM_SCROLLCARET, 0, 0); var myLine := Perform(EM_GETFIRSTVISIBLELINE, 0, 0); var linkLine := saveLink.Perform(EM_GETFIRSTVISIBLELINE, 0, 0); if myLine = linkLine then Exit; saveLink.Perform(EM_LINESCROLL, 0, myLine - linkLine); finally LinkedMemo := saveLink; end; end; procedure TLinkMemo.WMHScroll(var Message: TMessage); begin inherited; SyncLink; end; procedure TLinkMemo.WMVScroll(var Message: TMessage); begin inherited; SyncLink; end;

I'm not familiar with the DevExpress approach, but I assume the DX controls can request an image of arbitrary size/DPI from an DX image list (probably acting like a VCL TImageCollection). Standard controls based on Windows require an HIMAGELIST at the end, which contains images all of the same size. Compatibility is the limiting factor here.

Usually you connect the actions of such a TActionList to some visual control of a form (TMainMenu, TPopupMenu, TToolBar, TTreeView, TListView ...). Most of these controls have their own property to connect a TVirtualImageList, which should reside on the form itself. The latter is mandatory to make DPI awareness work properly. It may sound wrong to have separate virtual image lists in each form, which often contain the same content - sometimes the same as the one connected to the ActionList. If you imagine that each each image list can only hold one size of images and each form can have run on a different DPI it becomes clear that this is unavoidable. While it can be tedious to have all these TVirtualImagelist instances at design time, there are ways to simplify it. If you are interested I suggest reading my blog posts about ImageLists and High DPI

I can provide an alternative solution: type TLinkMemo = class(TMemo) private FLinkedMemo: TLinkMemo; procedure CNCommand(var Message: TWMCommand); message CN_COMMAND; procedure WMVScroll(var Message: TMessage); message WM_VSCROLL; procedure SyncLink; public property LinkedMemo: TLinkMemo read FLinkedMemo write FLinkedMemo; end; procedure TLinkMemo.CNCommand(var Message: TWMCommand); begin inherited; if Message.NotifyCode = EN_VSCROLL then SyncLink; end; procedure TLinkMemo.SyncLink; begin if LinkedMemo = nil then Exit; var myFirstLine := Perform(EM_GETFIRSTVISIBLELINE, 0, 0); var linkFirstLine := LinkedMemo.Perform(EM_GETFIRSTVISIBLELINE, 0, 0); if myFirstLine = linkFirstLine then Exit; LinkedMemo.Perform(EM_LINESCROLL, 0, myFirstLine - linkFirstLine); end; procedure TLinkMemo.WMVScroll(var Message: TMessage); begin inherited; SyncLink; end;

type TSendParameter = class private Fpayment_method: TArray<string>; Ftransaction_type: string; Ffull_name: string; Femail: string; public property email: string read Femail write Femail; property full_name: string read Ffull_name write Ffull_name; property payment_method: TArray<string> read Fpayment_method write Fpayment_method; property transaction_type: string read Ftransaction_type write Ftransaction_type; end; ... var par := TSendParameter.Create; try par.payment_method := TArray<string>.Create('credit-card', 'open-banking'); par.transaction_type := 'SALE'; par.full_name := 'Joe Blogs'; par.email := 'etc etc'; RestReq.AddBody<TSendParameter>(par); finally par.Free; end;

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.