cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
rcuadra
Level 6

Problem with HTML Control on a Japanese OS

I have a multi lingual installer that contains English, French, German, Spanish, Dutch and Japanese and currently the html control is not working. Please see the attached screenshot you will notice that in the English the table is showing correctly but on a Japanese OS the table is showing a character on top of the table and this character is from the code which seems like it is being truncated. Is there a limit to the string in Japanese? Per instruction in the help If you need to enter more than 256 characters for the content, use the CtrlSetText function to create the control. Which is what I did. Why is this not working on a Japanese OS? Note: I also tried to launch a different language on a Japanese OS and it is fine so why is this only happening if you select Japanese? Is there some setting that is needed to make this work?

Can someone in InstallShield please response to this question this is urgent.
Labels (1)
0 Kudos
(14) Replies
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

Does the HTML you are using display correctly if you load it in an HTML page in Internet Explorer? If not, then there is likely an issue with the HTML code itself that needs to be corrected. If it does display correctly in Internet Explorer, can you attach a sample project including the HTML that causes this behavior?
0 Kudos
rcuadra
Level 6

joshstechnij wrote:
Does the HTML you are using display correctly if you load it in an HTML page in Internet Explorer? If not, then there is likely an issue with the HTML code itself that needs to be corrected. If it does display correctly in Internet Explorer, can you attach a sample project including the HTML that causes this behavior?


Hi Josh,

Yes the code works in Internet Explorer. I uploaded the actual code I have in the test1.txt and test2.txt (please rename it to .html) before running. I will create a sample project for you and will send it next week.
0 Kudos
rcuadra
Level 6

Josh,

Attached is the sample project you requested. Please rename the attached zip to (.7z) this is a 7zip file.
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

After testing with the attached HTML files and sample project, we have not been able to reproduce any rendering issues related to the HTML content sent to the dialog. Please see attached screenshot of a test on a Japanese XP SP2 machine with IE6. Running the setup in Japanese on a Windows 7 machine with IE9 also did not seem to have any issues.

Is there a specific version of Windows and IE you were testing this project on?
0 Kudos
rcuadra
Level 6

joshstechnij wrote:
After testing with the attached HTML files and sample project, we have not been able to reproduce any rendering issues related to the HTML content sent to the dialog. Please see attached screenshot of a test on a Japanese XP SP2 machine with IE6. Running the setup in Japanese on a Windows 7 machine with IE9 also did not seem to have any issues.

Is there a specific version of Windows and IE you were testing this project on?


Hi Josh,

I'm currently testing it on a Windows 2003 SP2 with IE 8. I'm not sure why IE version would make any difference here. As for the screenshot, did you happen to scroll down did it have any tags showing, in my test even if the headers are ok, when I scroll down there is still a problem.

BTW, I'm using IS2010 I hope you did not convert it to IS2011.

As far as the html is concerned like I mention in the original question the same code that I use in the installer works if save in html and launched in IE.
0 Kudos
rcuadra
Level 6

Attached is the compiled setup can you please test this in your machine. Please rename the .zip to .7z as previous attachment.

I also added a screenshot of the setup that is zipped when ran in Windows 2003 sp2 japanese.

Notice the highlighted area in red. Note: if I select a different language say English on the same sample exe it works fine (please see attachment)
0 Kudos
rcuadra
Level 6

Hi Josh,

Here's another test if you open the FolderPermDlg.rul and change the following lines:

//uncomment this and recompile if you want to see a different problem with the html control in Japanese
szTemp4 = "   ";

//comment this out when you uncomment the one on top
//szTemp4 = "   ";

The result will be as this (see attachement). In this case the headers are ok but if you scroll down it is not. When I run it and choose English it is fine.

Please note if you convert it to IS2011 it is not an acceptable solution for us because we are 1 month away from release and we are not going to convert because of a bug. I hope you will provide a hotfix or at least you already have a hotfix.
0 Kudos
rcuadra
Level 6

Josh,

In IS2010 about it says:

Support for Unicode
InstallShield takes a three-pronged approach to fully supporting modern multilanguage installations: Windows Installer databases can now be built in a Unicode format, InstallShield projects are now stored in a Unicode format, and the InstallShield interface now supports entering and viewing Unicode characters from multiple character sets at the same time.

Unicode (UTF-8) Databases
The Build tab in the Releases view has a new Build UTF-8 Database setting that lets you specify that a Windows Installer database, along with any instance or language transforms, be built using the UTF-8 encoding. The UTF-8 encoding supports characters from all languages simultaneously, enabling you to mix and match, for example, Japanese and German, or Russian and Polish, both in text shown to end users and in file names and registry keys. These mixed languages work correctly regardless of the current language of the target system. Unicode support has also been added to key parts of the installation run times, including IIS support and changes to text and XML files.

The default value for the new Build UTF-8 Database setting is No.

The automation interface now includes support for this new setting. The ISWiRelease object includes a new BuildUTF8Database property that lets you specify whether you want to use the UTF-8 encoding.

This feature is available in the following project types: Basic MSI, InstallScript MSI, and Merge Module projects.

This feature resolves the following issues: IOB-000050571, IOC-000053626, IOC-000070145, and IOC-000074276.

Unicode Project Files (*.ism)
InstallShield now uses the UTF-8 encoding when saving both binary and XML project files. Because of this change, the files, registry data, and other strings that are used in the project can include characters from all languages simultaneously. With this encoding, InstallShield no longer needs to use an unreadable Base64 encoding for strings that are stored in the ISString table. Instead, as you add or modify strings in a project, InstallShield now saves them as human-readable Unicode strings that you can easily examine for changes across revisions of your project. Therefore, InstallShield uses only Unicode strings for all new projects that are created in InstallShield 2010; for upgraded projects, InstallShield uses Unicode for new and modified strings, as well as for strings that have been exported and reimported.

If you use Unicode values that cannot be represented in the target build (for example, an InstallScript installation, or a Basic MSI installation in which No is selected for the Build UTF-8 Database setting), a new build error points to the item that needs to be changed. In some instances, this reveals invalid string entries that were silently allowed in earlier versions of InstallShield.

This feature applies to all project types.

Unicode Views in InstallShield
Many views in InstallShield have been enhanced to display and allow you to enter characters from all languages. For example, in the Files and Folders view, Chinese file names from your local English system are no longer displayed with question marks for their names, and now you can add these files to your project. Similarly, the Registry view no longer converts Thai registry keys or values to question marks, and you can install them with your Windows Installer–based projects. In addition, you can view and edit strings from all languages in the String Editor view, a new separate view; previously, string entries were available from separate language nodes in the General Information view. Examples of other enhanced views include the Property Manager, Path Variables, Direct Editor, General Information, and Setup Design views.

Note that whenever No is selected for the Build UTF-8 Database setting, all file names, registry keys, and other strings must still consist of characters from the code page of all target languages that will use it. In this scenario, if an item uses a character that is not available on the code page of a target language, InstallShield reports a new build error that points to this item; the Chinese file name cannot be used in an English installation unless Yes is selected for the Build UTF-8 Database setting.

This feature applies to all project types.

This feature resolves the following issues: 1-12AZWL, 1-17D9Y0, 1-AT26Z, 1-NMATB, 1-SORS9, IOC-000073872


Is IS2010 InstallScript project really UTF-8 encoded?
0 Kudos
rcuadra
Level 6

Josh, any update?
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

In my test there where no erroneous/unclosed html tags in any of the cells in this table, either with Japanese or English systems.

For testing, I am building with what is basically IS 2011 since I don't have immediate access to IS 2010. However, nothing specific to the HTML control support changed in 2011.

Regarding the project file, the text encoding for InstallScript projects should be UTF-8. However, the InstallScript compiler (and any rul files), build, storage (data1.cab), and runtime in 2010 were still ANSI based. Any string operations during build, or at runtime that call outside of the script itself (for instance, CtrlSetText calls out of script to change the content of an HTML control) are subject to codepage conversions. The build, storage format, and runtime were updated in IS 2011 to be Unicode compatible (rul files and the compiler are still ANSI, however, strings can be stored in the string table and referenced through string IDs to be Unicode compatible).
0 Kudos
rcuadra
Level 6

joshstechnij wrote:
In my test there where no erroneous/unclosed html tags in any of the cells in this table, either with Japanese or English systems.

For testing, I am building with what is basically IS 2011 since I don't have immediate access to IS 2010. However, nothing specific to the HTML control support changed in 2011.

Regarding the project file, the text encoding for InstallScript projects should be UTF-8. However, the InstallScript compiler (and any rul files), build, storage (data1.cab), and runtime in 2010 were still ANSI based. Any string operations during build, or at runtime that call outside of the script itself (for instance, CtrlSetText calls out of script to change the content of an HTML control) are subject to codepage conversions. The build, storage format, and runtime were updated in IS 2011 to be Unicode compatible (rul files and the compiler are still ANSI, however, strings can be stored in the string table and referenced through string IDs to be Unicode compatible).


Hi Josh,

I understand that in your test you do not see the problem but keep in mind that I'm using IS2010 and not IS2011, I did confirm that when you convert it to IS2011 the problem goes away.

Per your comment:
However, nothing specific to the HTML control support changed in 2011.

This might be true but I think something has changed in IS2011 that fixes the problem in IS2010. Would someone in your group be able to use IS2010 and try this again? I also attached the compiled setup.exe for you to test, did you see the problem when you ran this executable on the same machine?

As I mentioned in my other post, when I select English or any other language other than Japanese on a Japanese OS there where no erroneous/unclosed html tags in any of the cells in the table it is only happening when I select Japanese.

I think the problem here has something to do with how IS do encoding so your comment "runtime in 2010 were still ANSI based. Any string operations during build, or at runtime that call outside of the script itself (for instance, CtrlSetText calls out of script to change the content of an HTML control) are subject to codepage conversions. The build, storage format, and runtime were updated in IS 2011 to be Unicode compatible (rul files and the compiler are still ANSI, however, strings can be stored in the string table and referenced through string IDs to be Unicode compatible)" might be the actual problem that is causing this erroneous html tags.

Unfortunately, we CANNOT use IS2011 on our upcoming release so there has to be some fix that you guys can provide to fix this problem. Remember that not all customers can just upgrade on the fly just because it is a problem in one version but fix on another.
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

I've been able to reproduce this behavior in IS 2010. Unfortunately, I am unsure as to the root cause of this behavior. However, as a workaround, the HTML content can be written to a file and then the file can be set as the HTML control content. Code similar to the following could be used:

// hFile is a NUMBER variable
OpenFileMode(FILE_MODE_NORMAL);
CreateFile(hFile, SUPPORTDIR, "testhtml.html");
WriteLine(hFile, szHTMLText);
CloseFile(hFile);

CtrlSetText(szDlg, DLG_FOLDERPERM_HTML, "[html]file://" + SUPPORTDIR ^ "testhtml.html");



Note that when building the HTML content, the [html] tag at the beginning of the string should no longer be used.

Also note that the file created with the above code will not be cleaned up automatically and should therefore be deleted in an event such as OnEnd (or at any point after the dialog has closed).
0 Kudos
rcuadra
Level 6

joshstechnij wrote:
I've been able to reproduce this behavior in IS 2010. Unfortunately, I am unsure as to the root cause of this behavior. However, as a workaround, the HTML content can be written to a file and then the file can be set as the HTML control content. Code similar to the following could be used:


Note that when building the HTML content, the [html] tag at the beginning of the string should no longer be used.

Also note that the file created with the above code will not be cleaned up automatically and should therefore be deleted in an event such as OnEnd (or at any point after the dialog has closed).


Hi Josh,

Thank you for the workaround I will try this and let you know of the result.
0 Kudos
rcuadra
Level 6

Hi Josh,

The workaround works, thank you.
0 Kudos