broken-e
Feature Request - Button Names and Copy Confirm
Thank you broken-e! Great utility. I have two feature request/suggestions:
- The option to rename the OK and Cancel buttons (to, for instance 'Yes - Go Ahead' and 'No - STOP!')
- The option to capture drag & drop COPY actions (respond to '&Copy here') with separate 'Ask Description'. The basic code works if you change the ItemText registry setting to '&Copy here' so just need to enable multiple ItemText triggers and corresponding AskDescription entries.
Thanks for considering. Arbar1
Disclaimer that I am (extremely) new to this.
1.) MessageBoxW is currently used which allows several options. There is a difference in functionality with MB_YESNO. Other than the if statement needing IDNO instead of IDCANCEL in that case the Esc key no longer cancels if that change is made, which might not be desirable. Outright custom buttons, if I understand what I've looked up correctly, actually require implementing a more custom dialog box entirely. It's possible of course, but not as simple as changing a couple things if I understand it.
2.) I'm trying to figure out if there's a language independent way of constructing the tests, but even with my limited knowledge adding a confirmation for copy would be fairly trivial.
As it stands I figured out how to use Visual Studio Community to compile and register the handler. I haven't the foggiest clue how to appropriately share anything though. If I understand the license correctly, anyone can download Visual Studio Community and play around with this, and after compilation regsvr32 can be used to activate or deactivate the resulting URL. (Restarting Explorer.exe is necessary after deactivating it.)
Edit: Implementing copy support and likely a Registry value to enable/disable it looks to be something well within my limited skill set. I make no promises but I bet I can figure out how to add it, as well as corresponding potential registry values for other languages.
While I could likely spend a few hours to change the button names, it's not something I personally intend to do unless it's desperately needed by someone. My knowledge of this consists a couple hours of messing around with the source in Visual Studio Community 2017. I literally have no experience with C++ on Windows prior to this so if I do end up making anything it will come with that disclaimer.
As per the above notification I implemented an off by default copy check with corresponding potential registry values to customize it.
Whether broken-e wants/approves of any of the changes I made I can't say, but I believe I got it working.
As for custom buttons I'm not sure I'm comfortable with my limited knowledge trying to implement that personally. Some searches yield chatter about how to do it. If you really want it if I have free time I can try to figure it out, but it's far more complicated than the other changes I personally made.
Thank you bduffek. I'd love to test your changes, but unfortunately I don't have the ability to compile the code. Could you, or anyone else participating, upload a compiled DLL (64 bit) ?
Sure, but do keep in mind I've never used Visual C++ until literally last week. There may be debug information or something. I don't know off hand how to compile the whole project so the installers get generated and such. broken-e also made mention that both the 64 and 32 bit versions are required, and likewise for the configuration. I do not know the special situation in which the 32 bit version would be used in 64 bit Windows.
DragDropConfirm_64_NOT INSTALL FILES.zip
I put the not install files disclaimer so it can never be confused for an official release. The batch files are what I was using to test it and detach it for modification. The detach one closes and restarts explorer.exe (so any File Explorer windows and other things that run with the shell will close if that batch file is run).
I put the registry configuration additions in the description of the pull request. https://github.com/broken-e/DragDropConfirm/pull/13
Fantastic. Confirmed the changes are working for me in initial testing. Thanks again bduffek.
As for 32 bit DLL, wondering if some sort of move/copy initiated from within MS Office 32 bit installed on 64 bit os would trigger?
I just realized is the current installer up to date with the changes merged in last year? That would explain why people were talking about the message popping below windows if so.
I have no idea how to make an installer like broken-e has. Hopefully they see the activity and respond. Either way I'm glad they made this. Here are the "release" compiled 32 and 64 bit versions. The disclaimer being all I did is select "release, 32 bit, compile, 64 bit, compile" so I have no idea if it I did properly. The one I shared earlier was in fact set to debug.
Of note here both say they register but I get an error message when trying to deregister both. I'm not sure if they are supposed to have some kind of different internal ID or something there. DragDropConfirm_BDuffekModifiedMay252017.zip
No the current installer does not have the latest DLLs. They would have to be downloaded separately here and substituted manually as we are doing with yours. As to un-registering, I'm seeing the same thing - which ever one you un-register first succeeds and the second fails. Never the less, you're files are working for me!
Oh, as for 'versions' of the DLL's - All of the compiled files show the same version number in the windows properties 'details' pane, making it difficult to tell which version you've got.
Oh good point. I don't know if there's a standard convention there. If broken-e doesn't get back to us on this chatter I'll just look at the old versions I suppose, thanks!
And to set your mind at ease re the deregistering error, the original (installer) versions of the DLLs generate the same error.
I searched the registry a bunch of times and it seems unregistering one does so for both. Searching online it IS proper both share the same GUID, from the chatter I found. That's probably why it happens, but the uninstall program takes care of it anyway. Thanks for your feedback too.
I also figured out how to make the 32 bit DLL use the normal section of HKLM in the Registry when on 64 bit Windows. This means, if I did it correctly and I did test it once, duplicating configuration to the Wow6432Node part of the Registry is no longer necessary. You are 100% correct with your Office example. I was able to test the 32 bit version separately by playing with the open/save dialog in Office. If it ever worked with Windows 2000, it will not after that change though.
Finally I looked at broken-e's files and he actually includes the installer information. I just didn't know what I was looking at. It's built with the free NSIS install generator program. I created a separate branch so the install files are separate from my pull request: https://github.com/bduffek/DragDropConfirm/tree/installation-files/Installer
I changed the version to 1.1.0.1 and appended _BD where possible and also changed the year to 2017. I don't know what number broken-e would give it if he wants the changes I made.
I notice there is a pull request that says it enables XP support. If I have time I'll see if I can work the additions/changes into that too, if broken-e can't be contacted. Thanks for all the feedback and absolutely keep posting if you want me to try to add something else. The button name thing looks like it would involve inspecting currently open windows and such and goes beyond merely editing the line that calls the window. If you desperately want that I can look into it but it's far beyond my current knowledge (which was nothing prior to looking at this last week).
Because button name changes aren't implemented, I will leave this open. Allowing that would require significant changes beyond the scope of what I'm personally comfortable doing, but perhaps someone else knows this stuff better to do it more comfortably.