Fails when moving Disk->Disk and Disk->Network Share

[TerraD]

Well in fact is does not really fail, because in those moments it does not execute a 'Move here' but a 'Copy here'. Anyway, I want to catch such operations, as it happened to me that I accidentally did a D&D to a different Drive or a shared disk on an other PC in the network.

It would be great if this could be handled in a manner that allows to have unlimited 'ItemText' registry entries. Reason: It is possible to set the UI language in windows on a per user base. e.g. my users prefer to have their client in German, while I prefer to use the English UI. As 'ItemText' is stored in HKLM and not HKCU there can be only one 'ItemText' per machine right now.

I think it would be a nice feature if the D&DConfirm could be configured for all users in HKLM anyway. e.g. if 'ItemText' could support multiple strings (e.g. comma delimited) in the same REG_SZ value: '&Move here,&Copy here,Hierher &verschieben,Hierher &kopieren'. The big advantage of this would be, that one configuration per machine would be enough to configure DragDropConfirm for all current and future users.

I consider your utility a lifesaver - looked many times in the last years for such a feature. Actually no D&D in Explorer would be far better than today's standard. I spent endless hours repairing directory structures and unwanted duplicates in the last few years! As I do not code C++ I can not code this myself - I think the hassle to set up a development environment would just be prohibitive... So I hope some good soul implements a solution!

[bduffek]

I am totally new to this. As in I never compiled anything with Visual C++ much less messed with an explorer extension prior to less than a week ago.

That said while I'm far from knowledgeable about all the inner workings I think I might be able to piece something like this together. (No promises mind you.) the problem with a delimiter is it would have to be something that can't show up in a menu. I'm not sure if commas can, or if there are any limitations.

I've also encountered the unfortunate realization (which I posted a new issue about) that non-primary (default right click) dragging is treated the same, popping up the warning before the menu pops up for the user. This complicates the information in the warning message, since it will show up for any successful default menu test, even if the user wasn't going to use the default action.

[bduffek]

It seems I forgot to respond to this issue yesterday: This pull request adds copy intercept functionality. https://github.com/broken-e/DragDropConfirm/pull/13

While I don't have much experience with this either and wouldn't have the foggiest clue where to start actually creating this from scratch, I used the context of the existing code and looked up functions to make the changes.

As far as the all users thing goes, it already uses HKLM.

As far as an arbitrary amount of options goes, I know C++ will not cover any mistakes with arrays and such, so I'm very hesitant to try and make such a dynamic system personally considering this is the first time I used C++ in like 15 years. If you need more than the two I could add more, but I know that quickly becomes spaghetti code.

[TerraD]

Thank you for the 'copy intercept' functionality! I'll install this as soon as I have half an hour to spend.... - might take 2 weeks or so.

I'm not sure if commas can, or if there are any limitations.

I'm not sure either. I think they are allowed, But the question here is: will the comma ever be in a standard dialog for copy or move - and I do not assume this. However there seems no way to be certain about this. Simple solutions: 1) let the user define his own separator in the registry OR 2) Allow for ItemText3 and ItermText4 (and the corresponding AskDescription). I for myself would be completely satisfied with ItemText3 and ItermText4. Other admins here in Switzerland might ask for a maximum of 4 languages (En, German, French and Italian). As I assume Switzerland is one of the worst countries considering language diversity 4 languages should do for most situations. Conclusion: With 2 languages 100% of the user base will be satisfied, with 4 languages a supposed majority of 99.9% of all future users will be happy. So I would stick with 4 languages and accept so much spaghetti... Of course neither is a proper concept, but limited resources demand for limited solutions! :-)

Such a simple solution will still be far better than needing to adapt the user configuration for each user! Personally I think 2) will lead to a better readability in the registry compared to 1)!

[bduffek]

I'll leave this issue open since many of these ideas are possible, though I have no time frame for implementing them.

There is a multistring registry value type which completely removes the "how do we separate each" issue. I think I would pull in third party code to utilize it. As far as I'm aware Visual Studio should optimize out unused stuff?

This is what I'm considering including eventually: https://github.com/GiovanniDicanio/WinReg

[bduffek]

One thing I've learned investigating this is that information can be stored incorrectly despite its designated type in the Windows registry. This means Windows registry types can't be trusted to guarantee data is correctly stored. A string might be stored without a null terminator, and a multistring may be stored without an empty string at the end. Additionally due to the erroneous "double null terminated" terminology often used, some programs may incorrectly assume an empty multistring must include two null characters, when in reality it would still be correct to have one (an empty string).

To put it simply, a non-terminated string read into a message box would fill the rest of the box with utter gibberish until it encounters a null value. If read into another part of RAM it could cause all kinds of issues, if whatever was copying the information assumed it was null terminated. This kind of thing is why as a novice I'm being extremely careful about this.

There is also the issue of size limitations. I'm not sure if Windows XP supports more than 1024 bytes in a registry value. I will have to eventually find that out, but even if it does the question then becomes a necessary decision as to how much this tool should allow.