SetWindowText() only change the title of the window.
But the application title is used in numerous cases, e.g. message box title.
MSDN documentation says about CWinApp member m_pszAppName:
"...The application name can come from the parameter passed to the CWinApp constructor, or, if not specified, to the resource string with the identifier of AFX_IDS_APP_TITLE. If the application name is not found in the resource, it comes from the .exe filename of the program."
I want to create from my code several flavours of executables and base the application name on compilation switch. Therefore:
The 2nd. option (resource file) is not helpfull.
The 3rd. option (take it from the executable name) will make the difference but usually not that friendly.
The 1st. option maybe the key - to give CWinApp constructor the exect name. BUT... How do I insert code vefore calling CWinApp constructor???
Fourth alternative is to set that member in CWinApp::InitInstance() but the CWinApp destructor is releasing that pointer. causes crush in run-time.
put this in the InitInstance of your app before the return TRUE:
//First free the string allocated by MFC at CWinApp startup.
//The string is allocated before InitInstance is called.
//Change the name of the application file.
//The CWinApp destructor will free the memory.
m_pszAppName = _tcsdup(_T("MyApp's New Name"));
Thanks for your reply.
I'm dealing with a concept our company call (and maybe well-known as) private lebeling:
Our customers want to 'label' an application we do as their own. For example, if Microsoft and Intel are both our customers, the only difference between their applications will be the application name and icon (anything else?).
One way to do it is that each customer will send me his application name and icon and I'll recompile the code. Can take a lot of resources from us as a company.
Other way is that the application will use an .ini file at run-time. But .ini file can be deleted by their customers.
Is there a third and better way?
There are also the version resources. Are you familiar with those? There is a lot more that can go into the version resources and your customers will appreciate the ability to get that information into the exe also.
I think what you should do is to use the version resource data to generate the application name. That is just the beginning, though. You can also write an "About" box that gets it's data from the version resource data. An "About" box typically has copyright information, which can be supplied in the version resource data.
You don't need to recompile the entire application. If you can use the version resource data for all data that changes, then you only need to recompile the resources and then re-link. The icon can also be updated in the resources, but not the version resources.
You don't even need to do that. There is a Windows API for updating resource data in a exe file without even re-linking and there are various utilities written that use it. It works only for NT/2000/XP but I assume that is not a problem. I am not familiar with a particular utility but there are many available. Your company might need to pay a few dollars for a utility but hopefully it will be worth it.
After 2 fantastic weeks in beautifull Italy, I'm getting back to buisness.
I have several questions regarding version information resource:
1. Can I have multiple version info resources for the same project? If yes, how can I select between them in compile time/runtime?
2. I understood that there is fixed part (with numerical values) and dynamic part (with strings) that can include one or more blocks - what is the relation between those two parts (e.g. in both parts we have file version)? Can I have in the dynamic part two blocks with the same language and code page?
My motivation is to give our clients, different companies, the possibility to market our product as if it was their product. I thought of two options:
A. different version information resource for each company OR
B. different dynamic block for each company in the same version information resource