Uwe Raabe

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.

I don't know, but having packages besides pas and/or dcu files can be necessary (or just convenient) when compiling with packages. Especially when libraries are not provided with all source files (not sure about this one), you need the bpl/dcp files. You can find more information about that in this blog post: Appercept’s New AWS SDK For Delphi, Available With RAD Studio And Delphi Enterprise and Architect

This is expected and even documented (see Windows7 item 1):

No. Probably you even cannot if these packages are compiled as runtime-only. In fact you will rarely have a need to compile your application with any designtime package unless the author missed to separate the designtime part from the runtime part. Note, that you have to deploy all directly and indirectly used runtime packages with your application if you compile it with runtime packages. To better answer your question: The DCP file for a BPL package is what you reference in the requires section of a package project file. It allows the using package to see all the units inside the package and f.i. link to the contained routines. The DCP itself also contains the name of the BPL file - usually with the LIBSUFFIX. The difference of a unit contained in a DCP file and a DCU file is that the DCU is linked into the compiled package or application, while the DCP provides the entry points to the BPL.