I just tried to compile an old MFC app under VS2013. It complained that non-Unicode MFC applications were deprecated, and refused to compile. Which is somewhat contrary to this announcement that talks about deprecating support for MBCS. Until now there were three choices for the Character Set option:
Unicode
MBCS
Not set
Personally, I'm entirely comfortable with dropping support for MBCS - I neither want nor need MBCS. But nor do I want nor need Unicode - ANSI/ASCII is just fine by me. So insisting that every MFC application henceforth must speak Unicode, and (in effect) provide the foundations of a platform support all possible languages, no matter who its intended audience is, seems... extreme. Am I missing something? Should I still be able to compile an MFC application with no character set specified under VS2013?
You can. Currently all my programs use the Unicode library. Except one older one, that includes very old code from previous versions and this program is needed for update support for this od version...
Currently there is an Addon that still supports MBCs.
Vote for it
As I understand the discussion (see comment of Mark Davis dated December 2014) such an Addon will be available up and including VS2015 (whatever Version is meant).
To be more precise what happens when you select "None" for the character set:
You program is linked against the MBCS Version of the MFC
Also the Windows SDK will Default to the MBCS Version of the API. So i.e. GetWindowTextA is calls instead of GetWindowTextW
So in fact. Setting _UNICODE and _MBCS to nothing just Defaults to _MBCS...
Internally the SDQ always checks a if UNICODE (not _UNICODE) is set. If not the MBCS Version is chosen.
Related
I have tried install llvm 7.0.1 on Windows 10.
But the installer has text corruption like below.
It make so harder to install.
How do I fix it?
I using Windows 10 1809, chcp is 65001.
I using Japanese.
I have enabled "Use Unicode UTF-8 for worldwide language support" in Region settings".
Is this change cause of the error?
But A installer of other application does not be text curruption.
Update:
The Picture of installer with compatibility mode (Windows XP SP3)
That LLVM installer is not a Unicode NSIS installer. The LLVM team can fix it by adding Unicode True to their NSIS script.
That LLVM installer looks like it supports multiple languages (I could not find it's source, it might be using CMake/Ninja) and NSIS does try to guess the correct language but this is based on the return value of GetUserDefaultUILanguage() and not the active codepage.
I could not replicate your issue on build 18290 (after changing to UTF-8 and rebooting I verified that GetACP() returns 65001) but this is probably because my system is detected as English by NSIS.
Based on the (N) in your Next button in your screenshot I'm going to guess that your UI language is detected as Chinese or Japanese?
Without more information about your system it is hard to guess if this is a bug in NSIS or Windows. NSIS is a relatively normal application and does not call MultiByteToWideChar on its interface strings (IIRC).
Edit:
By forcing a installer to pick Japanese I can replicate your issue. The solution for this issue is to switch your "language for non-Unicode programs" back to Japanese if you wish to install this application using Japanese as the display language. Another solution you can try is to set the locale for a single application. AppLocale was Microsoft's solution to this but it is not supported on Windows 10 but there are other alternatives out there.
When building a NSIS installer without Unicode support the program stores the text internally as raw bytes encoded with the codepage of the specific language. At run time it uses functions like SetWindowTextA to set the text of UI elements. This is how non-Unicode applications have worked since the dawn of time on Windows. All non-Unicode programs that display text outside the ASCII range will have the same issue unless they have been specifically written to support UTF-8 as the active codepage (which is unlikely since it is a new feature). This feature is only useful for console applications and ported POSIX applications that assume that the narrow string is UTF-8 encoded.
Too long for a comment.
UPDATE: Looking at this a little, I am wondering if the problem is a font corruption issue. There is a description of rebuilding the font cache here: http://www.trishtech.com/2013/11/rebuild-fonts-cache-windows-8/. I think you must install a good copy of the font file first though? You do that by copying the font files into the Fonts folders I believe. I will check with Anders what font NSIS uses.
Similar issue with an MSI file: Windows Installer ugly font rendering.
Compatibility Mode: Pretty sure that UTF8-setting would cause it. I don't think it would work, but the first thing I would try would be to run the executable in compatibility mode.
Locate the setup.exe in question.
Right click the EXE, hold right mouse button down, now drag to empty desktop area and release mouse button. Click "Create Shortcut Here".
Right click Shortcut => Properties => Compatibilty tab.
Try various combinations of "Run program in compatibility mode for..."
I would try "Windows XP" highest service pack first. Click OK when done.
Now double click the shortcut to launch the executable and see what happens.
I installed and used a UML plugin found here: UML Plugin for Netbeans 7.0?
Afterword, all of my .java code associated with the UML became black and white and un-editable. Although, I can write extra text it cannot be deleted. Running my project results in "Cannot execute - java executable not found".
I deleted the UML files associated with my projects and the code hasn't returned to normal.
Thanks.
Here is a picture:
This actually occurred to all java files.
Unlike Eclipse, different versions of NetBeans are so different that plugins made for younger versions (6) DO NOT work on later versions (8) by default. You can upgrade only subversions steps (digits after dot) without changing plugins. So you have used two pieces of SW that need not be compatible at all. You used a workaround to make to work the installation. And you can get absolutely any consequences, don't be surprised.
The history of the problem: there is no free UML plugin supporting NetBeans NOW. There was one, of Visual Paradigm, for versions to 6. But it's later variants are not free anymore and they are differently organized. If you want to use the modern version of the plugin, prepare to pay. It is very probable, that the free plugin doesn't work on NetBeans 8 by purpose.
You can try a new different plugin http://plugins.netbeans.org/plugin/49069/plantuml#v2590 of another author. It seems more simple, but at least it won't destroy your IDE. And now you have to save the project, reinstall NetBEans and import the project again.
Possible duplicate of this question.
I have a MFC project that uses /clr switch and some C++/CLI code to use a .Net component. Originally this was on VS2005.
On upgrading to VS2012 Update 2, during debugging, no values or types were shown for native data types. I learned that a new mechanism for native data type visualization (natvis) was introduced in VS2010 and extended / enhanced in VS2012. Following the information on that page, I unchecked Managed C++ Compatibility Mode and C/C++ edit and continue. After this, breakpoints became disabled and stopped being hit. Using "Only Managed" debugger, the breakpoints were hit but no values were shown.
Finally, I used "mixed" debugger and used __debugbreak() to force a break. This resulted in only integer values being shown ONLY if they are local autos; and data types were picked up correctly. However, std::string or CString values are not shown and instead their type is shown in value column. Similarly, pointers, class members, or functions argument values are not shown and type information, Undefined value, or out of scope is shown in the value column.
The behavior is consistent across autos, locals and watch windows as well as mouse hover on symbols.
How do I get the native data types to display their values during debugging in VS2012 mixed mode C++/CLI MFC application.
I have read this question and verified that all symbols have been loaded in modules window.
Apparently, Microsoft is aware of the issue and the upcoming CTP of Update 3 should fix it.
Additionally, why do I need to use __debugbreak()?
A couple of days ago, Microsoft released a Visual Studio Service Pack 3 RC which may help (installing it myself right now). Here is the link: http://www.microsoft.com/en-us/download/details.aspx?id=38832
Re-install Visual Studio 2012 and do not apply Service Pack 2.
I would expect the mfc to refer to the Microsoft Foundation Classes, but this still leaves the following questions:
What does the s stand for?
What does the 90 mean?
These MFC link libraries are lightly documented by Microsoft's TN033 Tech Note: http://msdn.microsoft.com/en-us/library/hw85e4bb.aspx
A quick summary about the mfcsxxx.lib files is: The MFCSxx[U][D].LIB libraries are used in conjunction with the MFC shared DLLs. These libraries contain code that must be statically linked to the application or DLL.
The "U" designates that the library is built for Unicode.
The "D" designates that the library is built for Debug.
If the number in the library is 90, then it's compiled with and for Visual Studio 2008 (VC++ 9.0)
If the number in the library is 100, then it's compiled with and for Visual Studio 2010 (VC++ 10.0)
Note that while the mfcsxxx.lib files have code that is statically linked to the output binary, they are used in conjunction with the DLL versions of MFC - when statically linking MFC, the [nu]afxcw[d].lib libraries are used (where "n" or "u" determines whether or not the library is Unicode, and "d" is used in Debug builds).
Other related MSDN pages:
Library Naming Conventions (for MFC static linking)
Naming Conventions for MFC DLLs
C Run-Time Libraries
90 is 9.0 and means it corresponds to Visual Studio 2008
I'm going to take a stab at the 's' and say it says the library supports MultiByte Character Sets (as opposed to Unicode or ANSI), but I could not find a link that directly confirmed that.
Edit:
Michael Burr is correct, the 's' indicates it is a library that is statically linked and used in conjunction with the shared DLL versions of MFC. I almost prefer the documentation for Visual Studio 2003: http://msdn.microsoft.com/en-us/library/eezxhb2t(v=vs.71).aspx where it has the DLL in the table and explains what it is for.
I've got several large MFC applications here, and converting them into any other format is out of the question. We're expanding into other markets, and would like to make the apps work in other languages and cultures.
So far, I've found occasional references as to what to do with Visual C++ version 6, with one mention that later versions of MFC have additional relevant features. Searching MSDN gives me instructions on how to convert the apps to Unicode, which we already did. I found nothing on MSDN on how to make languages multilingual once they're in Unicode, only a few older things using Google, and one book about internationalization using VC++6. (We're using Visual Studio 2008 now, on XP and Vista.)
I make no claims for the strength of my Google-fu, and would be happy to be directed to things I've missed.
Is it reasonable to use the methods of VC++6, or should I use later features?
If I should use features later than that, where can I find some reference to them?
Is there something I should worry about other than setting the locale, converting all strings to resources, and duplicating resources in different languages?
I can find more things about .NET internationalization, but I'm inexperienced in .NET. What will I find there that's applicable to VC++ and MFC?
Edit: I just ran into difficulties trying to put Unicode strings into the String Table resource. (As far as I can tell, Unicode strings need to be entered into the .rc file with a text editor, in L"0x0034" form. I haven't found a resource editor way to do that.) Any tips on that? Any other resource I can use in VS2008 using VC++ and MFC?
Edit: Somebody on a Microsoft forum suggested that I open the offending .rc file in Notepad, and save it in Unicode. Unfortunately, this doesn't seem to fix the dialogs, although the stringtable seems to be working in Japanese.
There's a lot more than just translating "strings" to internationalize an application.
Most of your UI will need to be updated to take into account the different text lengths, and language orientation (thing Hebrew, Chinese, Arabic, ...)
Some images will also need to be changed to fit a different culture (unfortunately, I don't have an example for that), either the figurative is different or the colors do not fit local specifications.
We are using a tool like appTranslator to help us do the cosmetic localization (UI re-formatting) and use a professional technical translator for the strings.
You can also create a resource only dll
See How To Create Localized Resource DLLs for MFC Application for more details.
You can internationalize your application using the following ways.
After you converted the application to unicode (you already did) and all the strings should be loaded from String table.
For each language you need to change the string table and compile
One more way is to maintain a XML file which contains all the strings in the localized format. Load the xml and strings depending on the language.
Here's a CodeProject article of mine that describes very "coding-efficient" method to pull strings from the string table (required for translatable texts):
http://www.codeproject.com/KB/string/stringtable.aspx
Here's another class that help your app pick the right UI language. It also helps you create a language selection menu:
http://www.codeproject.com/KB/locale/LanguageMenu.aspx
Last but not least, appTranslator is a tool that helps you translate the UI of your app, detect what changes were made in resources since the last version, create translated exe or resource DLLs and much more:
http://www.apptranslator.com
(Note: I'm the author of appTranslator.)