#59 Additional Plugin Access in Core

Mitch Capper

While I have made several additional changes to the core that I will submit at a later date, this is a fairly minimal set of changes required for a plugin I am working on (KPEntryTemplates). It modifies two classes PwEntryForm, adding an event for when it is loaded and when it is saving out, exposing the ability to manipulate fields on the form, and finally exposes its TabControl so plugins can add tab pages to the form.

Secondly it modifies EntryTemplates adding an event right before the creation of a new entry based on a template allowing the user to edit the entry before its shown to the user. This will allow plugins that want to extend the template system to do whatever additional functionality on the creation of a child.

The patch is attached.

The reason for this minimal patchset is to get it included in the next release without hassle. I do not know when this will be, but I figured it it was soon the smaller the better.

In return once a new release happens (assuming the patch is accepted) I can release my new plugin: KPEntryTemplates. You can see some screenshots at:

The plugin basically allows the user to create simple GUI's around the fields for easy entry. The great part about the plugin is none of the data is stored outside the entry and _minimal_ extra data is stored. In a child of a template the only extra data stored is a single additional String that is the GUID of the parent that is the template for it. In the template it stores several extra strings for the GUI but again they are just stored as strings in the entry.

It allows wrapping not just additional string fields, but also wrapping the standard fields in the gui. It nicely adds itself just as another tab on the PwEntryForm. Using it is fairly simple if you look at the first window that is what you see if an entry is neither a child of a template or a template. Init As A template just marks it as a template, and shows the gui builder (screen shot #2 and #4 and #6). Then for child entries you can attach them manually to a template by clicking set template parent (or if you use the built in new template functionality this is automatically done) so then you just see the gui as decided by the template (screenshot #3 and #5). Screenshot #6 shows the options of the GUI Builder.

If you have any comments/suggestions on the plugin let me know I tried to figure out the various GUI types people would want, I debated on checkbox but couldn't come up with a template that would use it so didn't add it. Otherwise it is fairly good to go as soon as a keepass release has this patch integrated.


  • Mitch Capper
    Mitch Capper


  • Dominik Reichl
    Dominik Reichl

    Your plugin looks very interesting!

    Unfortunately, I disagree with the approach how you've modified the KeePass core code. You're exposing many controls by adding new properties and methods. This doesn't really scale. If I'd agree with this approach of exposing UI elements, I'd need to add properties for each and every control in each and every dialog.

    My suggestion would instead be to use the public 'Controls' property that each form already exposes and use the 'Find' method to locate the control you want access to. For example, to get access to the tab control in the entry editing window, you'd use entryform.Controls.Find("m_tabMain", true). This approach on the one hand scales very well (plugins can locate exactly the controls that they want to get access to, without cluttering the KeePass core code with unnecessary properties), and on the other hand it's more future-proof: when a new control is added in KeePass and you want to use it, your PLGX plugin can still work for older KeePass versions where the control didn't exist yet (with an exposing property, the PLGX instead simply wouldn't compile). It is very unlikely that control names are changed after an official release (actually I can't remember doing this so far), so you don't need to fear changed names (and even if they'd need to be changed for some reason, you could still search for both names).

    Of course, the above approach only works for dialog controls, not for private variables of PwEntryForm. I therefore do see the need to expose these through properties and have added some: EntryRef (access the the PwEntry being edited), EntryStrings and EntryBinaries (that expose m_vStrings and m_vBinaries). Also, the important UI updating methods are now public: UpdateStringsList and UpdateBinariesList.

    I've also added the event in the EntryTemplates class (actually I've added two, one happening before the entry is added, one afterwards).

    In order to detect when a PwEntryForm dialog is opened, subscribe to the GlobalWindowManager.WindowAdded event and check whether the form is a PwEntryForm (use 'is' or try to cast). If it's a PwEntryForm and you need to do some delayed initialization, you can subscribe to the form's events (Load, Shown, ...).

    You can find the latest 2.x development source code here:

    With these new properties and public methods, you should be able to implement all the methods you've implemented in PwEntryForm in your plugin instead. Please let me know if there's anything still missing to realize your plugin!

    Thanks and best regards,

  • Dominik Reichl
    Dominik Reichl

    • status: open --> closed