Vincent Parrett

I've been using Delphi for 25 years, I'm working on a 20 year old code base, I'll let you know when I'm done refactoring

I've used the addictive lib for many years, but it's become a problem for me while separating execution from UI code so I can get by app running on docker - the library is so tied up in the vcl that it's not usable from a console app. Sadly, it appears the devexpress and tms ones are also dependent on the vcl (layered api's people!)

I just got done with this and it just worked! I did have to modify the hard coded path for the UsesHelper.SearchPath to match the delphi version I'm using. I tested first by specifying an output directory, and after checking with beyond compare to see how it did, I just processed the original files. It did also introduce some compilation errors, where I have prefixed function calls with the unit names (e.g SysUtils.DeleteFile ), simple to fix though. Thanks @Uwe Raabe

Not strictly speaking, but not relying on the scope names does actually speed up compilation. Then there's the different code styles in thousands of units created over 20 years, I'm a bit OCD I guess and want to apply the same standard across all my code!

@Uwe Raabe thank! I'll take a look at it tomorrow.

Hi All Anyone know of a tool that can fix up unit namespaces in the uses clause, ie change uses sysutils, stdctrls; to uses System.SysUtils, Vcl.StdCtrls; I have a few thousand units to go through and clean up, I've tried regex etc but it's not reliable enough.

Not sure if this is still the case, but hi color icons were not supported by brcc. I switched to using rc years ago because of this and never bothered switching back, so maybe that's been fixed (but I would not be surprised if it hasn't been).

There's no easy answer to this question, and it's one I've battled with for 20+ years. If it's a trivial change (< 10 min to code and test) and I think it's relevant (not all customer feature requests are, we have to evaluate how they apply to all users) I'll often just go ahead and do it immediately after reading the ticket. It's appreciated by customers, but a double edged sword, the more you do it the more they ask 😉

Good point... I wrote that message (in the core) months ago, before it was actually working so my mindset was probably a bit pessimistic back then 😉

Made some progress today on IDE integration, screenshot below of my first attempt at doing a dpm restore in the IDE plugin. Very much early days with the IDE integration, but it was still a punch the air kinda moment when it worked first time!

The package cache is accessible from projects without modification, but that's not my primary use case... in fact I can't see why you would want to do that. As for stand alone and being easily backed up.. I've not found making my vs.net projects stand alone necessary at all. I use distributed version control (git and mercurial) which is backed up (along with the copies already on our CI servers and other dev machines) - and our nuget packages are backed up (by nuget.org and our own backups for packages we haven't published). I've not tried using npm pack on a non package project, but does it really back up all the dependencies, I don't think it does.

Thanks @Uwe Raabe - IOTAIDENotifier was exactly I needed - first ever dpm restore on project load Still plenty to do but the basics are working

Thanks @Uwe Raabe I'll take a look at that tomorrow.

Global as (by default at least) 1 copy of the package on the file system, but not global as installed on the ide library path. Not sure what you mean by packing the whole project?

Hi All Any Open Tools api experts here? I'm working on an ide expert that needs to be notified when a project is opened and closed. I have something working IOTAProjectFileStorageNotifier, however when project groups are opened I can't tell because the ProjectLoaded method is never called for it. Is there a better way? Ideally I'd like to be notified before a project/group is loaded (I just need the filename). thx