DragDropConfirm
DragDropConfirm copied to clipboard
broken-e
Seems it does not work on non-English Windows
I tried to install the latest DragDropConfirm on Czech version of Windows 7 Pro SP1 but nothing seems to happen. I think the problem is that the check is valid for English version only. I propose to look for some value for "Move here" that is language-agnostic and does not change in non-English versions of Windows. Or if it is such a hack that it cannot be done easily, to have a hard-coded list of these "Move here" strings in all language versions of Windows which would be a nasty way to fix it, but perhaps working in most cases.
I want to look into this but I'm a novice. Implementing specific languages would be trivial but ideally as you suggest would be best. As it stands, if Microsoft changes the exact text it would break too, so if there is a solution to this it would help prevent that situation as well.
Edit: I figure there has to be a way somehow. I've found there are "canonical verbs" but I don't know how/if they can be retrieved and converted to the version that corresponds to the current Windows version and language setting.
Edit3: It doesn't do it automatically but the below link explains how to customize it for other languages.
A temporary and hopefully easy solution could be to read the current language setting from the system and set the proper "ItemText" according to the system localization while installing.
For this, we could collect the proper strings for different localizations here. This would help people who are not familiar with the registry to easily install it.
Another question/problem I asking myself is the following:
Windows Ultimate Edition for instance does offer a switch to change the GUI language in real time between other installed localizations. -> What will happen to the "ItemText", will the confirmation dialog appear? If not, you had to change this value to perform with different localizations.
I'm not very familiar with the inner workings of this. It seems to me the code executes every single time, so I'm not sure how much overhead would be acceptable making the automatic process happen every time. Perhaps a separate configuration tool would be an alternative. Such a tool could be written with a much higher level language without any risk of breaking anything in Windows. I'm very curious where Windows stores the localized strings, and how complex it is to read them. I'm not sure if I'll have time to investigate that personally, but I'm much more comfortable with a helper tool than making the DLLs themselves too complicated.
I think you've got me wrong:
by "read the current language setting from the system" I meant to read the language from the system, e.g. the registry: HKEY_CURRENT_USER\Control Panel\Desktop\MuiCached
so that the installer can compare the language string from that location with a list of its own to then set the proper language for "ItemText".
What I suggest is to save a list of "ItemText"-Strings from different languages to store them in the installer for first time install.
I just learned there is a multistring registry type. Not only that, but it doesn't even break the current implementation if it exists instead of a string. I am hoping this will actually allow multiple checks for multiple languages to be quite easy to implement.
Currently the HKEY_CURRENT_MACHINE location is used. Do you think it is necessary to change it for the current user only, or would a change allowing multiple strings to check work?
In fact it may even be possible to store different messages for different languages utilizing multistrings as well. I make no promises, but the potential looks very realistic.
A secondary configuration project is realistic too, and that could even be written in a much easier managed language like C# (targeting the .NET version supported by Windows XP of course).
I have no experience with programming. So I can't help you. I just know about the difference between LOCAL Machine and CURRENT USER. You can experiment with the attempt of using LM or CU for different language settings, if it fits the goal.
Because this uses C++ extreme care needs to be taken working with memory, so I'm not rushing into trying to implement the multistring support. I do plan to work on it when time allows eventually. I understand you have no experience with programming but a simple example of the difference between something like C++ and a managed runtime like C# is in C++ if you write something incorrectly you can end up writing over other parts of memory you have access to or allocating memory and never releasing it, causing a memory leak. With something like C# it is much more difficult to do things like that. Coupled with the fact this hooks into such a core functionality of Windows, as a relative novice I take any change I attempt extremely seriously. Hopefully I'll have time to work on this again soon.
I'm leaving this open due to PeJeyDimO's suggestion. It might be possible to do those things with the install system.
I'm not saying I will definitely personally implement this however I see with the currently utilized installer tool the functionality likely exists: http://nsis.sourceforge.net/Detect_System_Language_Name https://stackoverflow.com/questions/14409801/nsis-detect-windows-version
Such a feature would need an included set of localized instructions specified for each language. I'm not sure if language names differ for each version of Windows too. It's a potential can of worms, but if properly implemented it could be quite useful.
Is there any update on this issue?
It works with other versions, but instructions need to be updated. See my reply to this closed issue here: https://github.com/broken-e/DragDropConfirm/issues/22#issuecomment-571279832
Actually implementing the multistring idea isn't something I've had time to do. I used free time when caught up with work mid summer the other years when looking at this, and I have had more to do the last couple summers. This does work though; you just have to do as in the reply I linked to in order to get it to work in another language.
After reading: https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-menuiteminfoa
It looks to me that you can identify a menu item by wID
wID Type: UINT An application-defined value that identifies the menu item. Set fMask to MIIM_ID to use wID.
It makes sense that a menu item should have a proper ID that is used to identify the object, as we all can see, the name can change on the fly.
