PeterBelow

See Tools -> Options -> User interface -> Form designer -> High DPI, the designer itself is now DPI aware and you may have to change the default setting if you design on a high DPI monitor.

Tools -> Options -> User interface -> Form designer -> High DPI

In Delphi 11 the designer itself can be configured to be DPI-aware. Which version are you using?

Unlikely, it would be reported much more frequently in this case. I have never seen it, for example, but in my case the only 3rd party package used is MMX...

Isn't that what it does now?

I think the core of the problem is an ambiguity inherent in the original language syntax inherited from the days of Turbo Pascal and earlier. 'x' can be interpreted either as a character constant or a string constant, and the compiler decides which it should be dependent on the context. A char is also assignment compatible with a variable or parameter of type string (but not vice versa). I see no way to get around this, and changing these rules will never happen since they make sense and changing them would break heaps of older code. Of course the compiler could use more stringent rules for overload resolution, e.g. require type identity and not only assignment compatibility. That would solve the conflict in the case you noticed but would be quite bothersome in other situations, requiring more overloaded versions of a function to be implemented. Think about what a type identity requirement would mean for overloaded functions taking numeric types as parameter. Do you really want to declare versions for byte, smallint, integer, word, cardinal etc. ?

There would probably be a conflict in overload resolution. Anyway, System.StrUtils contains IndexStr and IndexText functions that would serve your need here.

I have seen something like this occasionally (D 11.1 on Win10). Task Manager shows 100% use of one CPU core for the process. Sometimes it resolves itself after a few seconds but often the only option is to kill the process. On restarting the IDE it usually works normally. I have never been able to reproduce it at will.

The VCL is not thread-safe in itsself, creating top-level objects like forms, frames or datamodules accesses some global stuff in vcl.forms connected to reading components from the dfm file. Try to replace your datamodules with a class (not derived from TCustomForm) that creates and configures all components you now place at design-time in code. I dimly remember a tool that could create such code from a dfm file, never used it myself, though. Are all your threads created in the same host thread? If so that should actually mitigate the problem since the thread constructor runs in the host thread, so all datamodules would be created in the same thread. But that may cause another problem: database connections are usually bound to the thread that creates them. If the datamodule creation already creates the connection, which is then later used in the context of the thread that owns the datamodule that may cause problems since the db access library may try to solve the conflict by serializing all DB access in a separate thread. Multithreading using a database can be even trickier than multithreading itself...

As far as I remember this "feature" comes from the original Wirth Pascal in Delphi's anchestry. Dropping it now would break heaps of legacy code, so is very unlikely to happen.

A COM dll usually uses interfaces as callbacks as well, not function pointers. I know nothing about Docker so cannot give you any advice on this topic. .NET has an interface to unmanaged code, which is used to interact with the OS API, though. Your dll would be unmanaged code, you just have to make sure you do not use any Delphi-specific types (especially compiler-managed ones, like String or dynamic arrays) in the functions the DLL exports.

Create a COM dll, Delphi has a wizard for that. Google for "C# com interop" to find examples for how to use such a thing from the .NET side.

ModelMaker Code Explorer (MMX) can do this, as well as a lot of other things. Could not live without it... See https://www.mmx-delphi.de/ It is free and maintained.

The script is looking at the wrong version of the rtl package. 17.0 is not 10.2 Tokyo, that would be 19.0. Check the pathes used in the script or the dproj files it refers to. 17.0 is 10.0 Seattle if memory serves.

The error message looks like the designer tries to read values from a dfm file into a component that has not been created yet. Was this other project created with the same Delphi version? Does it open and compile in Delphi Alexandria? Does the form you are trying to use in the new project use any self-written or 3rd-party components you are not yet using in forms of the new project?

If you used the button OnClick handler from the link you gave it will not work unless uncomment the Application.ProcessMesssages call.

The source of your problem is probably the line TImage1.Picture.Assign(Image); Should'nt that be Image1.Picture.Assign(Image);

unit Unit1; interface uses system.Generics.Collections, system.Typinfo, system.sysutils; type TDynamicArrayFormatter<T> = class strict private FData: TArray<T>; FDimensions: TArray<cardinal>; FIndices: TArray<cardinal>; FType: PTypeInfo; strict protected procedure AddValue(aBuilder: TStringBuilder); function CalcLinearIndex: Integer; function GetText: string; procedure ProcessDimension(aDimension: Cardinal; aBuilder: TStringBuilder); public constructor Create(const aDimensions: array of cardinal; const aDataArray: TArray<T>); class function Execute(const aDimensions: array of cardinal; const aDataArray: TArray<T>): string; end; implementation constructor TDynamicArrayFormatter<T>.Create(const aDimensions: array of cardinal; const aDataArray: TArray<T>); begin inherited Create; SetLength(FDimensions, Length(aDimensions)); Move(aDimensions[0], FDimensions[0], Length(FDimensions) * Sizeof(Cardinal)); FData := aDataArray; FType:= TypeInfo(T); SetLength(FIndices, Length(FDimensions)); end; procedure TDynamicArrayFormatter<T>.AddValue(aBuilder: TStringBuilder); var LValue: T; N: Integer; S: string; begin N:= CalcLinearIndex; LValue := FData[N]; case FType.Kind of tkInteger: S:= Pinteger(@LValue)^.ToString; tkUnicodeString: S:= PPChar(@LValue)^; else S:= 'unknown type of T'; end; aBuilder.Append(S); end; function TDynamicArrayFormatter<T>.CalcLinearIndex: Integer; var I, N: Integer; begin Result := 0; N:= 1; for I := High(FDimensions) downto Low(FDimensions) do begin Inc(Result, N * Pred(FIndices[I])); N := N * FDimensions[I]; end; end; class function TDynamicArrayFormatter<T>.Execute(const aDimensions: array of cardinal; const aDataArray: TArray<T>): string; var LInstance: TDynamicArrayFormatter<T>; begin LInstance := TDynamicArrayFormatter<T>.create(aDimensions, aDataArray); try Result := LInstance.GetText; finally LInstance.Free; end; end; function TDynamicArrayFormatter<T>.GetText: string; var LBuilder: TStringBuilder; begin LBuilder := TStringBuilder.Create; try ProcessDimension(1, LBuilder); Result := LBuilder.ToString; finally LBuilder.Free; end; end; procedure TDynamicArrayFormatter<T>.ProcessDimension(aDimension: Cardinal; aBuilder: TStringBuilder); var I: Cardinal; LAddValues: Boolean; begin aBuilder.Append('{'); LAddValues := integer(aDimension) = Length(FDimensions); for I := 1 to FDimensions[Pred(aDimension)] do begin FIndices[aDimension-1] := I; if LAddValues then begin if I > 1 then aBuilder.Append(','); AddValue(aBuilder); end else ProcessDimension(Succ(aDimension), aBuilder); end; aBuilder.Append('}'); end; end. Usage like var S: string; begin S:= TDynamicArrayFormatter<string>.execute([1,2,2], ['one','two','three','four']); WriteLn(S); end;

In addition to Anders' reply: note that (VCL) buttons have two useful properties for dialog boxes: Default - if you set that to true the button will "click" if the user hits the Enter or Return key, regardless of whether the button has focus or not. Cancel - if that is set to true the ESC key will click the button. If the button's ModalResult is set to mrCancel that will close the dialog.

My test code was a bit different and what I cited was what error insight displayed in the Structure pane; I did not try to compile it.

buf is declared as a single Widechar but you tell ToUnicodeEx that it can hold 255 Widechars. A good way to ruin your call stack.

The error message makes no sense since it gives the impression that the code would work if T is constraint to class or interface. That is of course not the case.

Like Remy said this would be much easier to handle if you transmit the whole input string after the user has entered it. There are ways to figure out which character would be created from a virtual key code and the current state of the modifier keys (Shift, Alt, Ctrl), see the MapVirtualKeyEx Windows API function, but this pointless if you have to deal with accented characters or other composites that are created by a sequence of keystrokes, or Alt+numpad input. Let Windows do this work for you and use the OnKeyPress event; it gives you the character directly.

A TDBGrid is a kind of virtual grid. It shows rows from a dataset and does not know how many rows the dataset contains (the dataset itself may not know that, in fact). So it scrolls the active row in the dataset, not the rows in the grid; the selected row in the grid corresponds to the active record in the dataset. The grid actually contains only enough rows to fill the visible area, which get reused for new content as the dataset is scrolled.

I tried something like that and the compiler does not accept the "set of T" declaration, moaning about T not having a class or interface constraint. Which makes no sense at all in this case.