App plugins

[sfrazor 3]

I'm wanting to extend a Windows app via plugins.  I'm sure this has come up before but I'm not quite sure what to search for.

I have a standard windows Form app  that has a  menu across the top and side.  I'd like to add plugins (new menu options) to the menu on the side.  

I'd like for the plugin to be scripted so any dev can add them.  I down want be stuck producing a dll that has to be put in place but prefer a script (not picky about the scripting language)

Add the plugin script to a folder and when the app starts/restarts the new menu item shows up and is interactive with the main app.

Simplicity is key....

 

I'm sure I can do it but it sounds more difficult than it probably is.  This is something I'm toying with after seeing a python app that allows plugins via very small and simple python scripts and am curious if I can accomplish something similar.

 

Can someone point me to an example perhaps?  Or ideas?

 

 

 

 

 

Edited June 1, 2023 by sfrazor
More info

[Fr0sT.Brutal 900]

You didn't say how these plugins should be linked to main app, probably something like RAD's Tools menu is enough? Otherwise you'll have to either include a script engine into app or have some interface a la COM in the main app for plugins to interact with

Edited June 2, 2023 by Fr0sT.Brutal

[sfrazor 3]

2 hours ago, Fr0sT.Brutal said:

You didn't say how these plugins should be linked to main app, probably something like RAD's Tools menu is enough? Otherwise you'll have to either include a script engine into app or have some interface a la COM in the main app for plugins to interact with

Thanks Frost, for me, this whole exercise is learning. 

 

I've never tried to dynamically extend an app other than dll's.  I'd think including a script engine would be a good way to go.  What would really be good is to be able to create the plugin from within the app.  So a script editor perhaps available in an admin area.  Sort of a mini Delphi editor maybe.  I've read a bit about some of the scripting tools in Delphi having access to the main app by exposing certain classes/objects.  That's also interesting but I'm not confident on how to tie it all together.  Sorry if I sounds like I'm rambling.  This weekend I'll dive in a bit.  My bet is that someone has been down this road already, and solved it.

 

All of this came from a python app I was working on.  Its easy to include a plugin because the entire language is scripting and the groundwork for  pulling in plugins was already in place.  It was prone to lots of debugging, so I was thinking maybe I could do it in Delphi easier once I got it straight.

 

 

 

[PeterBelow 238]

The classical way to implement plugins in Delphi is to create packages for the plugins (run-time packages) for which the host app looks in a folder defined in the app's settings or hardcoded to a subfolder of the folder the app itself (the exe) is located in. At startup the app looks for packages (bpl files) in this plugin folder and loads each one in turn via LoadPackage. The package then registers its plugin class in a unit initialization section, for which it calls a method of a class registry singleton object that is implemented in another package that both the app and the plugin packages use (static link). The app then builds the plugin menu from the list of registered plugins. It can also offer an API through such a shared package to allow the plugins to access the host app UI (like the IDE OpenTools API).

 

This is basically the same design the RAD Studio IDE itself uses to load components. The main drawback is that you need to build the app itself with run-time packages for the run-time library and the VCL (or FMX if you use that for the UI). This makes sure app and plugins use the same memory manager and other RTL and VCL/FMX classes but it complicates distribution of the app, since you also need to distribute the required run-time packages. It gets worse if you use 3rd-party components in app and plugins since you also need to install the  run-time packages for those. Any class to be shared between host app and plugins has to be implemented in a run-time package this way. 

 

With this design you do not need to change the host app to make it use a new plugin, just copy the new plugin package to the app's plugin folder and it will be loaded on next app start.

[Fr0sT.Brutal 900]

46 minutes ago, sfrazor said:

All of this came from a python app I was working on

Then Python4Delphi is your choice. There's even special section for it here in the forum

[dummzeuch 1505]

Alternatively there are quite a few other scripting engines, like the one included in Fastreport (Pascal, Basic, C, if I remember correctly) or DWScript (formerly known as Delphi Web Script, but definitely not restricted to Web usage).

 

Extending a program by such an engine mostly means to provide an interface for these scripts to access the programs data and optionally the UI. It can be quite challenging to determine what to expose and in which way.