I am using following code.
nsDialogs::CreateControl "RichEdit20A" ${WS_VISIBLE}|${WS_CHILD}|${WS_TABSTOP}|${WS_VSCROLL}|${ES_MULTILINE}|${ES_WANTRETURN} ${__NSD_Text_EXSTYLE} 30% 30% 65% 45% ``
Pop $0
;load the license from file
nsRichEdit::Load $0 $PLUGINSDIR\license.txt
(Using NSIS RichEdit Plugin)
I have problem loading special characters. They should up as ® or – instead of copyright symbol or -
I am using unicode version of NSIS and compiling on 32 bit machine. Can someone please provide suggestions for this.
I think there were an update in Unicode NSIS which fixes this issue. Try to use latest version 3.0a2.
Set Unicode true and use
nsDialogs::CreateControl "RichEdit20W" ...
The W mean Unicode version of RichEdit (A is for Ansi).
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.
Is it possible, using Visual Studio 2005 (and higher) to display a null terminated char buffer as UTF-8 strings while debugging ?
For example, if i have a buffer containing the bytes of the UTF-8 string "Здравствуйте", is there an option to display it as such (when hovering it with the mouse) instead of the ugly ascii equivalent : "ЗдравÑтвуйте" ?
Thank you :)
Use the s8 format specifier in the debug expression:
Your version of VS is stone cold old however, not sure if VS2005 supported it yet.
I'm developing a javafx-2 application and I want the user to be able to type Greek accented characters in a Textfield using a 'dead key'. Unfortunately, the accents are ignored. The javafx-2 samples provided by oracle behave the same way.
I've only checked on a mac running Lion. Java Swing applications don't have this problem. I have installed the latest JRE provided by apple (1.6.0_31-b04-414).
Thanks,
Nikos
You may want to try JavaFX 2.1 (dev preview: http://www.oracle.com/technetwork/java/javafx/downloads/index.html)
I had no problems with Greek accented characters there:
UPD: Typing these characters works as well in 2.1, see screenshot with characters entered from keyboard using dead keys for Greek Polytonic keyboard:
I am having the same problem with FX8. One solution would be to write a textproperty listener to take care of that, unless it is fixed later on. Coming from Swing it is true I did not have that problem either. I am using Windows7.
I am using the code below in several parts of my script.
${If} ${RunningX64}
; 64bit bits go here
${Else}
; 32bit bits go here
${EndIf}
In one function it runs perfectly fine, but the other calls will not work unless they are used after the initial call that executed correctly.
I have not been able to find any logical reason for this behavior. I have included both the LogicLib.nsh and x64.nsh heather files, but it goes through the 64 bit section.
What could it be? There does not seem to be any macros to initialize prior their use. Any ideas?
I'm using GetVersion plugin this way:
Var WINDOWS_ARCHITECTURE
GetVersion::WindowsPlatformArchitecture
Pop $WINDOWS_ARCHITECTURE ; 32 or 64
I can set the minimum version required (for example XP SP3) in Inno-Setup by going
MinVersion=0,5.01.2600
However, that leads to the rather unfriendly Message Box:
This program requires Windows NT version 5.1.2600 or later.
Is there any way to have this say instead:
This program requires WindowsXP Service Pack 3 or later.
This string is named WinVersionTooLowError and is defined as
This program requires %1 version %2 or later.
You can redefine it in the [Messages] section.
MinVersion=0,5.01.2600
Does not work, try this in [Setup] area, it can be used in quite a number of other areas in inno setup also.
MinVersion=0,5.1.2600