Uwe Raabe

When you create a new topic you see the Content tab, but there is a second tab named Poll. That should give you all the tools you need.

Well, the problem is not that it cannot find unit Vcl.ExtCtrls.dcu, but that it states it cannot compile that unit (which is expected and as stated above ist is something we definitely don't want). My guess is that your project or some 3rd party library contains a unit that is used by Vcl.ExtCtrls, but it doesn't match the one that comes with Delphi. You might want to scan the dcu output folder of your project and find dcu files that are also present in C:\Program Files (x86)\Embarcadero\Studio\22.0\lib\win32\debug or C:\Program Files (x86)\Embarcadero\Studio\22.0\lib\win32\release. When you found one or more, you have to search where they came from.

No problem: New macOS ARM 64-bit Target Platform

If you look a bit closer you can see that this entry contains a "Directory of " at the beginning.

Well I said Win32\Debug because that is the output folder you specified in your project. It is relative to your project directory. Your answer implies that you deleted all dcu files from the Delphi library folder. So yes, that was extraordinary foolish. I also have no better plan than to re-install Delphi then. BTW, your library path contains a weird entry at the end: I have no idea how that made it into that list. Please note one rule: You should never be forced to compile the Delphi standard units. You may deliberately do so for one or another, but you should definitely know why.

Have you deleted all dcu files in Win32\debug after removing those paths?

Several parts of the included Delphi units make use of ZLib, but that is not the root of your problem. The real question is: why does the compiler want to compile Delphi units in the first place. This can happen when the Delphi source folders are part of the search path. So I suggest you inspect the Delphi library paths for any references to $(BDS)\Source and remove those.

The plugins are integrated in the IDE and thus inherited the DPI support of the IDE. Although there are ways to make mixed DPI happen, that still needs developer capacity to implement.

It seems that these plugins don't have a high enough priority to get the necessary resources attached. It is expected that there will be High DPI issues. As there are still plenty of similar issues in the IDE, I can understand which ones they target first.

Of course, that could be done. IMHO it is just a bit less elegant.

Come on! It is not that bad when we use a class helper: type TCookieManagerHelper = class helper for TCookieManager private function GetCookiesAsString: string; procedure SetCookiesAsString(const Value: string); public property CookiesAsString: string read GetCookiesAsString write SetCookiesAsString; end; function TCookieManagerHelper.GetCookiesAsString: string; var lst: TStringList; begin lst := TStringList.Create(); try for var cookie in Cookies do lst.Add(cookie.GetServerCookie); Result := lst.CommaText; finally lst.Free; end; end; procedure TCookieManagerHelper.SetCookiesAsString(const Value: string); var lst: TStringList; begin lst := TStringList.Create(); try lst.CommaText := Value; for var S in lst do begin var uri := Default(TURI); var cookie := TCookie.Create(S, uri); uri.ComposeURI('', '', '', cookie.Domain.Substring(1), 0, cookie.Path, nil, ''); AddServerCookie(cookie, uri); end; finally lst.Free; end; end;

If we are talking about the same thing AFAIK it is called project page and it is accessible in the project menu.

Then you should limit the WHERE clause to that condition. Currently the WHERE clause updates all records in DELIVERY_DETAIL where there exists a record in ORDERDETAIL with the same LINENO - probably that are all records.

Well, I cannot see what db is in the exe path and what tables it contains. The $(RUN) variable is simply expanded to the path of the exe file. So the cause of your problem is most likely the db found in that folder. Note that the $(RUN) expansion will only give correct results at runtime and not while in the designer.

That is because you give a ConnectionDefName: The given value is the name of an entry in the definition file with the required values for that connection. My first question was targeting exactly that, simply because you gave most of the entries in your code as well - so why the def name. If you remove this assignment in your code as well as in the object inspector of the connection, this message should disappear.

You showed a screenshot of the Object Inspector for the TFDConnection. There can be seen the Params.Database value with c:\temp\drivers.db. Change that to $(RUN)\Drivers.db and your program will look for Drivers.db in the folder where the exe is. (I don't know how to explain it better.)

Set Params.Database to $(RUN)\Drivers.db

What are the settings in the connection definition with name Drivers?

Wouldn't adding a derived logger with that implementation be a more straight forward approach? Otherwise any registered logger derived from TDUnitXNullLogger would trigger that print out.

You can even link the database into the exe as a resource and write it to disk if it doesn't exist.

How much of paid work can you put aside to write it yourself?

There is a German blog post describing the whole process: Offline Installation und Aktivierung von Delphi, C++Builder und RAD Studio Perhaps you will get the points with a translation to English.

Option sets are fine when the same settings are to be applied to different projects. For a standalone project anything possible with option sets is also possible with build configurations.

Why? The other updates from previous versions (like 10.4.2, 10.3.3 or 10.2.3) are not selectable either. The list contains major versions only.

Are you able to achieve the desired results with separate build configurations? I'm sorry, but I still don't understand what your actual problem is.