We recently migrated from a Windows 7 environment running Blue Prism version 5 to a Windows 10 one running Blue Prism version 6.
The issue arises when we get an Excel Workbook with French language-specific characters as a Blue Prism Collection.
In the Windows 7/Blue Prism v5 resource environment it works as expected. However in the Windows 10/Blue Prism v6 one in place of the French alphabet characters we are getting a "?" character.
This is probably an issue with your Blue Prism 6.x language pack, but could be a .NET language issue.
I suspect it's working with the Windows 7 environment because the Blue Prism 5.x resource has French language/localization support, while your Blue Prism 6.x resource running in the Windows 10 environment does not.
If it were an issue with your OS environment you would see the characters incorrectly displayed in Excel as well. Since it sounds like the issue is only in the Blue Prism collection itself then.
That being said if you find that your Blue Prism 6.x language settings are configured to correctly support of French characters I would check that your Windows 10 version of .NET has French language support as well. This stems from the way Blue Prism uses the DataTable .NET class from the DataSet object in the System.Data namespace to construct and transmit Collections.
Eitherway, and given how janky the BP Excel VBO is, I highly recommend looking at how the Blue Prism Excel VBO converts an Excel Worksheet range into a Blue Prism Collection.
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 am working on a form, for which I would rather not rely on the one fingered typists in the workshop to fill in (with the inevitable typo's). Therefore I wondered if anyone know how to speak directly into some cells in excel and have that speech turned into text?
I have searched the net and constantly find the text to speech option which is the exact opposite of what I would like to do.
Although this question might be more appropriate for a different site (e.g. https://superuser.com/), here's some information that's out there.
Windows has built-in support to speech-to-text. This article is for Windows 7, but I was able to do something similar to get it to work for Windows 10 (I'm not sure what version of Windows your shop uses). I'm sure there are other commercial products you can use.
With Windows 10, I had to enable speech services, then use the Win+H keyboard shortcut to activate dictation. With Excel open and in focus, anything I said was entered into the active cell.
I'm using MS Office 2016 One note on windows 10.
On my PC, when I put box-drawing characters as like this : ┴┻┷┸┸┵┶┹┺┐┐┘├┬┬┤┴┼┣┳┼ on OneNote 2016 on Windows 10 those will be shown as ⍰⍰⍰⍰⍰⍰⍰⍰⍰┐┐┘⍰⍰⍰⍰⍰⍰⍰⍰⍰. Some of these seem like a missing glyph, but some of those are displayed properly, I've changed fonts but I still get the same result. I've also tested it on different office 2016's products but this only occurred on OneNote 2016.
Any possible solutions?
The reason why this doesn't work has nothing to do with the fonts as you've found. OneNote simply doesn't support unicode as has been reported here and the same issue, but more generally can be found also in this article.
As the following excerpt about the Windows 10 Edition(but should mostly apply to other versions as well) explains, a font fallback system is used for most applications to help them display characters not in a font.
All Windows 10 editions include fonts that provide broad language support, and the Windows platform includes font fallback mechanisms designed to ensure that text in any language always displays with legible glyphs rather than boxes. But some apps may take direct dependencies on particular fonts for displaying certain Unicode characters and do not utilize the font fallback mechanisms provided by Windows 10 systems"
(emphasis mine)
However this explanation neglects how Windows actually uses fonts and why a font fallback is necessary. The way that most applications in Windows handle text is:
Find the font it wants. Depending on the application it might look for a font file that comes bundled with it, or looks for the font in the Windows Font Directory if it's a commonly used font.
Displays the characters the chosen font supports. This contains characters to display, but not all of them, as there are 137,174 Unicode Characters and designing a single font for all of them is impossible because a font file simply can't contain that many characters.
However there are font families that are attempting to do this such as Google Noto.
Uses "font fallbacks" if the application uses them to display unsupported unicode. Windows knows that no font file can support all Unicode Characters so it has a system that inserts fonts for different languages and sections of Unicode.
Older applications such as OneNote may support sections or languages of this in a more manual way, but ultimately doesn't use the font fallback system, and so doesn't support all Unicode Characters. Which leads to the next step
Windows displays the "not defined" glyph this usually has the appearance of a rectangular box as you've seen, this can be "overridden" in a font, and depending on the OS or even application may appear as a black question mark.
The reason why OneNote has so many of these font issues is because it is a legacy program. In fact, the version you have stated you use, OneNote 2016 is being Sunsetted and as such will not be getting any more updates, so there is likely no fix for this beyond using a different application.
Disclaimer: I am not an expert nor will I pretend to be, I hope that this represents an accurate explanation, but cannot guarantee it. I may turn this into a community wiki later, but I plan to research this topic more to verify it.
In Excel 2010, I have a worksheet containing Japanese text. There is no problem editing, or displaying this. When I grab the value of a cell containing Japanese and use Debug.Print to display it in the Immediate Window it appears as ???? This would be a familiar issue if I was dealing with a browser. I would just make sure everything was in UTF-8 encoding. I have Japanese installed on my English Windows and that's all working fine. In Excel I tried to set the default language to Japanese. I changed the editor font to Arial Unicode but so far I still get question marks. I contacted Microsoft. I was passed from one person to another, but they couldn't help. They offered to pass me to a Technical support person who would charge me 500 US dollars!
How can I debug Japanese values in an English version of Excel using the Immediate Window?
The VBA development environment depends on the Windows "system locale" setting to tell it what character set to use. I got it to work using
Windows Vista (English)
Excel 2010 (English)
by going into the "Regional and Language Options" section of the Windows Control Panel and setting the system locale to "Japanese (Japan)"
After my system rebooted I could see Japanese characters in the VBA Immediate Window:
I'm developing a Win CE 6 OS image and want to make it fit in the "Windows Embedded CE 6.0 Core Run-Time License".
This means, among other things, that I have to remove the Wordpad application.
From a product service and development perspective I'd like to replace it with something similar but free.
One thought was to do a simple editor in C#/CF.Net but I'd rather like to find something which can be plugged in and works, preferable free or at least cheaper than the 15$ per unit a bumped up license would cost.
Is there any suitably licensed text editors out there which are available for Win CE 6?
I don't need a rich text editor just a simple text editor to edit xml and text configuration files. The editor must be able to handle utf-8/unicode.
cke is quite good and I'm sure you can make some kind of a deal with it's author. CEdit is another good one.
I ended up writing my own simple file editor in C#/WinForms. Not great, but gets the job done.