Leaderboard

No chance! It is difficult enough for MMX to adhere to its own settings and in some cases MMX even tries to adhere to the IDE settings. Why should I take the burden to look after some settings from any other 3rd party tool, especially one that I don't use by myself nor am planning to do so? What if several plugins offer such a functionality, which one to prefer? What if none of these is installed at all? Should MMX provide a similar setting for its own?

Probably yes. In that case it would override any other setting and looking for those would be senseless. That would be the only option I can think of implementing. You shouldn't hold your breath for it, though. The theme support involves a complete re-architecture of the toolbar system and may force fixed toolbars in the first iterations anyway - possibly staying that way if there are not too much complaints. That doesn't forbid a toolbar customization of course. Well, I don't and I cannot see anything justifying to handle this tool different than any other tool - which is simply: As long as there are no incompatibilities caused by MMX I don't care about it being installed or not.

The simplest way, without having to reimplement a couple of things from the original CMShowingChanged is leaving the form on wsMinimized and then calling a SW_SHOWNOACTIVATE: private procedure CMShowingChanged(var Message: TMessage); message CM_SHOWINGCHANGED; procedure TForm3.CMShowingChanged(var Message: TMessage); begin inherited; ShowWindow(Handle, SW_SHOWNOACTIVATE); end; This will also result a "restore" animation, if enabled.

FastMM4 FullDebug in a debug build of our application - LeakCheck in unit and integration tests If any third party leak analysis tool claims that FastMM has a memory leak it probably will tell you the call stack of where it comes from and you will be able to find it. Also are you aware that there is RegisterExpectedMemoryLeak function that the third party tool might not be aware of and has a false positive? As for Deleaker - I think that tool and me won't become friends. UI is irritating and if its burning 100% of my CPU for minutes while triggering a million werfault.exe processes that it supresses until I press cancel to find some memory allocation leaks from that simple program I can't imagine what it will do when I let it run for a real application. "Sorry, but's a no from me"

The problem is not any 3rd party MM but the fact that some pieces in the RTL are deallocated within System.pas finalization which takes place after detaching/finalizing any 3rd party MM (if that one does something in its finalization block as posted in the previous post). And then it tries to give back memory to the system that it orginally had from the already unloaded/detached 3rd party MM. There are various fixes in the RTL (I don't remember which version they did that in) that use SysGetMem/SysFreeMem to bypass the pluggable memory manager API. It can very well be the case they missed something or you are using a version that does not have them yet.

Just for whom may be interested: The CnWizards Lock Toolbars setting is located here: HKEY_CURRENT_USER\Software\CnPack\CnWizards\CnPaletteEnhanceWizard -> LockToolbar

If toolbar management is ever consolidated, that would certainly come from a substantial redesign of the IDE, and would certainly be a benefit. Similar to the issue of hotkey centralization. It would be rather silly for any plug-in to try to organize such things, as the various tool vendors would keep doing their own thing, and the task would be endless.

FastMM4 works perfectly and has no leaks as far as I know. We are using FastMM4 in Delphi applications that run 24/7 for years at the time and it works just fine. That holds for the latest FastMM from https://github.com/pleriche/FastMM4. I have no idea how built-in FastMM works. One should just be careful when running FastMM4 with /dFullDebugMode. In this mode, FastMM never returns memory to the operating system and your code can run out of memory. This is a feature, not a bug.

Well, it has been confirmed now that the "Lock Toolbars" setting is from CNWIZARDS and not from the native Delphi IDE. Since the Delphi IDE seems to have no native setting to lock the toolbars (which is a standard feature in most professional toolbar applications) I would suggest that MMX reads this setting from CNWIZARDS and locks/unlocks its toolbars accordingly. What do you think?

There is List of Delphi language features and version in which they were introduced/deprecated

The next version of the RemObjects SDK will add support for the great Grijjy (https://github.com/grijjy/GrijjyFoundation) foundation classes on their SUPERTCP, SUPERHTTP and HTTP channels! This could imply big perfomance improvements, high output, Google protocol buffers and more. Great news!

EVERYTHING in the Shell has a PIDL, relative to the Shell root. In this case, Libraries is not part of the file system, so you can't get its PIDL from parsing a file system path. The correct way to get the Libraries PIDL is to use SHGetKnownFolderIDList(FOLDERID_Libraries) instead.