Can you access standard Windows strings like 'Cancel'?

Question

I am building a Windows dialog box that has the standard 'OK' and 'Cancel' buttons. Given that Windows uses the same button text in its own dialogs is there a way for me to grab the correct strings to use on the buttons?

This way my application will have the correct strings no matter which language is being used, without me needing to localize it for lots of different languages myself. I am using C# but can happily use platform invoke to access an OS method if needed.

NOTE: Yes, I can easily localize the resources but I do not want to find and have to enter the zillion different language strings when it must be present within windows already. Please do not answer by saying localize the app!

Answer 1

In Visual Studio: File + Open + File, type c:\windows\system32\user32.dll. Open the String Table node and double click String Table. Scroll down to 800.

Microsoft takes a pretty no-nonsense stance against relying on these resource IDs. Given the number of programmers who've done what you're contemplating, it is however unlikely they can ever change these numbers. You'll need to P/Invoke LoadLibrary() and LoadString().

However, your ultimate downfall on this plan is Vista/Win7 Ultimate with MUI language packs. Which allows the user to switch between languages without updating the resource strings in the DLLs. Such an edition will always have English strings.

Answer 2

see MB_GetString which claims to do exactly this:

https://msdn.microsoft.com/en-us/library/windows/desktop/dn910915(v=vs.85).aspx

however, it seems to require runtime linkage:

http://undoc.airesoft.co.uk/user32.dll/MB_GetString.php

Answer 3

Well, if you use the standard MessageBox.Show() function and pass it approriate parameters it will automatically localize the yes/no/okay/cancel buttons for you.

What is more interesting is how you localize the message text.

Answer 4

No, there is no standard, supported way to do this. Yes, Windows does store these strings and it's (with some effort) possible to obtain them, but there is no guarantee that they'll remain in the same location and under the same identifier from version to version.

While you might not want this to be the answer, the answer is, indeed, to localize your application. If you're localizing everything else (as you'd have to, unless you just wanted OK and Cancel to be localized), I'm not sure why it would be any great effort to include localized values for OK and Cancel as well.