Uwe Raabe

As a workaround you can disable the toolbar in Pascal Expert Options. You might configure some shortcuts instead.

I was able to create a similar call stack with my CodeCoverage plugin calling INTAServices.NewToolbar. This is most likely an internal bug inside the IDE. Probably all plugins adding their own toolbar to the IDE should be affected (f.i. TMS FixInsight).

This blog post mentions support for 10.4: https://www.peganza.com/support-for-delphi-10.4.html

AFAIK, it doesn't come with source.

So you should be able to make a reproducible test case - in case there is none already.

Works fine her, too.

Yes, that is supported in 10.4.2

The IDE theming support in 10.2.3 is much more buggy and quirky than in the newer versions. I'm sorry, but I am not going to fix that as long as the workaround is to simply re-open that dialog.

No, it will remove 10.4.1 before installing itself.

Which Delphi version?

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.