Leaderboard

@PeterPanettone - If you add _XRio to the last three, you won't get any issues with Rio when 10.5 arrives.

Found a solution for me here

Not so. For sure the language doesn't stop you using any message you like. But that doesn't mean that it is reasonable to do so. Oftentimes messages are used in the private implementation detail for a class. As a broad principle, you should not be looking to work with Windows messages when consuming VCL controls. Sometimes one is forced into it because the control provides no official mechanism. But when we do that, it is brittle, and subject to future implementation detail changes. And there it is. There's the point where you take a dependency on on implementation details. The implementation of RecreateWnd is: procedure TWinControl.RecreateWnd; begin if WindowHandle <> 0 then Perform(CM_RECREATEWND, 0, 0); end; There is a difference between this code and yours. Your code does something unconditionally. But RecreateWnd does nothing if the window handle has not already been created. I'm quite sure that you've got this wrong. I mean, it won't have any material impact on things, but one may as well do things the right way.

We are fine thanks! Getting used to the "new normal" and looking ahead hoping things will globally improve soon. I've merged your PR a couple of minutes ago, thanks! 🙂 Andrea

Hi @Stuart Clennett, my fault! I forgot to update some prototypes here and there. Thanks for pointing this out: add these to the uses clause: , MARS.Core.URL, MARS.Core.RequestAndResponse.Interfaces change the BeforeHandleRequest assignment to : FEngine.BeforeHandleRequest := function (const AEngine: TMARSEngine; const AURL: TMARSURL; const ARequest: IMARSRequest; const AResponse: IMARSResponse; var Handled: Boolean ): Boolean begin Thanks! I'll fixit in the repo ASAP Andrea

Thanks to everyone who responded to this! I'm new to git (and to contributing to open source projects) so I installed a bunch of stuff, cloned the SynEdit2 repository, made a branch (I think that's the correct thing), went to add the wordwrap fix I mentioned above... and found that pyscripter had already fixed it last December and I had totally missed it. Nice! I'm going to attempt a pull request on a very minor fix I have to try to get my feet wet on the process.

Why not just make that property be a simple String value? Easy to read, no popup dialog needed, and you can disable DFM streaming for that property if needed. But, if you really want a popup dialog, then you need to separate your code into run-time and design-time packages. The run-time package implements only the main component by itself, and it should have no concept of the popup dialog at all. The design-time package uses the run-time package, and implements the actual popup dialog, as well as a component editor to display that popup dialog when the user double-clicks or right-clicks on your main component. Indy implements both approaches, and Indy is pre-installed in the IDE w/ source code, so you can look at how Indy handles these steps: - In the IdBaseComponent.pas unit of the IndySystem run-time package, the TIdBaseComponent class, which is a base class that all Indy components derive from, has a public Version property that returns a static String from IdVers.inc specifying the compiled version number (the Version property could have been made published in the Object Inspector with a little extra work). - In the IdCoreDsnRegister.pas unit of the IndyCore design-time package, there is a TIdBaseComponentEditor class that is registered with the IDE at design-time using the RTL's RegisterComponentEditor() function, to display a popup dialog when double/right-clicking on any Indy component in the Form Designer. - Also in IdCoreDsnRegister.pas is a 3rd way that Indy displays its version number - in the IDE's own About dialog! When the IndyCore design-time package is loaded in the IDE, it registers some custom Strings with the IDE's About box using the IDE's OpenTools API, specifically the IOTAAboutBoxServices.AddPluginInfo() interface method.

Just FYI, you should call the form's RecreateWnd() method instead of issuing the CM_RECREATEWND message manually.

The stack trace you showed is complaining that the character data for the UnicodeString returned by TJSONString.Value is what is being leaked. That UnicodeString is assigned to your private FToken variable. Which means the TBetFairApi object that is holding that UnicodeString is not freeing that UnicodeString properly. Either because itself is being leaked as well, or you have a bug elsewhere in your code that is overwriting the UnicodeString's internal pointer to the allocated character data. Either way, this is happening after TBetFairApi.GetToken() has exited, so the problem is not in TBetFairApi.GetToken() itself. The leak report is merely showing you the call stack leading up to the memory allocation that leaked, not the call stack leading up to the leak itself. That was a typo in my example. I meant to free only the TJSONValue that ParseJSONValue() returns, not the TJSONValue of the 'token' field. I have corrected that mistake in my earlier example.

Dude, just make a minimal example and debug that. Post it here if you want. Really good discipline to learn how to make that minimal example.

Cut this code down to the minimum that leaks. Then debug that.

10.4 has an update to Bookmarks and Navigator. It creates C:\Program Files (x86)\Common Files\ParnassusShared and places ParnassusBookmarks_XSydney.dll ParnassusCoreEditor_XSydney.dll ParnassusNavigator_XSydney.dll So, to cure the 10.3 ailments, copy from C:\Users\<username>\Documents\Embarcadero\Studio\20.0\CatalogRepository\ to the first mentioned common catalog Bookmarks-1.0\ParnassusBookmarks.dll to ParnassusBookmarks_XRio.dll ParnassusCoreEditor-1.0\ParnassusCoreEditor.dll to ParnassusCoreEditor_XRio.dll Navigator-1.0\ParnassusNavigator.dll to ParnassusNavigator_XRio.dll

It's called consistency and is considered to be a good thing...most of the time.