Uwe Raabe

Here we go: SetVersionInfo.zip Simply call TSetVersionInfo.SetVersionInfo(<Dproj-FileName>, <VersionString>). The current implementation sets the version info in the base configuration only and removes any version info entries in child configurations (just like Project Magician does). If you need to set different version info for each build configuration or platform I might get that implemented, too. I just need to know the rules. The unit uSetVersionInfo.XML is more or less a copy of NativeXML, renamed to allow multiple instances in different design packages.

May be, and that would probably be best. My knowledge is just that FinalBuilder doesn't change the dproj files, but rather creates proper rc files to achieve that. There might also be found some code in DevExtensions regarding this subject.

If you are interested I can provide the relevant code from Project Magician. Not sure how it fits into the existing DPM code, though. I use ProjectMagicianCmd successfully for exactly that purpose with build servers where FinalBuilder is not available.

Bli frisk snart.

Unfortunately, you cannot. The wrapping algorithm is based on a tokenizer with some checks for line comments and special delimiters (like comma, semicolon and opening brackets) which are kept with the following token. Currently there is nothing implemented to detect complete declarations. You can file a feature request here: support@mmx-delphi.de (best accompanied by a set of examples to help me create some unit tests).

Can you reproduce in a simple app? If yes, can you attach it here?

Did you compare the generated op code?

It is indeed MMX Code Explorer which catches the Ctrl-Shift-Up/Down shortcuts and handles them properly. As MMX is one of the first additions installed here, I didn't notice the standard behavior change.

I followed your steps and the cursor is on line 27, while the editor top line is 25. Embarcadero® Delphi 10.4 Version 27.0.40680.4203 (with MMX Code Explorer , Project Magician, Selective Debugging and wuppdi Welcome Page)

I cannot confirm that. With Ctrl-Shift-Arrow Down the cursor is located in the first line after begin. I cannot confirm that either. The top line in the editor is the method declaration. That one I can indeed conform. Please file a bug report for that.

Sorry, I didn't have had time to check this. Will take a look on that for the next version.

Declare a class like this and create an instance with TJson.JsonToObject from REST.Json.pas: type TMyJson = class FResult: Integer; FIdList: TArray<Integer>; end; const cJson = '{"RESULT":200, "IDLIST":[1,2,3,4,5]}'; var myJson: TMyJson; begin myJson := TJson.JsonToObject<TMyJson>(cJson); try for var I := 0 to Length(myJson.FIdList) - 1 do { do something with myJson.FIdList[I] } finally myJson.Free; end; end;

I suggest filing a bug report emphasizing that a simple reload fails to refresh the LSP.

After reloading the file have you tried making a simple change in the editor? That should trigger a refresh as any other code change does. Perhaps it is simply the reload that misses the triggering.

As I said, a customer now has to tweak the requires clause of his package using Indy for each new Delphi version anyway. If you start the new scheme for the 10.5 packages and keep the old as is, you don't have any compatibility issue at all. At least this will ease the use of Indy in all versions 10.5 up. A backport to packages for older Delphi versions can then be done separately if feasible. The interesting thing is that the Indy version delivered with Delphi already follows the LIBSUFFIX approach. package IndyIPClient; ... requires rtl, IndyCore, IndyProtocols, IndySystem, CustomIPTransport, IndyIPCommon; That said, using the non-included Indy packages already lays a burden on the user, because the requires clauses won't match when switching to a non-included Indy version. Even more: the necessary package changes are already available and ready for use.

No! If you start the setup you are asked to remove the registry settings and the default is no. Unless you change that all settings are kept.

That may be true for the Delphi 4 and 5 packages, but can easily be dropped for all others. The naming of the bpl files would still be the same. Honestly? With the current scheme you have this breakage for each new Delphi version.

Looks like there is a different RaizeComponentsVcl270.bpl found somewhere.

Worked perfectly just a minute ago. Can you try to remove that library and try again? Perhaps you have to clear the corresponding folder in $(CatalogRepository) in between.

http://docwiki.embarcadero.com/RADStudio/Sydney/en/10.4_Sydney_-_Release_1#Projects

Worked flawlessly over here. AFAIK GetIt packages are not re-installed, but I don't use those anyway. I always install packages directly and these are all present after the update.

If it is the only change in the project files, it would at least work for packages 10.4 and up - at least until any new setting throws a spanner into the gear.

Under Tools - Options - IDE - Saving and Desktop there is a setting Save project desktop when closing.

It was introduced in 10.4 Sydney - Release 1

Meanwhile a bit dusty, but most of it is still valid and overlaps your suggestions nicely: Delphi Library Guidelines