Lars Fosdal

@dmitrybv I assume that in your real code, you retrieve the correct installation paths from registry?

Edit: Also, see this for executing shell commands:

@RDP1974 Dave is correct. Please remove your comment.

It is possible to add a comment to the issue, but not sure if that would be more hurtful than helpful.

You can also define symbols in an environment variable, but then they apply to ALL projects you compile.
dcc_define=Test;MagicSymbol;SomeOtherDefine
dcc_define being the magic environment variable name which defines the symbols.

Example:

This one defines "foslar" - so that I can include code that I am working on but which doesn't compile in the project and commit/push to git without breaking the build server or messing up for other users.
 

{$ifdef foslar}
procedure DoSomething
begi
  What was I thinking?
{$endif}

Version Control.  

TEventually<T> 😛

But you are still blocking, if looping around a wait.
Are you going to put a ProcessMessages in that loop?

Wait = Block. 
Events = Asynch w/o block.

I have a 5K 40" Lenovo, that can be split into two "virtual" displays.  I can set up different resolutions and scalings on those when I need to test HighDPI. 
Generally speaking, the test results are so disheartening that I still stick with 100% scaling in the OS, and use BDS in DPI-Unaware mode.

Generally speaking I prefer offloading background tasks to a threadpool in-queue. The threadpool messages the main thread when the work is done. The main thread then retrieves the response from the threadpool out-queue.(i.e. mailbox principle).

If there are multiple parallell tasks (i.e. a job), the main thread will need to know that, and whenever a thread completes, check if it fullfill the needs of the job and then fire off whatever should happen after the job is complete.

There really is no single best way to deal with background processing - except ensuring that the main thread is not blocked.

I see there are several attributes relevant for the Swagger data, such as RequestParamAttribute, but I see very few examples of use.
Github: search for "Param]" (without the quotes)

I woud suggest you experiment with those to see what you get.

Ah, so how to generate complete Swagger info from your MARS API?

Not sure if I understand your question?
Swagger is API documentation. Are you looking for how to generate code for MARS REST based on a Swagger definition?

@audi30tdi We do all our EHF invoices through third party systems, so I have no Delphi code to offer.

Are you looking for the specification of the EHF invoice document or code for sending the document to an http endpoint?
 

Isn't that the type of error you get when you try to link a .dcu that is for the wrong platform?

Apple's RAM and disk prices are ridiculous, but personally I'd go for at least 24GB and 1TB. 
My MBP M1 has 32GB/2TB.

Looks fixed now.

IMO, if you need multiple values for a field, you should use a list element.

Duplicate key/value pairs in JSON just doesn't make sense.
https://JsonLint.com does not like them either.

Sorry, no updates.  Not using Delphi much, except from small utils. Haven't checked on the problem since 12.3.

AFAIK, no. 

You could run it through an RSS reader. Perhaps there is one that can ignore topics the way you desire?

@ŁukaszDe You find a topic uninteresting, but it keeps reappearing?
Have you tried the "Ignore this topic" for a thread you don't want to read again?

24 minutes ago, Uwe Raabe said:

Try with external MSBuild in the project options and select x64 as preferred architecture. Key is to use the 64-bit compiler versions from the bin64 folder. The target platform is almost irrelevant. Only bcc64x got an update with the April patch.

Yeah, THAT surfaced the dreaded error

[dcc64 Error] NonNullableConstraint.dpr(41): Type parameter 'T' must be a non-nullable value type

Half-baked patches are no fun. 

Edit - Also noticed that the Error ID is lost when using MSBuild.

@Anders Melander

I just tried my example code which failed before the April patch in the 64-bit IDE, targeting 64-bit Windows.
It no longer stops compiling.

program NonNullableConstraint;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

type
  TMyClass = class
    function Select<T:Record>(const selector: string):TArray<T>;
  end;

  TNotifcationRow = record
  const
    Query = 'SELECT * FROM v_server_notifications';
  public
    Id: Integer;
    Name: String;
    Data: String;
    ByWho: String;
    CreatedWhen: TDateTime;
    function DataAsId: Integer;
  end;
  TServerNotificationArray = TArray<TNotifcationRow>;

{ TMyClass }

function TMyClass.Select<T>(const selector: string): TArray<T>;
begin

end;

procedure Test;
var
  MyClass: TMyClass;
  Res: TServerNotificationArray;
begin
  MyClass := TMyClass.Create;
  Res := MyClass.Select<TNotifcationRow>('foo'); // <- E2512 Type parameter 'T' must be a non-nullable value type
end;

{ TNotifcationRow }

function TNotifcationRow.DataAsId: Integer;
begin
  Result := 0;
end;

begin
  try
    Test;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

It is fixed. It is no longer necessary to remove the record constraint to avoid the non-nullable type error.

Edit: Woops - missed that 64-bit thing... do you mean the 64-bit target, or the 64-bit compiler?

You can reserve a video against embedding, so that might be a factor?