I'm pleased to announce KPEnhancedEntryView has now reached beta state, and is ready for users to play with and test. This is a plugin to provide a new UI for viewing and editing both individual entries, and mass editing a multiple selection in KeePass, as a replacement for the standard textual entry view.
I don't expect it to cause any problems in use, but make a backup of your database before trying it anyway, that's just common sense.
Project page: http://sourceforge.net/projects/kpenhentryview
Bug reports, questions and comments are welcome, as are suggestions for improvements.
This is very interesting, thank you! I recommend F2 (as a typical "rename" hotkey) for inline editing instead of ENTER.
Also: If I change an entries title with your plugin, the title in the entry list refreshes only after entering/leaving the entry, maybe you can send some refresh command to Keepass.
Hello, thanks for your feedback, I'll take a look at the title refreshing issue.
For F2, what I decided on was that F2 would rename the field, and Enter would edit the value. I thought that matched the "rename" semantics better, and that renaming would be a less frequent operation than value editing, so could use a more obscure shortcut.
Well, I'm going to assume no news is good news. In the absence of any further bug reports, I've released v0.2 with just a fix for the issue where making changes didn't notify KeePass to refresh. Download link for the latest version remains: http://sourceforge.net/projects/kpenhentryview/files/latest/download
In answer to Paul's points, from the earlier thread: https://sourceforge.net/p/keepass/discussion/329220/thread/feaafea4/#8efd
Launch URL on the context menu is a great idea, I'll add that.
So the idea would be that you could drag and drop a row, and it would work as if you had dragged the text of the value? That could work, I'll see what I can do.
Drag and drop as plain text from the notes field might be tricky - rich text box controls are horrible, but if it's possible, I'll enable that.
I've just checked, and drag and drop from the attachment field does currently has a bug in it, but when it is working it still wouldn't let you drag and drop the file contents as text into Notepad. The idea is that it performs a drop of the file into a destination folder in Windows Explorer so you can extract the file to a location of your choosing. In order to allow you to drag and drop onto an application, the file would have to be extracted into a temp folder somewhere, which I see as being a security issue. KeePass wouldn't know when it was possible to delete it, so the file would just stay there, out of sight, out of mind, and likely never be deleted. At least if you've dragged and dropped a file directly to a known location then you are taking responsibility for the security of that file - I can guarantee it's not been written out to any other location on disk, it was only written to where you put it.
Protect Field doesn't change the field protection. Hmm. Not sure why this change isn't always sticking any more, I'll look into that. Thanks for reporting it.
As I thought, the RichTextBox control does not have great support for drag and drop. Tellingly, KeePass itself has code for allowing drag and drop out of the entry view text area, but has it all commented out! I don't know if it is possible at all to do text drag and drop from these things, but if it is, I suspect it isn't worth the effort.
On the other issues, though, I'm happy to report much more success. v0.3 now has an Open URL context menu command, allows drag and drop of field values, fixes the bug with dragging and dropping attachments, and fixes the bug with protecting fields.
KPEnhancedEntryView v0.3: http://sourceforge.net/projects/kpenhentryview/files/latest/download
What version of KeePass are you testing with? I can't get 0.3 to load with V2.19 or 2.21.
I am using 2.22, but I thought it was supposed to work backwards compatibly too. Maybe it has to be using the plgx system for that - I will try to set up plgx generation tomorrow and see if that helps.
Finally managed to get plgx generation working, I think. I've uploaded a new version packaged as a plgx; if that one fails, could you let me know any error message that it displays? Thanks, Alex.
KPEnhancedEntryView v0.4: http://sourceforge.net/projects/kpenhentryview/files/latest/download
All of your fixes are working really well. I like being able to single click the URL, or choose from the context menu.
To make it more like KeePass you could add the additional launch options that KeePass has, or just use the KeePass context menu - probably not possible.
File names no longer drop into Notepad++, but I can drag n drop the file onto disk.
Notes are still copy/paste, but at least I can do it.
When a value is changed the KeePass history is not updated. I've tried just changing the value and saving after the change.
It's already possible to both open and copy the URL, so I guess you mean being able to open with a specific browser? OK, I'll look into whether this functionality can be reused. I can't use the KeePass menu directly, as that only applies to the URL field itself, not any field with URLs in it.
I admit, I've never actually used History, but I assumed it was something KeePass would take care of itself. Apparently that isn't the case, so I'll have to investigate how history is managed. If it is exposed in a way plugins can access, then I'll handle updating it too.
Thanks for the feedback,
PLGX looks fine too. Tested with 2.21 & 2.22
I've just put v0.5 up for download from the SourceForge page. History should be fixed now, and I've added the submenu with extra launch options for links in the field context menu. This is a bit hacky, as the KeePass functionality for doing this isn't really exposed to plugins, so it might not work properly on all possible versions. In any case, the plain "Open" command should keep working even if the others don't.
KPEnhancedEntryView v0.5: http://sourceforge.net/projects/kpenhentryview/files/latest/download
History is now working as expected.
Open URL works if the URL field has a properly defined URL (http://www...) but not if you leave off the http:// off. If the field is the standard URL field you should probably assume the value is a URL - which KeePass does already.
Open URL also doesn't work if you have a cmd://.
Thanks for reporting this. I've fixed up URL handling of non-standard URLs (it was previously parsing them as URIs and then using the parsed value to execute, rather than the original string, so "cmd://notepad.exe" would be executed as "cmd://notepad.exe/")
I'm not entirely convinced that it should always assume that the contents of the URL field are a valid URL, but given that KeePass does, I take the point that KPEnhancedEntryView should behave consistently, so I've made that change too.
KPEnhancedEntryView v0.6: http://sourceforge.net/projects/kpenhentryview/files/latest/download
Testing with either of these command lines doesn't work in an additional field, but are OK in the URL field.
cmd://%comspec% /k echo Hello
cmd://cmd.exe /k echo Hello
This command line is OK in an additional field.
If I copy a value and then paste it into a field value, when the clear clipboard action takes place the edit fails as if you have pressed Esc.
When I click on an entry the entry view pane seems to update twice over about a second. this makes it look like the screen is flickering and stops you selecting another entry - at least on my Windows 7 system.
Thanks for reporting these. I think they are related - when KeePass raises the UI State Updated event KPEnhancedEntryView refreshes itself. Unfortunately, for some reason, KeePass raises that event when the clipboard is auto-cleared, which is why it's dropping you out of edit mode when that happens.
Also, when you select an entry, KeePass raises that event twice, which is why does the double-update thing.
I can't just ignore the update if the same entry is still selected, because the entry may have been edited. I'll try running for a while with an additional check to see if the last modification timestamp on the entry has changed and see whether there are any side-effects of that - hopefully anything that means the view should be refreshed would touch that modification timestamp, though.
I'll be honest this plugin is the only reason I am even considering using KeyPass as the standart layout simply does not work for me. I do however have two suggestions:
1) Would it be possible to hide blank fields (including username and password)? Reason being is that I am not only storing login/pw data but other information such as my libray card where these fields are simply not applicable
2) I still think copying the field value to the clipboard could be easier. Ideally a single click on the field copies it and double click edits
Thanks for your comments - the plain text entry view put me off too, which is why I thought I might be able to do something a bit nicer!
For your suggestions:
1) I quite like this, actually - several of my entries don't use the standard fields either. I've got a nagging feeling there's a good reason not to do it, though, as the standard fields are never "not present", only "blank string", whereas custom fields can be "not present" and "present with a blank string" - so you'd end up with slightly different behaviour when you did, for example, Select All and Backspace on a standard field if I made them hidden when blank. I'm going to try it out anyway, and see what it's like to live with. If it seems OK, I'll include it in the next update and see if anyone complains!
2) Not going to happen. Copying sensitive data onto the clipboard is an action that should only be taken in response to an explicit informed user command - simply clicking on a field is not sufficient to indicate that the user wanted to put it on the clipboard, or that they were aware that's what would happen when they clicked it.
And a double click for copy and right click context menu for edit? It's a good idea, no?!
Ps: congratulation for your plugin!
Thanks for your reply. As to the "click & copy" functionality it's actually present in quite a few other password apps (Safewallet, mSecure) so it's not unheard of but I see where you are coming from. I'm not sure if the plugin would go as far as allowing you to place a copy icon to the right of every field. Guess that would be a bit more obvious having to click that...
Hiding blank fields is not a good idea. As an example.
Create new entry and fill in the user name. Close the edit window.
Drag n drop the user / pass to register on the new site.
Go to the login page of the new site and copy the URL.
Oops, no URL field to fill in!
For a copy icon on every field, security-wise I think that's OK, as long as it was a fairly clear 'copy' icon, but aesthetically it would look horribly cluttered. Perhaps if it only appeared when the mouse was over the field in question... Anyway, it's a bit academic at this point as the ListView control I'm using doesn't really support buttons in cells when they are not being edited. It might be possible to hack something together with custom drawing and tracking the mouse, but for the effort involved and the minimal benefit gained, I don't think it's worth it.
Have you tried using drag and drop instead of copy and paste? If the two clicks involved in right-click, copy are one click too many for you, then you might find drag and drop to be more click-efficient.
Paul, thanks for your comment. What I was thinking was that the "(add new)" insertion row could be used to add standard fields when they were hidden. So in your example, after copying the URL, the user would double click (add new), pick "URL" from the list, and enter the value there. It makes it consistent with the way you would add other fields which weren't visible, but in your example, is clearly less convenient. I'm a bit on the fence about this one. On the one hand, do the standard fields really need special treatment over all other fields? They might not be the only ones that I'd always want present for ease of filling in with new entries. On the other, they are de-facto special cases in the way the KeePass treats them elsewhere.
Anyway, I've produced a v0.7 with the standard field hiding behaviour. If it turns out to be more annoying than helpful, I'm keeping an open mind to reverting it back to always showing them. 0.7 also uses the modification timestamp check I proposed to reduce the flickering and edit-cancelling on clipboard clearing issues.
KPEnhancedEntryView v0.7: http://sourceforge.net/projects/kpenhentryview/files/latest/download
I think with regards to copying the password/field contents I just need to get used to doing it differently :)
As for hiding the blank fields I think it's absolutely brilliant! Thanks for turnin this round so quickly!
Log in to post a comment.