Uwe Raabe

OK, I didn't realize that DoIt doesn't exist. MMX basically works on the current unit and the selected entity - property, method, class, module etc.

Adding a layer of action to achieve a goal is probably not well accepted by long time MMX users as it would break their work flow. Even if such functionality would exist, which class should the method be added when DoIt is not declared in TMyObject, but in TMyBaseObject, which TMyObject is derived from? Instead of asking for the target object each time, it is much simpler to Ctrl-Click on the TMyObject reference or even the DoIt reference in the code, which immediately selects the requested object on which the Add Method action then can be executed on.

Wrong Expectation! The method is (obviously) added to the currently selected object TForm1. Works as expected.

I have got my first shot on Sunday. Monday morning I felt like 20 again, where I also had massive problems to get out of bed (albeit for other reasons). Took a nap after dinner (can't remember doing such thing before). Fortunately that fatigue went away in the evening. So I highly recommend a vaccination, too.

Unfortunately the conditions when taking over MMX explicitly forbid making the code or parts of it Open Source.

Cannot test it from here, so something is probably still missing, but it might look like this one: uses System.SysUtils, REST.Client, REST.Authenticator.OAuth, REST.Types; procedure Main; var auth: TOAuth2Authenticator; client: TRESTClient; request: TRESTRequest; response: TCustomRESTResponse; begin client := TRESTClient.Create(nil); try client.BaseURL := 'https://notify-api.line.me'; auth := TOAuth2Authenticator.Create(nil); try auth.TokenType := TOAuth2TokenType.ttBearer; auth.AccessToken := 'U4314taadsffhjjjjykllFVissffdfssdfsdfsgfgz'; client.Authenticator := auth; request := TRESTRequest.Create(nil); try request.Client := client; request.Method := rmPOST; request.Resource := 'api/notify'; request.AddParameter('message', 'abcTest', pkREQUESTBODY); request.AddParameter('stickerPackageId', '1', pkREQUESTBODY); request.AddParameter('stickerId', '113', pkREQUESTBODY); request.AddParameter('imageFile', 'D:\mypic.jpg', pkFILE); request.Execute; response := request.Response; if response.Status.Success then begin Writeln('Success: ' + response.Content); end else begin Writeln('Failed with ' + response.StatusText + ': ' + response.Content); end; finally request.Free; end; finally auth.Free; end; finally client.Free; end; end;

Note that the shown price is for a one year subscription. Nevertheless totally worth it.

Depends on which country the server is locating you. AFAIK, for Germany the reseller is Emenda. @KodeZwerg, do you have anything like a proxy, VPN or something active when you browse that site?

This is a part of the Called By graph for the TCodeItem.Clear method in MMX Code Explorer as created by Understand. The dots allow to dynamically expand/collapse the next level. This goes up even to wired event handlers, f.i. to quickly find the form and control triggering the call.

Place the cursor somewhere inside the method and press CTRL-W repeatedly until the whole procedure is selected. Standard IDE functionality.

It is the same as Comment Entitiy. It places a line comment // before the entity at the cursor and all related entities (like getter, setter, field for a property). It comments interface and implementation part of that entity. It doesn't matter whether the cursor is placed in the interface or implementation of that entity. Note that there is no simple action to reverse that.

Of course it would. It is just that all others are completely incompetent. 🤦‍♂️

I guess, the tricky part is to make the IDE support High-DPI while the form designer stays on PixelsPerInch = 96 (Irony: This would be pretty easy with the undocked designer). Imagine the controls shifting around when one DFM is designed on several systems with different DPI. One cannot expect all developers in a team working in exactly the same environment. Merging changes in DFMs would be near to impossible.

Any subkeys of the key need to be deleted first. TRegistry.DeleteKey already takes care of that, but it needs KEY_ENUMERATE_SUB_KEYS access for that, which is not included in KEY_WRITE. Try KEY_ALL_ACCESS.

These are not UI bugs in the first place. The form design looks quite OK during design time (the "String" label is changed dynamically) and run time on my system. You can see that there is still some difference in the gap between External File and the combo box. I guess, your display problems are due to some buggy scaling of the Delphi IDE, which is to be expected as long as the IDE doesn't support High DPI properly. There is not much I can do about that.

This kind of display errors are often seen when the IDE is used in a High-DPI environment with GDI scaling. Windows sometimes select font sizes slightly larger as the scaling suggests. It is pretty hard to detect this inside the application, The only workaround I am aware of is to give some extra space between controls to cover these cases.

It would be interesting to inspect the different settings in your DEBUG and RELEASE configurations to find the real cause.

That works only when MMX Code Explorer is installed

AFAIK, that Demo-Kit is meant to support presenters and bloggers to create content around Delphi 10.4.2. I don't know if that stuff is planned to go into the normal demos.

This blog mentions a way: Execute Scripts and View Source with TEdgeBrowser

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.