This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Problem with HTML Control on a Japanese OS
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 24, 2011
03:13 PM
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.
Can someone in InstallShield please response to this question this is urgent.
(14) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 25, 2011
04:36 PM
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 25, 2011
05:00 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 28, 2011
01:06 PM
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?
Is there a specific version of Windows and IE you were testing this project on?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 28, 2011
01:31 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 28, 2011
01:36 PM
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)
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)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 28, 2011
01:55 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 28, 2011
03:43 PM
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?
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 29, 2011
12:02 PM
Josh, any update?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 29, 2011
07:58 PM
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).
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).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 30, 2011
08:48 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 30, 2011
06:25 PM
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).
// 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).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 31, 2011
02:59 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 01, 2011
09:23 AM
Hi Josh,
The workaround works, thank you.
The workaround works, thank you.