Uwe Raabe

Found it - well, at least a workaround. Will investigate for the root cause later. The new version is available for download.

Yes, I noticed that here, too. I am still investigating what change may have caused that.

Search for ParnassusCoreEditor in this forum and you will get some helpful answers.

Thanks to the overloads for AddBody that is not a big challenge: { as Json string } Request.AddBody(TJSON.ObjectToJsonString(aMsg, [joIgnoreEmptyStrings, joIgnoreEmptyArrays, joDateIsUTC, joDateFormatISO8601])); { or as TJsonObject } Request.AddBody(TJSON.ObjectToJsonObject(aMsg, [joIgnoreEmptyStrings, joIgnoreEmptyArrays, joDateIsUTC, joDateFormatISO8601]), ooREST);

Nice! Any reason why you didn't make use of TRestClient instead of the Indy component? That would not only avoid the dependence on the OpenSSL libraries, but make it also work on other target platforms. unit O365WebHook; // Lars Fosdal, 2020 OCT 16 // Simple example without error handling interface uses System.Classes, System.SysUtils, REST.Json, REST.Client, REST.Types; type TWebHookMessage = class end; /// <summary> See https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/connectors-using /// for examples of how to structure the json for creating advanced formats</summary> TSimpleText = class(TWebHookMessage) private FText: String; public property Text: String read FText write FText; constructor Create(const aText: string); end; type TWebHook = class private FClient: TRESTClient; FRequest: TCustomRESTRequest; FURL: string; protected property Client: TRESTClient read FClient; property Request: TCustomRESTRequest read FRequest; public constructor Create(const aURL: string = ''); destructor Destroy; override; function PostMessage(const aMsg: TWebhookMessage; aOwnsMsg: Boolean = False): Boolean; property URL: string read FURL write FURL; end; implementation { TWebHook } constructor TWebHook.Create(const aURL: string); begin inherited Create; FURL := aURL; FClient := TRESTClient.Create(nil); FRequest := TCustomRESTRequest.Create(nil); FRequest.Client := FClient; end; destructor TWebHook.Destroy; begin FRequest.Free; FClient.Free; inherited; end; function TWebHook.PostMessage(const aMsg: TWebhookMessage; aOwnsMsg: Boolean = False): Boolean; begin try Request.Client.BaseURL := URL; Request.Method := rmPOST; Request.AddBody(aMsg); Request.Execute; Result := Request.Response.Status.Success; finally if aOwnsMsg then aMsg.Free; end; end; { TSimpleText } constructor TSimpleText.Create(const aText: string); begin inherited Create; FText := aText; end; end.

Thanks! There are several issues regarding visibility and they are still being investigated. All reproducible steps are valuable.

Not really. People volunteered for it. Some do smaller tasks like testing, but most of the work has been done by the core team. I see it as part of the things MVPs do.

Perhaps, but one should not forget that Embarcadero actually did offer a full version for free to Andy several times. Even if that version may be time limited for one year, that is just the same with the CE version anyway. So he may have his reasons to decline these offers, which we simply do no know.

Well, this suggests there will never be a CE for the current version, only for previous versions. This implies that there will be no Fix-Pack for any current version either.

The configuration may lead to a big ball of mud quickly. Just your suggestion assumes that anyone uses lower case prefixes in the first place. I have seen some significant number of coding style guides that prefer the capital letter A. While I can see the benefit for your personal case, I expect difficulties to make it suitable for the general audience.

You can make use of pre-compiled DCUs for these libraries.

Formatter.EXE, the Command Line Formatter

According to the call stack the error is happening way outside of the MMX code, even if we would call VirtualTrees actually a part of MMX. Do you see these crashes even in a vanilla 10.4.1 installation with only MMX as plugin? Can you retry with the latest version 15.0.28? (Note that the map files are already included in the setup) Does anyone else see these crashes?

The Delphi integrated formatter offers that as well.

The current VirtualTree already supports VCL styling. I am talking about IDE styling for IDE plugins, which is somewhat different to the normal VCL styling. On the other hand I just noticed that the latest version still doesn't support per control styling. That would make a good kludge I could contribute.

I already thought of that, but most of the changes are needed to make the control compatible with the IDE styling. That is probably of less interest to the public. Nevertheless, I will see how this might be integrated with minimal footprint.

There is a new version available where VirtualTrees is upgraded to a more recent version. There were a lot of things to adjust as MMX made some changes to VirtualTrees which had to be reworked a bit.

Wait a minute. The map file I attached before belongs to the previous version. Can you try again with the correct map file attached here, please? I will see if I can include the map files in the setup. MMX_BDS21.map

That callstack doesn't make any sense at all. Both mentions of MMX are from VirtualTrees. The corresponding line 10883 says Canvas.FillRect(Rect(0, 0, Width, Height)); Even as weird for the other one. Line 5706 says Result := Tree.GetDisplayRect(Node, Column, True, False); Nothing looks like it may end up in a call stack as shown. I can update to a newer VirtualTrees version and see if that helps. BTW, the blank window issue is a 10.4.1 thing.

Thanks! Will be fixed in the next version.

As long as you choose the same setup mode (for me only / for all users) as before there should be no problem. The setup will detect the previous installation and replace the files without manipulating your settings. If that isn't the case with your installation, please contact me so we can find the cause.

Sorry, I just realized that we are on FMX here.

A fixed version V15.0.27 is available.

I have uploaded a new version, which is identical to that I am working with in the moment. In addition I have attached a map file for the 10.4 instance of this MMX version. Place the map file next to the MMX_BDS21.dll. This will give some more verbose call stack for the MMX part. The problem about empty floating windows is reported from others, too. Currently I have no idea what could be the cause, so we have to investigate further. Fortunately I can somehow force this problem to appear, when I create a layout where the MMX windows are undocked. Starting a debug session with closing those windows and opening them again after debugging actually shows these empty windows. At least that is a point where I can start. Just checked, it works perfectly with 10.3.3 MMX_BDS21.map

Do you get call stacks with the crashes? If so, I would provide a map file to get more information from it.