Which setting in an MFC app controls the title shown in the windows 7/8 jump-list, just below the actual list of jumps, above the pin application option?
This is mainly so that a localised string can be used for non-english systems.
My first thought on this problem was that it could be set in the version resource file, although adding a new localised section (sweden in this case) and setting the description/file name does not seem to affect the text i'm interested in.
Finally figured this one out, the name used here and in several other places is set in a registry key for the application at
[HKEY_CLASSES_ROOT\Applications\AppName.exe]
"FriendlyAppName"="This text is shown"
Some documentation can be seen here: https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx#applications
Related
We need our application to be able to accept languages such as Korean/Japanese etc. as input.
However, if I have my Keyboard language set to Korean then in the bottom right of the task bar I get this:
and if I try to input anything, It's just regular english characters.
In any other windows application (including stack overflow) I can input these characters (ex ㅔㄹㅎ), and this is what the taskbar looks like:
I'm using Qt and C++, is there any way I can get the same behaviour as any other application?
We are using custom text edits rendered with OpenGL/DirectX. On the Gl/Dx widget I needed to add setAttribute(Qt::WA_InputMethodEnabled); in order to enable the IME.
Try changing the default locale of your Qt application to the language you are targeting.
QLocate::setDefault(QLocale("ko_KR"));
I am not new in C++ but this is my first time developing a Win32 program. It has to be graphical and so I have been attempting to get user input using an input/dialog box with no success.
I have read this topic on MSDN and found it helpful, but I get an error about IDD_PASSWORD and IDE_PASSWORD not being defined. Declaring them in resource.h and giving arbitrary values (like 110, 111) yields no results. Other attempts I have tried to modify the auto-generated about box, which also yields no results after modification, I noticed that if i change the value of IDD_ABOUTBOX in resource.h from 103, this also does not work. I also tried using the .rc under Resource View, but still no results.
So I'd like to know if the resource box templates have predefined constant numbers that i have to use, if so where because I searched that too or if there is another way to obtain user input in a windowed application. I just want to obtain an integer, that's all.
There is nothing magic in the numbers assigned to resources. The numbers are what the code actually uses to identify the resources. Visual Studio just allows you to assign symbolic names to those numbers through the use of C macros (i.e., #define) to make your code easier to read. These values are all defined in the file resource.h by convention, and although you can modify that file manually, you usually should not do so—let the Visual Studio Resource Editor handle that for you.
The problem you're running into is that you actually have to create those resources first before the numbers will mean anything. When you create a new Win32 project, Visual Studio will automatically create an about box dialog and give it the symbolic ID IDD_ABOUTBOX. However, there is no such IDD_PASSWORD dialog created by default in a new project, and there isn't one built into Windows.
You can create this dialog yourself using the Dialog Editor (part of Visual Studio's Resource Editor), which is pretty easy to do as it allows you to drag controls around on the dialog where WYSIWYG. When you add a new dialog box to your project's resources, you will be given the option to name it anything you like. You can use IDD_PASSWORD if you want, or any other name. A numeric ID will be assigned automatically based on an algorithm; generally the lowest available number is used.
The article you linked to is assuming that you have already added a dialog to your project with the symbolic name IDD_PASSWORD (which is probably a mistake on the part of the author). All it shows you is how to display that dialog once it exists as part of your project's resources.
It's going to be somewhat difficult to learn Win32 programming just by reading the MSDN documentation. I strongly suggest getting a book that explains it more clearly and in a more logical order. The canonical text is Charles Petzold's Programming Windows, 5th Edition. Note that you will need to make sure you get the 5th edition, as the newer editions digress from their Win32 roots and start talking about completely unrelated things like C# and Silverlight.
If you absolutely must learn by trial-and-error and MSDN, start reading about dialog box resources here.
Our company has an installer written in C++ that creates program shortcuts using IShellLink as described in:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb776891%28v=vs.85%29.aspx
On Windows 8 all shortcuts created in the Start Menu will also show as titles on the Start Screen. What we're looking to do is programmically control which icons are shown on the Start Screen. In the following article it describes the option "System.AppUserModel.StartPinOption" as:
To create add an app shortcut without pinning it to the Start screen
view, you can set the following property on the shortcut:
System.AppUserModel.StartPinOption = 1. The symbolic name for 1 is
APPUSERMODEL_STARTPINOPTION_NOPINONINSTALL.
http://msdn.microsoft.com/en-us/library/windows/desktop/jj673981%28v=vs.85%29.aspx
This appears to be possible using the Windows Installer, however I haven't found a way to accomplish the same functionality programmatically in C++ given our context.
If anyone has any information about this, or an example of some sort, it would be much appreciated.
One thing I found was that "..NewInstall" literally means that. User customizations to the tiles seem to be retained even after you delete/update the .lnk files. This is probably a good thing as updates won't reset the user's environment, but it does mean that I needed to use fresh installs of Windows 8 during testing. I used a VM box to minimize the pain. At least I don't know how to delete the properties once set from within the environment.
I am a .NET guy who is having to do some work on an MFC app. The app is a VS2008 MFC executable which I have converted to VS2010. The original developers did localisation by specifying the name of a .txt file with key value pairs in it on the applications command line. Installed shortcuts to the executable specify a different .txt file depending on which country the app is being installed in. This of course does not work if you just run the .exe directly. This seems like a weird way to do things to me.
I want to do this the propper MFC way, but I am having difficulty finding definitive answers on Google. My understanding is that the String Table in the .rc file should be used for this localisation? Is this the current best practice for MFC?
With respect to the String Table I have read that the practice is to create multiple string tables each for a different language. How do MFC applications choose which language to use? Is it based on the machines current language settings or can I control this (it may be that we want the language to be specified by the Wix .msi installer we are also building)?
I have also read that embedding all resource inside an MFC application has fallen out of favor and that now you should compile seperate resource .dlls? Is this is true ill investigate how to do it...
Finally, do I have to do something special to get MFC to support Unicode or is MFC Unicode by default?
Thanks
The idea is that all localizable items should be stored in resources. Standard UI objects such as menus and dialogs are automatically stored in there (resources) for you but items such as string literals (eg: error messages, messagebox prompts,...) should be pulled from source code to the string table. This short codeproject article of mine demonstrates how to easily pull strings from the string table in your code.
Note: You should have only one string table in your resource script (.rc).
From there on, you can translate your resources and create resource DLLs (aka satellite DLLs). The idea is that you keep a different copy of the .rc file(s) for each language. Each translation is compiled into a codeless DLL that acts as a container for the resources.
This other codeproject article of mine lets you easily load resource DLLs according to system settings or user preferences: The code looks among your resource DLLs which available language best matches user settings (based on user's UI language and regional settings). The code also lets you easily build a menu with all available languages. That way, your user can override the default choice.
DISCLAIMER: My ad follows. Feel free to skip :-)
Regarding the translation of resources, the management of translations and the creation of resource DLLs, you may want to check out appTranslator.
END OF AD :-)
Regarding Unicode, MFC ships with ANSI and Unicode versions of the code. It's up to you to choose if you want to build an ANSI or a Unicode app: Just make your pick in the first page of project settings. Of course, if you are startgin from scratch, you should definitely go Unicode. But if legacy reasons force you to stay ANSI/MBCS, don't worry to much: It won't prevent you from localizing your app.
Years ago when I had to work with multiple languages in MFC, we used separate resource DLLs. All you need do is make one call to switch which handle the resource functions would use and all was automatic from that point forward.
You need to do more than just change the strings. Dialogs in particular will have strings inside of them, and you may need to change the layout if those strings become too long after translation.
Is it possible to give a network drive mapping (as created with the WNetAddConnection functions or "Map network drive..." GUI) a label other than the default "<Target Name> (<Target Path>) (<Drive Letter>:)" one?
I tried giving SetVolumeLabel a go but this always fails, and I see nothing in the WNet API's to specficy the display label.
This isn't a 100% solution but it's more of an answer than a comment...
If you rename a mapped network drive the the GUI (by right clicking on it and going to 'Rename') it adds a value to the registry. Reading round on various sites (notably this one) it looks like Windows may sporadically delete this value by itself, so this may not be a permanent solution...
I have just manually done it through regedit and it worked in the GUI, so I see no reason why it shouldn't work programmatically as well
Add a string value called _LabelFromReg with a value of whatever you want the label to be to the registry key
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\##<server-name>#<share-name>
This key should already exist if you have already created the share.
Apparently (see the link above) you then need to make that key read-only to prevent the OS from changing it back at will - I don't know how you would do that programmatically but i'm sure it can be done.
I know there are huge gaps in this answer, but maybe it's a poke in the right direction?